668475 - Cookie handling in IFrames

Status: RESOLVED DUPLICATE of bug 1473978

(Core :: Networking: Cookies, enhancement, P3)

Description

[Martin von Gagern]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110627180347

Steps to reproduce:

The actual page I visited was http://www.securvita.de/egk/ but that page is in German, and might change or vanish before this bug here is fixed. So I'll describe things in a more general example.

1. Disable third party cookies
2. Visit page containing iframe from another domain, say outer.com/outer containing an iframe with the document inner.com/first. The inner.com/first document tried to set a cookie.
3. Press form button inside iframe, with the form submission directed to inner.com/second



Actual results:

inner.com/second requires the cookie set by inner.com/first, but with third party cookies disabled, FF5 won't send that cookie. So the page doesn't work.



Expected results:

Disabling third party cookies should prevent cookies being sent to inner.com in response to a page load for outer.com, as this would allow third-party user tracking. But interacting with the form inside inner.com should be a different matter.

I propose associating a kind of temporary cookie jar with every inner frame. Documents initially loaded into that iframe would store cookies in that temporary jar. When loading a different document inside that same iframe in response to some user action (as opposed to a javascript timeout or a reload meta tag), then the temporary jar is merged into the main cookie jar, and subsequent loads in that iframe will send cookies in just the way that top level documents do.

The rationale is that by interacting with the iframe, the user implicitely expressed a certain trust in that content. So it very likely isn't a tracking advertisement.

I'm not sure how much of the "reloade due to user interaction" machinery is present, but I guess one could start on the safe side with links and form submissions only, no scripting involved.

Comment 1

[Mildred Ki'Lya]

Somehow, cookies storage (cookies jar) should be handled by the DocShell (a good explanation of docshells is at https://bug463027.bugzilla.mozilla.org/attachment.cgi?id=523450 )

> ehsanjdm: do you know anything about our docshells?
> ehsanjdm: so they're this tree of objects which you can think about like document
> containers
> ehsanjdm: we have chrome and content docshells
> ehsanusually when you have a tab loaded in a browser window, we have a root docshell for
> browser.xul which is a chrome docshell
> ehsanwhich has a child for the content document which is open in a tab
> ehsanjdm: and things like iframe docs would have a docshell which is a child of the parent
> content docshell

Setting a cookie must be a message sent to the docshell. The default behaviour is to ask the parent docshell to store/get the cookie. The iframes would just change this implementation to use a temporary storage backend.

In the future, this would enable different tabs to have different cookie jars. This is what I'd like to see one day in Firefox.

I might want to look into this.

Comment 2

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 3

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 4

[Andrea Marchesini [:baku]]

Martin von Gagern, what you described 9 years ago is what we call ETP. We finally have something similar to what you describe.
See: https://blog.mozilla.org/blog/2019/09/03/todays-firefox-blocks-third-party-tracking-cookies-and-cryptomining-by-default/