1308607 - When "privacy.firstparty.isolate" is true, key permissions to first party domain, not origin (Tor 20317)

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect, P3)

Description

[Arthur Edelstein [:arthur]]

Here's my proposal from https://trac.torproject.org/20317:

In Firefox (and current Tor Browser), permissions are keyed by origin. That is a tracking vector -- for example, on Google maps, if click on the "Show your Location" button, the browser prompts, "www.google.com: Would you like to Share your Location with this site?" If we choose "Always Share Location", then this permission is stored, keyed to www.google.com.

Now the UI says "this site", which is, to my ear, synonymous with "first party domain". But now on other sites, any third-party iframe from www.google.com (such as created by a Google Analytics script or a Google+ button) can obtain our location. And, further, it can expose a function call (using iframe postMessage tricks) that any other script on the same page could call to obtain our location. So in practice, we have given permission for any domain embedding an appropriate Google script to obtain our location. And the very existence of the unusual permission setting, or any other, helps to track our browsing history across domains.

So I would like to propose that, when "privacy.firstparty.isolate" is true, Firefox should key every permission by first-party domain instead of origin domain. That means that the Permissions UI doesn't need to change at all. We are still assigning each permission to a single domain. But this way, granting a permission to google.com would not leak to every other site.

And I would argue that this is already the perception of most users when they see a permission requested for "this site". Most users are not knowledgeable about the subtleties of third-party scripts -- they expect a permission to apply to the site they are visiting (the first party).

Here's a demo that works on Firefox (not Tor Browser, because we don't have navigator.geolocation exposed).

First visit
​https://torpat.ch/geolocate.html
And choose "Always Share Location" for torpat.ch.

Now visit
​https://arthuredelstein.github.io/tordemos/geolocate.html
The iframe runs the same torpat.ch page to obtain location, and then uses postMessage to send the location to the parent page, at arthuredelstein.github.io.

(When you are done, be sure to revoke permissions to torpat.ch! :))

Comment 1

[Ethan Tseng [:ethan]]

Arthur, thanks for filing this bug.

(In reply to Arthur Edelstein [:arthuredelstein] from comment #0)
> And I would argue that this is already the perception of most users when
> they see a permission requested for "this site". Most users are not
> knowledgeable about the subtleties of third-party scripts -- they expect a
> permission to apply to the site they are visiting (the first party).

If your assumption is true, isolating permissions by first party domain should not break the web.
(in the perspective that most users would not realize anything goes wrong)

According to your previous discussion, is there any special use case that isolation might cause
users' attention?
If not I think this is a decent proposal.

Comment 2

[The 8472]

>  Firefox should key every permission by first-party domain instead of origin domain.

Shouldn't that be s/instead of/and/?

There's no reason to grant permissions to some iframes at the same time as the top level domain or vice versa unless they're asking for it.

Comment 3

[Tanvi Vyas[:tanvi]]

When adding a permissions check for First Party Isolation, please make it general to Origin Attributes, so that each Origin Attribute can choose whether it wants to isolate permissions or not.  Thanks!

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Arthur Edelstein [:arthuredelstein] from comment #0)
> Now the UI says "this site", which is, to my ear, synonymous with "first
> party domain".

We should file a bug on geolocation to be more specific, like our gUM prompts are (they show the origin).

E.g. https://jsfiddle.net/srn9db4h/ asks to share with fiddle.jshell.net (not jsfiddle.net) because that's where its iframe is.

> But now on other sites, any third-party iframe from
> www.google.com (such as created by a Google Analytics script or a Google+
> button) can obtain our location. And, further, it can expose a function call
> (using iframe postMessage tricks) that any other script on the same page
> could call to obtain our location. So in practice, we have given permission
> for any domain embedding an appropriate Google script to obtain our
> location. And the very existence of the unusual permission setting, or any
> other, helps to track our browsing history across domains.
> 
> So I would like to propose that, when "privacy.firstparty.isolate" is true,
> Firefox should key every permission by first-party domain instead of origin
> domain.

I think this is a good idea regardless of "privacy.firstparty.isolate". In fact, the mediacapture spec now requires us to do this for gUM (bug 1299577).

> That means that the Permissions UI doesn't need to change at all. We
> are still assigning each permission to a single domain. But this way,
> granting a permission to google.com would not leak to every other site.
> 
> And I would argue that this is already the perception of most users when
> they see a permission requested for "this site".

Sadly we'd probably need to show both origins in the prompt (see bug 1299577 comment 6), to cover the case of a deceptive banner ad on a reputable site asking for permission.

Comment 5

[Daniel Veditz [:dveditz]]

As formulated I don't think this suggested change works. We can "double-key" permissions, but we can't just say 3rd parties should use the permissions set for the first-party. The user might trust the first party, but there could be tons of 3rd parties (ads!) they don't trust.

UX confusion about who is asking in a permission prompt is an issue, which for some items we're deciding by saying 3rd parties simply can't ask for those things. But internally we need to know the difference because there is a distinction. Cookie-setting permissions, for example.

Comment 6

[Arthur Edelstein [:arthur]]

(In reply to Daniel Veditz [:dveditz] from comment #5)
> As formulated I don't think this suggested change works. We can "double-key"
> permissions, but we can't just say 3rd parties should use the permissions
> set for the first-party. The user might trust the first party, but there
> could be tons of 3rd parties (ads!) they don't trust.
> 
> UX confusion about who is asking in a permission prompt is an issue, which
> for some items we're deciding by saying 3rd parties simply can't ask for
> those things. But internally we need to know the difference because there is
> a distinction. Cookie-setting permissions, for example.

Yes, I think I am persuaded that we need to double-key permissions. I am closing this bug and I have opened bug 1330467 for double-keying.