Bug 35824 – Relax 3rd party cookie policy in certain cases

• Component: Page Loading
• Status: RESOLVED FIXED

[Brady Eidson]

Currently the default WebKit + CFNetwork 3rd party cookie policy prevents any changes to non-1st party cookies.  This is to prevent undesirable user tracking from 3rd parties.

We should relax this policy a tad to allow setting 3rd party cookies when the 3rd party in question already has a cookie set.  This shouldn't actually open up any new tracking vectors but will fix certain real world compatibility issues.

Since the policy is only implemented by CFNetwork on Mac and Windows, and Mac + Windows only patch to WebCore is upcoming.

[Brady Eidson]

<rdar://problem/7163012>

[Brady Eidson]

Created attachment 50145 [details]
Fix for Mac + Win

Fix by setting the first party url for a request to the url of the request itself if we mean to relax the policy for that particular request.

Comment on attachment 50145 [details]
Fix for Mac + Win


> -        CFURLRequestSetHTTPCookieStorageAcceptPolicy(newRequest, CFHTTPCookieStorageGetCookieAcceptPolicy(cookieStorage));
> +        
> +        int policy = CFHTTPCookieStorageAcceptPolicy(cookieStorage);

I think you meant to use CFHTTPCookieStorageGetCookieAcceptPolicy()! This is just casting cookieStorage to a CFHTTPCookieStorageAcceptPolicy, which happens to be int. So this should be

    CFHTTPCookieStorageAcceptPolicy policy = CFHTTPCookieStorageGetCookieAcceptPolicy(cookieStorage);

I didn’t review the rest of the patch, but r- based on that. Sorry.

[Brady Eidson]

> I didn’t review the rest of the patch.

Awwwwww....

[Brady Eidson]

Created attachment 50232 [details]
Fix for Mac + Win (tested on Windows, now)

[Anders Carlsson]

Comment on attachment 50232 [details]
Fix for Mac + Win (tested on Windows, now)


