1480901 - Perform storage permission checks for all subdomain components up to and including the eTLD+1

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Steven Englehardt [:englehardt]]

In Bug 1474651 we added a heuristic to grant storage access to tracking resources on example.com when the tracking domain is called by window.open from example.com. This bug relates to granting storage access by eTLD+1/public suffix + 1. If any subdomain of trackertest.org is opened via window.open, all other subdomains of trackertest.org should have storage access granted.

Expected functionality:
Storage access should only be granted to the eTLD.

Actual functionality:
Storage access is not granted to the eTLD+1 when a subdomain is opened. E.g. Storage access is not granted for trackertest.org when a window.open call happens to test.trackertest.org.

Steps to reproduce:

Unfortunately this requires a local server until Bug 1476967 is fixed. Download this page [0] and host via a local server (e.g. `python -m SimpleHTTPServer 80`).

Set these prefs (note that trackertest.org is on the TP list):
network.dns.localDomains = trackertest.org, test.trackertest.org
privacy.restrict3rdpartystorage.enabled = True

Visit: https://senglehardt.com/test/cookie_restrictions/bugs/noopener_and_strict_hosts.html.

Initial loads to trackertest.org on this page shouldn't include cookies. Click "subdomain of tracker page sets js cookie". Cookies access on senglehardt.com should be granted for trackertest.org, but it is not.

[0] https://senglehardt.com/test/cookie_restrictions/set_js_cookie.html

Comment 1

[(no longer active)]

