Suppress cookie dialog for prefetched documents

RESOLVED WONTFIX

Status

()

Core
Networking
P5
minor
RESOLVED WONTFIX
13 years ago
2 years ago

People

(Reporter: Darin Fisher, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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?
(Reporter)

Updated

13 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta3
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...)
(Reporter)

Comment 2

13 years ago
> 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.
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

13 years ago
(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.
(Reporter)

Comment 5

13 years ago
the default behavior would be to block cookies when prefetching if there is no
available prompt.
> 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

13 years ago
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 ;)
Would it be better (for this, security and other reasons) to just not do
cross-domain link prefetching?

Gerv
(Reporter)

Updated

12 years ago
Target Milestone: mozilla1.8beta3 → mozilla1.9alpha
*** Bug 313577 has been marked as a duplicate of this bug. ***
Depends on: 313414
(Reporter)

Updated

12 years ago
Priority: -- → P5
(Reporter)

Updated

12 years ago
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Target Milestone: mozilla1.9alpha → ---

Comment 10

10 years ago
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.
this could be fixed using the new LOAD_ANONYMOUS flag from bug 389508

Updated

9 years ago
Blocks: 463117
No longer blocks: 463117
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.