>      if (CFHTTPCookieStorageRef cookieStorage = currentCookieStorage()) {
>          CFURLRequestSetHTTPCookieStorage(newRequest, cookieStorage);
> -        CFURLRequestSetHTTPCookieStorageAcceptPolicy(newRequest, CFHTTPCookieStorageGetCookieAcceptPolicy(cookieStorage));
> +        CFHTTPCookieStorageAcceptPolicy policy = CFHTTPCookieStorageGetCookieAcceptPolicy(cookieStorage);
> +        CFURLRequestSetHTTPCookieStorageAcceptPolicy(newRequest, policy);
> +        if (policy == CFHTTPCookieStorageAcceptPolicyOnlyFromMainDocumentDomain) {

You should add the same comment here that you added in ResourceHandleMac.mm. Have you tried this on Tiger as well?

r=me

[Brady Eidson]

Thanks!

(In reply to comment #6)
>
> Have you tried this on Tiger as well?
>

No, but the APIs used are documented as having existed since 10.2.7 so I'll trust in the bots to confirm or deny.

[Brady Eidson]

Fixed in http://trac.webkit.org/changeset/55672

[Brady Eidson]

Fixed in http://trac.webkit.org/changeset/55672

[Darin Fisher (:fishd, Google)]

I'm confused by the change.  It seems like this change would allow a third-party site to do things like increment a visitation counter.  Doesn't that go against the privacy goals of blocking third-party cookies?

Do you have a list of popular websites for which this change helps?

[Brady Eidson]

(In reply to comment #10)
> I'm confused by the change.  It seems like this change would allow a
> third-party site to do things like increment a visitation counter.  Doesn't
> that go against the privacy goals of blocking third-party cookies?

If you already have a cookie set, you can implement a server-side visit counter.

> Do you have a list of popular websites for which this change helps?

Facebook, and many Windows Live ID enabled sites.

[Jeff Johnson]

I see several problems here. First, there's this bug:

https://bugs.webkit.org/show_bug.cgi?id=26391

So, you visit a site with third-party Flash content, and unbeknownst to you, a third-party cookie gets set. Combined with the change here, it basically becomes anything goes for third-party cookies, as long as they can get that first cookie on your machine somehow.

Second, Brady, when you say, "If you already have a cookie set, you can implement a server-side visit
counter", I don't think this is true of any old cookie. It's only true of a uniquely identifying cookie.

Suppose you visit a site, set some kind of site-specific preference (e.g., location, language, color scheme, sorting, filtering), leave the site, and then delete all of the site's cookies except the one containing the site-specific preference you're interested in. Then you have a cookie for the site on your machine, but it's not a tracking cookie. However, combined with the change here, you're now allowing any cookies to be set for that domain even when you're not visiting the site directly.

[Brady Eidson]

(In reply to comment #12)
> I see several problems here. First, there's this bug:
> 
> https://bugs.webkit.org/show_bug.cgi?id=26391
> 
> So, you visit a site with third-party Flash content, and unbeknownst to you, a
> third-party cookie gets set. Combined with the change here, it basically
> becomes anything goes for third-party cookies, as long as they can get that
> first cookie on your machine somehow.

This argument basically says "they can get a cookie on your machine anyway" which implicitly argues that WebKit's cookie policy is irrelevant.

That said, we plan on fixing this hole.

> Second, Brady, when you say, "If you already have a cookie set, you can
> implement a server-side visit
> counter", I don't think this is true of any old cookie. It's only true of a
> uniquely identifying cookie.

Possibly.  Depending on the setup of a particular ad provider's content, they may or may not be able to gleam additional information through the content requested.

There'd certainly be no way for WebKit to tell whether a cookie is "uniquely identifying" or not.

> Suppose you visit a site, set some kind of site-specific preference (e.g.,
> location, language, color scheme, sorting, filtering), leave the site, and then
> delete all of the site's cookies except the one containing the site-specific
> preference you're interested in. Then you have a cookie for the site on your
> machine, but it's not a tracking cookie. However, combined with the change
> here, you're now allowing any cookies to be set for that domain even when
> you're not visiting the site directly.

This is a *very* uncommon power-user scenario.

If you're managing individual cookies such as "preferred language" or "color scheme", we're probably talking about a site that you visit as a first party and not some 3rd party advertiser that you're concerned is tracking you as a 3rd party.

[Adam Barth]

I'm sorry I didn't see this bug earlier.  This change is lame.  You're right that third-party cookie blocking isn't 100% effective, but when thinking about the feature, you can't think of it as a security feature (because its not a security feature).  It's a privacy feature.

Anyway, this change basically makes third-party cookie blocking toothless.  You might as well just turn it off.

[Maciej Stachowiak]

(In reply to comment #14)
> I'm sorry I didn't see this bug earlier.  This change is lame.  You're right
> that third-party cookie blocking isn't 100% effective, but when thinking about
> the feature, you can't think of it as a security feature (because its not a
> security feature).  It's a privacy feature.
> 
> Anyway, this change basically makes third-party cookie blocking toothless.  You
> might as well just turn it off.

I agree that it's a privacy feature. I think the Flash loophole is a red herring and is something we should fix separately.

Do you think being able to update a pre-existing cookie is significantly more "lame" than being able to track you via a pre-existing cookie that isn't updated? It's true that there may be a privacy delta if the original cookie doesn't uniquely identify the user, however, third-party cookie blocking is targeted at users who don't carefully manage their cookies by hand.

[Adam Barth]

IMHO, we should make this feature stronger by blocking both read and writing cookies in a third-party context.  That would have the benefit of blocking tracking even if the user has already interacted with the site in a first-party context.  You still won't be able to stop cooperative tracking (where the first-party and the third-party collude to track the user), but you'll be much better off again non-cooperative tracking.

[Brady Eidson]

(In reply to comment #16)
> IMHO, we should make this feature stronger by blocking both read and writing
> cookies in a third-party context.  That would have the benefit of blocking
> tracking even if the user has already interacted with the site in a first-party
> context.  You still won't be able to stop cooperative tracking (where the
> first-party and the third-party collude to track the user), but you'll be much
> better off again non-cooperative tracking.

Users use some sites as both a 1st and 3rd party and expect it to work.

For example, facebook.com and facebook connect enabled sites.  IE/Firefox/Opera would all work but WebKit browsers wouldn't.

You want this real world incompatibility?

[Maciej Stachowiak]

(In reply to comment #16)
> IMHO, we should make this feature stronger by blocking both read and writing
> cookies in a third-party context.  That would have the benefit of blocking
> tracking even if the user has already interacted with the site in a first-party
> context.  You still won't be able to stop cooperative tracking (where the
> first-party and the third-party collude to track the user), but you'll be much
> better off again non-cooperative tracking.

We could do that. But that would be a different feature, one we probably could not ship by default, because it would break too many features that users see as legitimate (such as Facebook Connect).

Regards,
Maciej

[Maciej Stachowiak]

(In reply to comment #18)
> (In reply to comment #16)
> > IMHO, we should make this feature stronger by blocking both read and writing
> > cookies in a third-party context.  That would have the benefit of blocking
> > tracking even if the user has already interacted with the site in a first-party
> > context.  You still won't be able to stop cooperative tracking (where the
> > first-party and the third-party collude to track the user), but you'll be much
> > better off again non-cooperative tracking.
> 
> We could do that. But that would be a different feature, one we probably could
> not ship by default, because it would break too many features that users see as
> legitimate (such as Facebook Connect).
>

By the way, it may be that the weakened third-party cookie blocking is too weak to have at all. I do think it would typically stop, say, doubleclick.net from tracking you (assuming we fix the Flash loophole), but not sites that most users also interact with as a first party, such as google.com of facebook.com. That's more or less the same as the current default policy, though. The only difference is for users who have carefully hand-pruned their cookies down to ones that are useful but which do not uniquely identify them.

We could certainly consider adding a non-default policy that is worse for compatibility but better for privacy, though not as much as blocking all cookies. That might be better for the sort of user who would carefully go over his or her cookies and handpick which ones to keep.

[Adam Barth]

I wrote the below before Maciej wrote his comments.  It seems we're pretty much in agreement.

===

> You want this real world incompatibility?

Alright, I'm regretting stepping into the morass that is third-party cookie
blocking.

The overarching problem is that third-party cookie blocking can't actually
provide decent privacy benefits without breaking sites.  We can machinate
around the privacy / compatibility trade-off forever.  Compatibility always has
a stronger pull because you can see that XYZ works after you bolster
compatibility whereas you don't see the privacy costs because they're harder to
measure.

There are essentially three reasonable design points for third-party cookie
blocking

1) Block writing in third-party contexts.
2) Block reading in third-party contexts.
3) Block reading and writing in third-party contexts.

with roughly increasing security benefits.  WebKit already has a number of
hacks to try to improve the compatibility of (1), which end up making the web
platform more complex.  For example, forms submitted from third-party context
have the cookie blocking ban lifted.  That means that an advertiser who wants
to track users can just use form submissions instead of using other kinds of
loads.

At some level, the problem is that we have third-party cookie blocking on by
default.  That means that we're forcing everyone to give up compatibility to
gain some amount of privacy.  That means we get pushed harder by every
compatibility problem and end up doing a diservice to folks who have stronger
privacy goals.  If we turned off third-party cookie blocking by default, we'd
gain the following benefits:

1) The web platform would be more predictable because the default behavior
would be much simpler.
2) Folks who care more about privacy end up with a privacy/compatibility trade
off that better suits their desires because they aren't forced to make
compromises on behalf of the proletariat.

[Maciej Stachowiak]

(In reply to comment #20)

> 
> There are essentially three reasonable design points for third-party cookie
> blocking
> 
> 1) Block writing in third-party contexts.
> 2) Block reading in third-party contexts.
> 3) Block reading and writing in third-party contexts.
> 
> with roughly increasing security benefits.  WebKit already has a number of
> hacks to try to improve the compatibility of (1), which end up making the web
> platform more complex.  For example, forms submitted from third-party context
> have the cookie blocking ban lifted.  That means that an advertiser who wants
> to track users can just use form submissions instead of using other kinds of
> loads.
> 
> At some level, the problem is that we have third-party cookie blocking on by
> default.  That means that we're forcing everyone to give up compatibility to
> gain some amount of privacy.  That means we get pushed harder by every
> compatibility problem and end up doing a diservice to folks who have stronger
> privacy goals.  If we turned off third-party cookie blocking by default, we'd
> gain the following benefits:
> 
> 1) The web platform would be more predictable because the default behavior
> would be much simpler.
> 2) Folks who care more about privacy end up with a privacy/compatibility trade
> off that better suits their desires because they aren't forced to make
> compromises on behalf of the proletariat.