(In reply to Steven Englehardt [:englehardt] from comment #0)
> In Bug 1474651 we added a heuristic to grant storage access to tracking
> resources on example.com when the tracking domain is called by window.open
> from example.com. This bug relates to granting storage access by
> eTLD+1/public suffix + 1. If any subdomain of trackertest.org is opened via
> window.open, all other subdomains of trackertest.org should have storage
> access granted.

Why?  Have you tested how Safari behaves here?

> Expected functionality:
> Storage access should only be granted to the eTLD.

FWIW I think the actual desired functionality is very much unclear here.  One could very well argue that if we allow storage access to one domain belonging to a tracker, why not allow storage access to all domains from that tracker as per out TP entitylist?  I would personally argue that the desired expected functionality here is whatever that gives us the desired web compat outcomes we're seeking.  Perhaps it would make sense to have a pref that would force us strip the tracking origin down to its eTLD+1 when performing these checks, but it's not quite obvious to me if that's desirable to ship as that gives more tracking capabilities than what we've implemented so far.

> Actual functionality:
> Storage access is not granted to the eTLD+1 when a subdomain is opened. E.g.
> Storage access is not granted for trackertest.org when a window.open call
> happens to test.trackertest.org.

FWIW, for code changes needed, I think we'd only need to modify this function: https://searchfox.org/mozilla-central/rev/f0c15db995198a1013e1c5f5b5bea54ef83f1049/toolkit/components/antitracking/AntiTrackingCommon.cpp#59.  The origin arguments may need to be stripped down to be eTLD+1.

Comment 2

[Andrea Marchesini [:baku]]

Attachment: etld.patch

Comment 3

[Andrea Marchesini [:baku]]

This patch is not ready, it breaks 1 cookie test, but maybe it could be a good starting point.

Comment 4

[Steven Englehardt [:englehardt]]

(In reply to :Ehsan Akhgari from comment #1)
> (In reply to Steven Englehardt [:englehardt] from comment #0)
> > In Bug 1474651 we added a heuristic to grant storage access to tracking
> > resources on example.com when the tracking domain is called by window.open
> > from example.com. This bug relates to granting storage access by
> > eTLD+1/public suffix + 1. If any subdomain of trackertest.org is opened via
> > window.open, all other subdomains of trackertest.org should have storage
> > access granted.
> 
> Why?  Have you tested how Safari behaves here?

Safari differs from both our current implementation and what I've suggested. The allow cookies for all subdomains of the "activated" origin. So doing a window.open() to tracker.example from example.com gives access to *.tracker.example (e.g., foo.tracker.example and foo.bar.tracker.example). Doing a window.open() to blah.tracker.example on example.com gives access to *.blah.tracker.example (e.g., foo.blah.tracker.example or blah.tracker.example) but NOT tracker.example.

> > Expected functionality:
> > Storage access should only be granted to the eTLD.
> 
> FWIW I think the actual desired functionality is very much unclear here. 
> One could very well argue that if we allow storage access to one domain
> belonging to a tracker, why not allow storage access to all domains from
> that tracker as per out TP entitylist?  I would personally argue that the
> desired expected functionality here is whatever that gives us the desired
> web compat outcomes we're seeking.  Perhaps it would make sense to have a
> pref that would force us strip the tracking origin down to its eTLD+1 when
> performing these checks, but it's not quite obvious to me if that's
> desirable to ship as that gives more tracking capabilities than what we've
> implemented so far.

That's a good point. Let's keep this a tight as possible unless webcompat forces us to make it more permissive.
 
> > Actual functionality:
> > Storage access is not granted to the eTLD+1 when a subdomain is opened. E.g.
> > Storage access is not granted for trackertest.org when a window.open call
> > happens to test.trackertest.org.
> 
> FWIW, for code changes needed, I think we'd only need to modify this
> function:
> https://searchfox.org/mozilla-central/rev/
> f0c15db995198a1013e1c5f5b5bea54ef83f1049/toolkit/components/antitracking/
> AntiTrackingCommon.cpp#59.  The origin arguments may need to be stripped
> down to be eTLD+1.

Comment 5

[(no longer active)]

(In reply to Steven Englehardt [:englehardt] from comment #4)
> (In reply to :Ehsan Akhgari from comment #1)
> > (In reply to Steven Englehardt [:englehardt] from comment #0)
> > > In Bug 1474651 we added a heuristic to grant storage access to tracking
> > > resources on example.com when the tracking domain is called by window.open
> > > from example.com. This bug relates to granting storage access by
> > > eTLD+1/public suffix + 1. If any subdomain of trackertest.org is opened via
> > > window.open, all other subdomains of trackertest.org should have storage
> > > access granted.
> > 
> > Why?  Have you tested how Safari behaves here?
> 
> Safari differs from both our current implementation and what I've suggested.
> The allow cookies for all subdomains of the "activated" origin. So doing a
> window.open() to tracker.example from example.com gives access to
> *.tracker.example (e.g., foo.tracker.example and foo.bar.tracker.example).
> Doing a window.open() to blah.tracker.example on example.com gives access to
> *.blah.tracker.example (e.g., foo.blah.tracker.example or
> blah.tracker.example) but NOT tracker.example.

OK, so I think if anything, we should implement that behavior.  (That actually makes sense to me!)

Comment 6

[Steven Englehardt [:englehardt]]

(In reply to :Ehsan Akhgari from comment #5)
> (In reply to Steven Englehardt [:englehardt] from comment #4)
> > (In reply to :Ehsan Akhgari from comment #1)
> > > (In reply to Steven Englehardt [:englehardt] from comment #0)
> > > > In Bug 1474651 we added a heuristic to grant storage access to tracking
> > > > resources on example.com when the tracking domain is called by window.open
> > > > from example.com. This bug relates to granting storage access by
> > > > eTLD+1/public suffix + 1. If any subdomain of trackertest.org is opened via
> > > > window.open, all other subdomains of trackertest.org should have storage
> > > > access granted.
> > > 
> > > Why?  Have you tested how Safari behaves here?
> > 
> > Safari differs from both our current implementation and what I've suggested.
> > The allow cookies for all subdomains of the "activated" origin. So doing a
> > window.open() to tracker.example from example.com gives access to
> > *.tracker.example (e.g., foo.tracker.example and foo.bar.tracker.example).
> > Doing a window.open() to blah.tracker.example on example.com gives access to
> > *.blah.tracker.example (e.g., foo.blah.tracker.example or
> > blah.tracker.example) but NOT tracker.example.
> 
> OK, so I think if anything, we should implement that behavior.  (That
> actually makes sense to me!)

I suggest we keep the current behavior (exact origin matching) unless web compat forces us to change to something more relaxed. Aside from matching Safari, are there other reasons you think their current behavior is preferable?

Comment 7

[(no longer active)]

It's not clear to me that our current behavior is better than Safari's.  I think there is some value in making sure that sites that have received some attention in order to make them work in Safari work well in Firefox, so the fewer differences we have in our heuristics the easier our webcompat road will be.