318574 - Cookie pref for "Ask before accepting" overrides "Accept only from sites you visit"

Status: RESOLVED WORKSFORME

(Core :: Networking: Cookies, defect)

Description

[Chris Lawson (gone)]

In Privacy prefs, if "Ask before accepting each cookie" is checked, *all* cookies will be asked about, even those originating from a third-party server. This is contrary to the user's wishes if "Accept only from sites you visit" is checked, as that user has no desire to accept third-party cookies in the first place (and therefore shouldn't be asked about them).

If we decide to fix bug 174070, we'll need to be careful to avoid exacerbating this behaviour or regressing this bug.

Comment 1

[Samuel Sidler (old account; do not CC)]

I think we're doing the Right Thing here. If a user checks "Ask before accepting each cookie" and doesn't get asked before accepting... each cookie, that's going to be against expectations. What we should be doing is only asking for cookies from that site and rejecting all other cookies.

Comment 2

[Chris Lawson (gone)]

(In reply to comment #1)
> I think we're doing the Right Thing here. If a user checks "Ask before
> accepting each cookie" and doesn't get asked before accepting... each cookie,
> that's going to be against expectations. What we should be doing is only asking
> for cookies from that site and rejecting all other cookies.

Ah, yes, I think we misunderstood each other. I completely agree with the above. We should automatically REJECT third-party cookies without asking, and ASK for cookies set by the visited site.

Allow me to run through an example of what we SHOULD do IMO:

Say I have "Accept only from sites you visit" and "Ask before accepting" checked.

1) I browse to www.example.com, which has third-party advertisements on the page served from adserver.domain.com.

2) www.example.com wants to set a cookie, so I get a sheet asking "Do you want to allow www.example.com to set a cookie?"

3) I dismiss the sheet somehow (either by clicking "Deny" or "Accept").

4) adserver.domain.com *also* wants to set a cookie, but since this is a third-party cookie, it should respect my pref of "Accept only from sites you visit" and reject the cookie without asking.

What we currently do for step 4 is the same as for step 2, which IMO is wrong.

cl

Comment 3

[Simon Fraser [no longer active]]

I'm surprised the backend doesn't work this way already. Well, I'm not surprised, but it seems like it should.

Comment 4

[Chris Lawson (gone)]

(In reply to comment #3)
> I'm surprised the backend doesn't work this way already. Well, I'm not
> surprised, but it seems like it should.

Should this be kicked over to Core, then, and we'll get it when it's fixed there?

Or do we want to go ahead and fix it on our own now, and then change things again when (if) the Core fix lands?

cl

Comment 5

[Stuart Morgan]

My recollection from when I updating Camino's cookie interface during The Great Core Cookie Pref Rearrangement of '04 was that the logic about precedence of cookie prefs was really convoluted but all intentionally designed. I wouldn't be at all surprised if this is deliberate core behavior.

Comment 6

[Simon Fraser [no longer active]]

Yeah, and I don't think we can fix this outside of core. All we get is an upcall to show the cookie sheet.

Comment 7

[Chris Lawson (gone)]

Kicking over to Core, cc'ing mconnor as suggested by Stuart.

Comment 8

[Mike Connor [:mconnor]]

As reported, the bug is closer to invalid than a dupe.  The foreign cookie restriction is checked when we call CheckPrefs, well ahead of when we talk to the permission manager code that calls the dialog.  These probably aren't foreign cookies within the HTTP channel.

The reason it seems that you're seeing this is because if you have content from bar.com, even if its called from a document on foo.com (iframe, etc) then bar.com will be able to set a cookie as part of the http request fetching the content.  Cookies are set and retrieved on a per-connection basis, so the user expectation surrounding the third-party pref is often violated.  Its a known bug, on record since forever.  (Its not considered completely fixable, either. (See Bug 158463))

Comment 9

[Chris Lawson (gone)]

If no one has any objections, I'm going to kick this back to Camino and reopen it, where we may have some hope of generating an internal solution if Core can't (or won't) work around this.

cl

Comment 10

[Darin Fisher]

Is the cookie permission callback insufficient to allow you to solve this bug in your application?

http://lxr.mozilla.org/mozilla/source/netwerk/cookie/public/nsICookiePermission.idl

Perhaps this is a bug in the default nsICookiePermission implementation?

Keep in mind that nsICookiePermission allows apps to completely override the cookie blocking behavior.  Thunderbird implements its own version of this interface.  The default however is designed for the web browser, so we should probably fix this bug there.  Though, off-hand, I don't know for sure.

Reopening

Comment 11

[Darin Fisher]

> The reason it seems that you're seeing this is because if you have content 
> from bar.com, even if its called from a document on foo.com (iframe, etc) 
> then bar.com will be able to set a cookie as part of the http request 
> fetching the content.

Mike, we set nsIHttpChannelInternal::documentURI so that the cookie code can see what the toplevel HTTP request is for any given sub-document request.  This enables the cookie module to apply third-party cookie blocking rules.  Perhaps it is the case that there are bugs in the way we assign documentURI.

Comment 12

[Darin Fisher]

-> default owner

Comment 13

[Stuart Morgan]

*** Bug 356526 has been marked as a duplicate of this bug. ***

Comment 14

[[e-mail]]

this is a valid bug; it shouldn't be happening. the logic is set up such that the nsICookiePermission implementation is called before anything else; if this has nothing to say about the cookie, then we fall back to third-party checks etc, which (in this case) should nix the request right there. we shouldn't be getting to the point of throwing a dialog, which occurs (logically) much later.

having said that, this WFM on linux trunk. cl, are you still seeing it? (you can use the URL in bug 143985 as a third-party testcase.)

Comment 15

[[e-mail]]

smorgan confirms that this is WFM for him on camino trunk. so, i'm closing this out as WFM; if anyone still sees it, please reopen.

Comment 16

[Chris Lawson (gone)]

Sounds good to me. I quit using the "ask" pref a long time ago because it was way too annoying, and now I don't care enough to look into it any further :-p