We'll consider adding a stronger cookie blocking mode, though I think it would likely require CFNetwork changes to implement it on Mac, and UI approval to make it a visible option in Safari's UI (other browsers are of course free to pick their own defaults). It's probably more useful for "power users" than 100% cookie blocking. We'd certainly take patches to support the concept of that mode in WebKit.

I think the weak third-party blocking is still useful and viable as a default option, even if there is also stronger cookie blocking available. If it provides a smaller privacy benefit but achieves much better Web compatibility, then it's still a benefit to the vast majority of users who will never change their preferences. I am not yet convinced that the privacy benefit is completely nonexistent. I'm also not convinced that the level of complexity in the restrictions is so high as to negate the user benefit for users running with default settings.

More relevant to the immediate situation, I think the patch for this bug does not substantially affect the level of privacy benefit that third-party cookie blocking provides. Your argument above does not seem to justify your earlier comment that "this change is lame". For the issues of creating a new stronnger cookie policy, I think a separate bug is called for. For the possibility of changing Safari's default settings, that should be filed at bugreport.apple.com (or we can bring it up ourselves with the relevant security and HI folks).

[Adam Barth]

> More relevant to the immediate situation, I think the patch for this bug does
> not substantially affect the level of privacy benefit that third-party cookie
> blocking provides. Your argument above does not seem to justify your earlier
> comment that "this change is lame".

