explicit-explicit exception pairs

I've done a quick writeup for ACTION-173 to describe the problems around
(explicit,explicit) exception pairs, including a screenshot of what I view
to be our rather problematic attempt at applying this to geolocation
permissions in Chrome. The writeup with screenshots is at
https://docs.google.com/document/d/19mNwTiZgYsrhgYDQHTljuId49DFDrApoTRZrVl-tniA/edit

I've included the contents below, but I suspect it will probably get munged
by mailing lists and drop images etc. You're probably better off viewing
the google doc via the link above, but for the sake of archival I've copied
the body into this email.


  *Perils of cross-products in settings

We made what I now believe to be a mistake in our implementation of the W3C
Geolocation API. We thought it would be a great privacy feature to remember
permissions granted to third parties (e.g. iframes) on a page only in the
context of their embedding page. That is, if outer.com iframes inner.com,
and inner.com requests access to your location, what we currently have is a
prompt in the browser saying “inner.com wants to access your location”, and
if you accept, the browser remembers that inner.com can access your
location when inner.com is on outer.com. We wanted to prevent a user’s
location from being tracked across the web, which I believe was a good
goal, but in the end we ended up with a very confusing user experience. The
user is asked about inner.com but they see outer.com in the address bar and
may not know what inner.com actually represents, and our UI in settings is
even more complex, a screenshot of which is included below: (see the
“html5demos embedded on ianfette.com”)

Luckily, the number of sites that actually request geolocation information
is relatively low, and the percentage of users that go into settings to
change this is also low. However, this has created awful UI that none of us
are happy with, and many complications internally in the code. (Whereas for
most things we simply store whether a particular site has a particular
permission, we now have to pass around additional state that indicates what
site the resource is embedded in. It sounds trivial but it’s not, and has
been the source of subtle bugs.)

This type of UI also leads to user confusion and suboptimal handling of
real use cases. For DNT in particular, I believe that a site wishing to
obtain exceptions for third parties will most likely wish to obtain
exceptions for all of the third parties on the site. As a concrete example,
a site author may believe they will only achieve a sufficient level of
monetization via mechanisms requiring an exception to DNT:1, and so they
may wish to request exceptions for the ads that will be shown on the page.
If they don’t get an exception, they may instead offer the user
alternatives (sign in, pay, get some amount of views free, etc.) Given that
this is rather burdensome imposition on the user (some form of interaction
required before they can view the content), the site is incentivized to
ensure that the user is asked as few questions as possible. The site
doesn’t want to come back tomorrow and say “My ad network now includes this
other third party so let me re-prompt” (assuming the site even is capable
of enumerating the third parties that may be included through the ad
network). So, the site will request mysite/* to indicate all third parties
on the site. The site also doesn’t want to get into a state where they have
to support some exponential number of configurations (“A is allowed but not
B, C is allowed and so is D but not E...”). Furthermore, before serving
content, the site will wish to know whether its required exceptions have
been granted or not. Having to serve javascript to the user to do polling
is a non-starter as it introduces a round-trip. Keeping things to mysite/*
makes it trivial for the browser to indicate whether the site has the
exceptions it needs, otherwise the browser has no way of knowing whether
the site will be satisfied as the browser doesn’t have a-priori knowledge
of what resources will be requested by the site so the browser cannot
indicate the status to the site on the initial request.

>From the user’s perspective, if a site wishes to request exceptions for
even a very limited ad exchange containing ten entities, I’m not sure how
we would display any UI that would allow for a usable experience while also
offering any meaningful choice. The notion of having ten checkboxes on an
infobar scares the daylights out of me from a usability perspective.The
management UI that we did for geolocation would become even worse, given
the large number of third parties that are likely to be involved compared
to the relatively few number of sites using the geolocation API. In short,
I’m convinced this is a path we should not follow.

Instead, I propose that we limit ourselves to firstparty/* (all third
parties on this first party) and */thirdparty (this third party on all
contexts). It’s very easy for a user to understand “I am giving an
exception everything comprising this site” since the user perceives the
site as a single website, not a collection of resources from multiple
origins. It’s also easy for a user to understand “I am giving an exception
to this widget” as the widget is likely something they’re familiar with,
e.g. a gadget from a social network or other third party site they interact
with. This is also easy to message to the user in an understandable and
concise way, and easy to provide management UI that is intelligible and
allows users to later change their mind. (“Here’s a list of sites you have
granted exceptions to. Here’s another list of third party thingamajiggers
you have granted exceptions to.” Both are linear, you don’t get the “list
of 100 common exceptions * top 500 websites = 50000 lines of scrolling
uselessness” instead you get perhaps “here’s the 10 sites I frequent that
have requested an exception, here’s the 4 widgets I trust and have granted
exceptions to.” Yes, this does mean you don’t have an easy way to say
“Trust this widget for everything except the following websites” but I
frankly think that’s a niche case, and if you don’t trust the privacy
controls that the widget gives you, you probably shouldn’t grant it a
web-wide exception. Or, you can do your sensitive browsing in a mechanism
supported by the browser for that purpose (another profile, “incognito” or
“private” browsing, etc.)*