+++ This bug was initially created as a clone of Bug #724179 +++ In the case where a page embeds content from an unrelated domain (different TLD+1), including <img src=''>, <script src=''>, etc., we should attempt to enforce CORS; if the subresource's domain doesn't allow the load, but it is a cross-domain load that we would normally do without enforcing CORS (e.g. <image src="" hotlinking), then we should load the cross-domain resource without sending any cookies or HTTP auth credentials, and without allowing any cookies (or HTTP auth credentials) to be set (or requested) by the response. AFAICT, most of our motivation for continuing to support these cross-domain embeddings without enforcing CORS is to allow hotlinking of images. I bet it is rare that the user ever benefits from sending cookies and HTTP auth credentials in those requests. Note that this proposal wouldn't stop image-based trackers (tracking pixels, banner ads) from working; it would only push them to supporting CORS. See also bug 647010.
(In reply to Brian Smith (:bsmith) from comment #0) > AFAICT, most of our motivation for continuing to support these cross-domain > embeddings without enforcing CORS is to allow hotlinking of images. ... and CDNs, of course.
This would incidentally solve the "check whether you're logged into Facebook using image onload" problem... if we can get away with it. The possible compat issues here worry me.
Images might be ok here, but with all the JSONP loading going around I'm almost certain that disabling cookies would "break the web". I have heard something about microsoft doing something like this, but that they added smarts to figure out when to send cookies and when not to. I never understood how that logic worked though, and if it was successful.
(In reply to Jonas Sicking (:sicking) from comment #3) > I have heard something about microsoft doing something like this, but that > they added smarts to figure out when to send cookies and when not to. I > never understood how that logic worked though, and if it was successful. Sounds interesting, do you remember where do you heard/read about this? MSDN, EricLaw's IEInternals blog, …?
It was in a direct conversation with Eric iirc. So we can probably ask him.
Component: Security → DOM: Security
Whiteboard: [fingerprinting] → [fingerprinting][domsecurity-backlog]
Brian, why this is tagged as fingerprinting?
Could the IE thing possibly be: > Q7: My site is not receiving cookies when it is running in an IFRAME and the parent page is from a different domain. Why? > > A: Internet Explorer has restrictions on “3rd party” cookies. 3rd party cookies are cookies which are set or sent for resources from a different domain than the top-level browsing context. You can easily confirm P3P/Cookie restrictions as the root cause of such issues by temporarily changing IE’s Tools / Options / Privacy setting to “Accept All Cookies”. > > In order to allow such cookies to be sent reliably, you should send a P3P header when setting the cookie. https://blogs.msdn.microsoft.com/ieinternals/2009/08/20/internet-explorer-cookie-internals-faq/
Whiteboard: [fingerprinting][domsecurity-backlog] → [domsecurity-backlog]
Christoph, I'm going to kick this to you for help determining if this is still valid.
No longer blocks: 1329996
This approach causes too much real-world breakage, as we've seen in attempts to restrict 3rd party cookies more broadly. We're now trying an approach on restricting these to "known trackers" that seems more successful.
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.