Well, the change is lame:

+                CFURLRequestSetMainDocumentURL(newRequest, url);

That line isn't correct.  The main document URL isn't |url|.  To the extent that things besides cookie blocking are using the main document URL, they'll get the wrong answer.

Also, w.r.t. <http://code.google.com/p/chromium/issues/detail?id=37684>, I'm not sure I'd recommend that Chrome loosen its non-default, block-on-write third party cookie policy to match this new behavior because the compatibility cost isn't as acute.  That means Chrome and Safari's third-party cookie policies will likely diverge, which is bad for the web platform.

[Brady Eidson]

(In reply to comment #22)
> > More relevant to the immediate situation, I think the patch for this bug does
> > not substantially affect the level of privacy benefit that third-party cookie
> > blocking provides. Your argument above does not seem to justify your earlier
> > comment that "this change is lame".
> 
> Well, the change is lame:
> 
> +                CFURLRequestSetMainDocumentURL(newRequest, url);
> 
> That line isn't correct.  The main document URL isn't |url|.  To the extent
> that things besides cookie blocking are using the main document URL, they'll
> get the wrong answer.

Nothing in our networking layer uses the main document url for anything besides determining 3rd party cookie policy.

> > Also, w.r.t. <http://code.google.com/p/chromium/issues/detail?id=37684>, I'm
> not sure I'd recommend that Chrome loosen its non-default, block-on-write third
> party cookie policy to match this new behavior because the compatibility cost
> isn't as acute.  That means Chrome and Safari's third-party cookie policies
> will likely diverge, which is bad for the web platform.

In that bug, the reporter mentions "for all I know, chrome already has this relaxed behavior?"

Does it?

> I'm not sure I'd recommend that Chrome loosen its non-default, block-on-write third
> party cookie policy to match this new behavior because the compatibility cost
> isn't as acute.  

I don't understand how - if the cookie policies of Chrome and shipping Safari/WebKit are identical - that Chrome doesn't have the same facebook.com vs Facebook connect website incompatibility.  Can you explain how it doesn't?

[Jeff Johnson]

(In reply to comment #21)
> We'll consider adding a stronger cookie blocking mode, though I think it would
> likely require CFNetwork changes to implement it on Mac, and UI approval to
> make it a visible option in Safari's UI (other browsers are of course free to
> pick their own defaults). It's probably more useful for "power users" than 100%
> cookie blocking. We'd certainly take patches to support the concept of that
> mode in WebKit.

I would be in favor of this. What CFNetwork changes do you envision that aren't already handled by -[NSMutableURLRequest setMainDocumentURL:] and -[NSMutableURLRequest setHTTPShouldHandleCookies:]?

[Brady Eidson]

(In reply to comment #24)
> (In reply to comment #21)
> > We'll consider adding a stronger cookie blocking mode, though I think it would
> > likely require CFNetwork changes to implement it on Mac, and UI approval to
> > make it a visible option in Safari's UI (other browsers are of course free to
> > pick their own defaults). It's probably more useful for "power users" than 100%
> > cookie blocking. We'd certainly take patches to support the concept of that
> > mode in WebKit.
> 
> I would be in favor of this. What CFNetwork changes do you envision that aren't
> already handled by -[NSMutableURLRequest setMainDocumentURL:] and
> -[NSMutableURLRequest setHTTPShouldHandleCookies:]?

The proposal for the FOURTH cookie mode is "Don't send or accept any cookie from 3rd parties"

Yes, setting the main document URL is necessary to specify who the 1st party is.

But CFNetwork doesn't currently have the 4th mode.

[Adam Barth]

> Nothing in our networking layer uses the main document url for anything besides
> determining 3rd party cookie policy.

Isn't it a layering violation to know that?  (Although I've never understood
why a URL request should know anything about documents, much less main
documents, so I might not understand the layering abstractions here.) 
Regardless of what we use the field for currently, that line of code is, on
it's face, inaccurate.

> > > Also, w.r.t. <http://code.google.com/p/chromium/issues/detail?id=37684>, I'm
> > not sure I'd recommend that Chrome loosen its non-default, block-on-write third
> > party cookie policy to match this new behavior because the compatibility cost
> > isn't as acute.  That means Chrome and Safari's third-party cookie policies
> > will likely diverge, which is bad for the web platform.
> 
> In that bug, the reporter mentions "for all I know, chrome already has this
> relaxed behavior?"
> 
> Does it?

As far as I know, previous to this change, Chrome's third-party cookie blocking
matches Safari's.  Chrome has a "default deny" implementation, so it takes a
while to flesh out all the bugs w.r.t. URL requests from plug-ins, workers,
etc, but the intent is/was to match Safari identically.

> > I'm not sure I'd recommend that Chrome loosen its non-default, block-on-write third
> > party cookie policy to match this new behavior because the compatibility cost
> > isn't as acute.  
> 
> I don't understand how - if the cookie policies of Chrome and shipping
> Safari/WebKit are identical - that Chrome doesn't have the same facebook.com vs
> Facebook connect website incompatibility.  Can you explain how it doesn't?

Is that an issue fixed by this patch?  I see a vague reference above that this
patch helps Facebook, but nothing specific about Facebook connect.

The broader answer is that because the feature is not enabled by default,
Chrome's incentives are to balance the privacy/compatibility trade off in the
direction of privacy because the folks who turn this feature on want better
privacy.  (Whether the feature actually delivers what they want is a separate
question.)

Maciej would tell me that I shouldn't be writing these posts without a goal in
mind.  I'm not sure I have a specific goal.  I don't see how you can avoid the
gravitational pull of fixing the compatibility issue at hand given the current
equilibrium.  However, there's another equilibrium that's a better global
social optimum and this is a step in the opposite direction.

[Jeff Johnson]

(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #21)
> > > We'll consider adding a stronger cookie blocking mode, though I think it would
> > > likely require CFNetwork changes to implement it on Mac, and UI approval to
> > > make it a visible option in Safari's UI (other browsers are of course free to
> > > pick their own defaults). It's probably more useful for "power users" than 100%
> > > cookie blocking. We'd certainly take patches to support the concept of that
> > > mode in WebKit.
> > 
> > I would be in favor of this. What CFNetwork changes do you envision that aren't
> > already handled by -[NSMutableURLRequest setMainDocumentURL:] and
> > -[NSMutableURLRequest setHTTPShouldHandleCookies:]?
> 
> The proposal for the FOURTH cookie mode is "Don't send or accept any cookie
> from 3rd parties"
> 
> Yes, setting the main document URL is necessary to specify who the 1st party
> is.
> 
> But CFNetwork doesn't currently have the 4th mode.

I apologize if I'm misunderstanding something, but my assumption was that this would be a WebKit preference rather than an additional NSHTTPCookieAcceptPolicy. The issue here seems to be a dispute over WebKit logic rather than a deficiency in CFNetwork code.

One possible implementation of the 'strict' WebKit cookie preference would be simply to call setHTTPShouldHandleCookies:NO for 3rd-party URL requests.

[Brady Eidson]

I'll send two separate replies, as one is objective and the other a point of debate.

(In reply to comment #26)
> > Nothing in our networking layer uses the main document url for anything besides
> > determining 3rd party cookie policy.
> 
> Isn't it a layering violation to know that?  (Although I've never understood
> why a URL request should know anything about documents, much less main
> documents, so I might not understand the layering abstractions here.) 
> Regardless of what we use the field for currently, that line of code is, on
> it's face, inaccurate.

Well, it's certainly no secret what the API is for:
http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Reference/Foundation/Classes/NSURLRequest_Class/Reference/Reference.html#//apple_ref/occ/instm/NSURLRequest/mainDocumentURL
http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Reference/Foundation/Classes/NSMutableURLRequest_Class/Reference/Reference.html#//apple_ref/occ/instm/NSMutableURLRequest/setMainDocumentURL:

Only VERY recently was this field renamed to "firstPartyForCookies" in WebCore.  That is certainly a more accurate name.  Imagine we could rename existing API.  Lets pretend instead of:
    CFURLRequestSetMainDocumentURL(newRequest, url);
... the line of code read:
    CFURLRequestSetFirstPartyForHTTPCookies(newRequest, url);

Would it then still be incorrect?  That line of code says "I want the networking layer to make 3rd party cookie policy decisions as if the 1st party was this URL", and that is intended.

I think the only problem is that the Mac/Windows ports implement this new policy using unfortunately named API.  We'll try to get it changed in future releases but that's an Apple internal matter.

[Brady Eidson]

(In reply to comment #26)

> Maciej would tell me that I shouldn't be writing these posts without a goal in
> mind.  I'm not sure I have a specific goal.  I don't see how you can avoid the
> gravitational pull of fixing the compatibility issue at hand given the current
> equilibrium.  However, there's another equilibrium that's a better global
> social optimum and this is a step in the opposite direction.

I think what you're trying to say is that you (and Chrome) would actually like to see this policy be more strict - no read, no write - and therefore move up into a new sphere of privacy.  And therefore you're disappointed in the conditional relaxation of it.

Disappointment noted.  

Since moving into that new sphere of privacy would also involve moving into a new sphere of incompatibility, Safari can't accept that change to its default cookie policy (for the same reasons that Chrome would probably be unwilling to make it the default there).

Also...

(In reply to comment #22)
> That means Chrome and Safari's third-party cookie policies
> will likely diverge, which is bad for the web platform.

This change makes Safari's DEFAULT cookie policy MORE compatible with the web platform.  I think this hyperbole unnecessarily limits the conversation by assuming as fact that there can only be a single 3rd party cookie policy in a browser.

Why can't a browser have the following 4 policies, listed by order of decreasing privacy:

1 - Accept all cookies.  An option in all browsers, and default for most users today.  Least amount of privacy.  Best compatibility.
2 - Send 3rd party cookies, but don't accept new ones.  Default in Safari. A small privacy increase over option #1.  Less compatibility.
3 - Don't send or receive 3rd party cookies.  Not currently implemented in any browser.  Definitely more privacy than #2.  Definitely worse compatibility.
4 - Never accept any cookies.  An option in most (all?) browsers, will always be there for the truly paranoid.  Absolute privacy (cookie-wise...) but also tons of broken websites.

Only #1 (most) and #2 (only Safari) are the default in major browsers.  How would tweaking #2 and adding the optional #3 be any worse for the web than what is already out there now?  Would Chrome having all 4 of these options be any worse for the web than having only 3 of them?  Would Safari having all 4 of these options be any worse for the web than having only 3 of them.

[Brady Eidson]

Maybe this discussion needs to move to webkit-dev - we're way past the scope of this bug at this point.

[Adam Barth]

> Only VERY recently was this field renamed to "firstPartyForCookies" in WebCore.

Yeah, I made that change after noticing a number of places in Chrome that were using the value assuming it had more natural semantics.

> I think the only problem is that the Mac/Windows ports implement this new
> policy using unfortunately named API.

IMHO, the networking layer should expose two flags:

1) Allow reading of cookies.
2) Allow writing of cookies.

The client can then mix and match those to its hearts content.  I've never really completely understood how redirects are handled, but I assume we'll get a chance to twiddle the mainDocumentURL at this codepoint on redirects (otherwise the patch has correctness issues).

BTW, does this patch affect the behavior of document.cookie, or just cookies received over the network?

> I think what you're trying to say is that you (and Chrome) would actually like
> to see this policy be more strict - no read, no write - and therefore move up
> into a new sphere of privacy.  And therefore you're disappointed in the
> conditional relaxation of it.
> 
> Disappointment noted.  

I'll need to think carefully about balancing our desire to keep WebKit a unified platform with the privacy costs (which I don't have a concrete way to measure).

