295558 - Suppress cookie dialog for prefetched documents

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P5)

Description

[Darin Fisher]

Suppress cookie dialog for prefetched documents

I think we should consider making nsCookiePromptService::CookieDialog refuse to
accept cookies if the parent window parameter is null.  Or, we should make the
caller do this check.  Another choice would be to inspect the channel passed to
nsCookiePermission::CanSetCookie to see if it doing prefetching.

Thoughts?

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

why does prefetch's channel have notificationCallbacks set? and if it doesn't,
why is there a cookie dialog? (I don't think prefetch should show nsIAuthPrompt
dialogs either...)

Comment 2

[Darin Fisher]

> and if it doesn't, why is there a cookie dialog?

it doesn't have it set.  the cookie dialog code uses windowwatcher to get a
parent dialog if non is supplied.  see my suggested fix in comment #0.

i think there is no auth prompt for prefetched documents precisely because there
are no notification callbacks assigned on the channel, and there is no load
group either.

Comment 3

[Hixie (not reading bugmail)]

Wasn't there a bug where it was agreed that prefetching should just delay the
cookie stuff until the page was really loaded, at which time the headers should
take effect?

Comment 4

[Hermann Schwab]

(In reply to comment #3)
> Wasn't there a bug where it was agreed that prefetching should just delay the
> cookie stuff until the page was really loaded, at which time the headers should
> take effect?

That would be my understanding of privacy. 
Why tell users they can block cookies whenever they understand how to, when
websites just can set the prefetch labels to enable prefetching  of content and
silent cookies related to that content, if I correctly understand the topic of
this bug.

Comment 5

[Darin Fisher]

the default behavior would be to block cookies when prefetching if there is no
available prompt.

Comment 6

[Hixie (not reading bugmail)]

> the default behavior would be to block cookies when prefetching if there is no
> available prompt.

That doesn't sound right. The behaviour as far as the user sees should be
indistinguishable when we do prefetching and when we don't, with the exception
of the prefetching being faster. That means prompts appearing in the same
places, cookies being set in the same places, etc. Most notably for this case,
it means prompts appearing after the user clicks the link, not before, and
cookies being set after the user goes to the page, and not before.

Comment 7

[[e-mail]]

sorry if i'm out of touch here... can we store the headers somewhere and 'play'
them to the cookieservice (and other services of interest) on user click?

i'm unsure what's involved in caching them for this purpose, but it seems like
the cleanest solution.

of course, dialogs should die, but that's a separate argument ;)

Comment 8

[Gervase Markham [:gerv]]

Would it be better (for this, security and other reasons) to just not do
cross-domain link prefetching?

Gerv

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 10

[Adrian Chadd]

pre-fetched URLs are possibly being given the oppertunity to set cookies before the user actually visits the page in question.

Eg - google currently seems to use prefetch for the first URL in the search results and I do see sites setting cookies via the prefetch reference. This wouldn't be so much of a possible privacy violation but this allows a site in another domain (ie, not the domain you're looking at right now, so not google.com as an example) to set a cookie without you having visited that site.

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

this could be fixed using the new LOAD_ANONYMOUS flag from bug 389508