> > That means Chrome and Safari's third-party cookie policies
> > will likely diverge, which is bad for the web platform.
> 
> This change makes Safari's DEFAULT cookie policy MORE compatible with the web
> platform.  I think this hyperbole unnecessarily limits the conversation by
> assuming as fact that there can only be a single 3rd party cookie policy in a
> browser.
> 
> Why can't a browser have the following 4 policies, listed by order of
> decreasing privacy:

Chrome actually used to have exactly those settings.  Under pressure from confused users and the UX team, we simplified the options to (1), (2), and (4).

> Only #1 (most) and #2 (only Safari) are the default in major browsers.  How
> would tweaking #2 and adding the optional #3 be any worse for the web than what
> is already out there now?

The main issue is that it increases the complexity and reduces the stability of the web platform.  For example, have you compared the behavior here to Firefox's third-party cookie blocking?  What about IE?  How is a web developer supposed to make their web site work in the face of all these fractured cookie policies?  Proximately, it improves compatibility in these cases, but in the long run, it introduces structural compatibility problems between browsers.

> Would Chrome having all 4 of these options be any
> worse for the web than having only 3 of them?  Would Safari having all 4 of
> these options be any worse for the web than having only 3 of them.

Every option has a cost because it increases complexity and expands the testing matrix for web developers.  In reality, the testing matrix is already too big, which is why we're seeing compatibility problems with Safari's default behavior.

Surely the long-term solution to compatibility problems is to increase interoperability among browsers rather than reduce it.

[Maciej Stachowiak]

(In reply to comment #24)
> (In reply to comment #21)
> > We'll consider adding a stronger cookie blocking mode, though I think it would
> > likely require CFNetwork changes to implement it on Mac, and UI approval to
> > make it a visible option in Safari's UI (other browsers are of course free to
> > pick their own defaults). It's probably more useful for "power users" than 100%
> > cookie blocking. We'd certainly take patches to support the concept of that
> > mode in WebKit.
> 
> I would be in favor of this. What CFNetwork changes do you envision that aren't
> already handled by -[NSMutableURLRequest setMainDocumentURL:] and
> -[NSMutableURLRequest setHTTPShouldHandleCookies:]?

It might be possible to implement an additional mode purely in WebKit without CFNetwork changes. If so, we'll take patches. Though exposing that mode in the Safari preferences UI would be gated on Apple.

[Maciej Stachowiak]

(In reply to comment #26)

> > 
> > I don't understand how - if the cookie policies of Chrome and shipping
> > Safari/WebKit are identical - that Chrome doesn't have the same facebook.com vs
> > Facebook connect website incompatibility.  Can you explain how it doesn't?
> 
> Is that an issue fixed by this patch?  I see a vague reference above that this
> patch helps Facebook, but nothing specific about Facebook connect.

Brady is probably hesitant to say what the specific issue is, since it was originally reported via Apple-internal channels. I'll make the call that it's worth saying what the bug actually is, since I'm sure external folks using Safari enough have experienced it. If a user is logged into Facebook, then under shipping Safari's default cookie policy, if they visit a Facebook connect site twice with a separation of an hour (or so), they will be logged out the next time they visit facebook.com. That's because Facebook attempts to refresh the login cookie fairly frequently, but the default cookie policy was preventing it from updating it. Note that it's not at all obvious *why* the logout happened - it took us an immense amount of debugging to narrow this down, starting with reports that just said "sometimes I randomly get logged out of facebook."

We also believe this change will fix other bugs with the current policy, where sites attempt to log the user out by overwriting an existing cookie with an expired one. Granted, we could address those cases with a much narrower exception.


> Maciej would tell me that I shouldn't be writing these posts without a goal in
> mind.  I'm not sure I have a specific goal.  I don't see how you can avoid the
> gravitational pull of fixing the compatibility issue at hand given the current
> equilibrium.  However, there's another equilibrium that's a better global
> social optimum and this is a step in the opposite direction.

I think it's fine to post without a goal in mind, but probably bug comments are not the best place. Might be good to discuss this on webkit-dev.

[Adam Barth]

Oh, that's an interesting bug.  Thanks for explaining.

[Eric Seidel (no email)]

http/tests/cookies/third-party-cookie-relaxing.html -> failed

is occasionally failing on the commit-bot when testing "does trunk actually build and test" which is done before applying the patch for commit.

This may be a more recent regression than this bug, or it may be flakey from this original checkin.

[Eric Seidel (no email)]

Looks like the new flakiness is from bug 26391.

[Brady Eidson]

(In reply to comment #36)
> Looks like the new flakiness is from bug 26391.

Please delete the ~/Library/Cookies/Cookies.plist file from whatever bot this is that's failing to clear the failure.

[Eric Seidel (no email)]

(In reply to comment #37)
> (In reply to comment #36)
> > Looks like the new flakiness is from bug 26391.
> 
> Please delete the ~/Library/Cookies/Cookies.plist file from whatever bot this
> is that's failing to clear the failure.

Done just now per your instructions.  I'll let you know if it reproduces.