[Bug 27269] Normatively require distinctive identifiers to be different by top-level and EME-using origin

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269

--- Comment #6 from David Dorwin <ddorwin@google.com> ---
(In reply to Henri Sivonen from comment #5)
> (In reply to David Dorwin from comment #4)
> > While using a combination of origins may address the concern, there are
> > potential problems:
> > 1. Other storage mechanisms (cookies, etc.) are not unique per combination.
> 
> Well, cookies are so broken that they aren't even clamped to an origin!
> Still, the Web Platform has been able to introduce other things that have
> origin-based security.

Yes, origin-based, but not (origin x origin)-based.
> 
> >  * Introducing this new type of separation for this single purpose may be
> > problematic.
> 
> Chances are that it's a bug that this kind of separation isn't being used
> for other things, too. Quoting Mike Perry from
> https://groups.google.com/d/msg/mozilla.dev.privacy/3jA9zt1pXVo/tD0buhEMfMEJ
> :
> > For the record, in Tor Browser we are also trying to demonstrate that it
> > is possible to provide the same third party tracking protections as "Do
> > Not Track" through technology, rather than policy.
> >
> > In other words, we have jailed/double-keyed/disabled third party
> > cookies, cache, DOM storage, HTTP Auth, and TLS Session state to the URL
> > bar domain, to eliminate third party tracking across different url bar
> > sites.

It is possible that some implementations or standards efforts will seek to
introduce this separation across the web platform. This comment was about
introducing it for one specific API without also enforcing it for other APIs,
especially "storage" APIs.
> 
> (Back to quoting David Dorwin:)
> > For example:
> >   i. Communicating this to the user could be difficult.
> 
> My recollection is that I've even seen a UI design *for Chrome* for a scoped
> permission (for geolocation) like this in a paper co-authored by Adrienne
> Porter Felt, but now I can't find such a paper.

Thanks. I will look into this.
> 
> >   ii. User agent implementations may not support storage by such
> > combinations.
> 
> Well, a priori, UAs don't support CDM interfaces, either. Code needs to be
> written to support new things.
> 
> > 2. All CDM storage must be similarly separated.
> >  * This is more complex than just salting an identifier.
> >  * See also #1.
> >  * See also #incomplete-clearing in the spec.
> 
> You store a salt per top-level + EME-calling origin pair. Then you give a
> CDM storage partition for each salt.
> 
> > 3. Appearing as a different user/device to the EME-using origin may have
> > undesirable results for the user.
> 
> Do you have examples?

Some hypotheticals:

1) Suppose there is some service that provides protected content services for
other websites. Maybe the user somehow has a relationship with that service.
With the proposal in this bug, that service would see different distinctive
identifiers when hosted on example.com, foo.com, and foobar.com. If the service
limits the number of "devices" a user can use in some period of time, the user
would unknowingly use up three "devices". (Note that this can also happen if
identifiers are cleared or as a result of using private browsing modes *if* the
user agent allows distinctive identifiers in such a mode.)

Related to potential problem #1, the cookies, local storage, IndexedDB, etc.
would all be the same even though the distinctive identifier is different.

This could potentially be a problem even for a standalone site. For example,
www.example.com and browse.example.com might both host an iframe for
player.example.com.

Note: Presenting the pair of origins in UX for clearing data may actually be
beneficial in this case. A user may mistakenly clear data for a service named
contentprovidingindustriesllc.com but might be more cautious if it was paired
with a recognized site like example.com. (The same might apply to permission
prompts.)

2) Data, such as a persistent license, stored from offline.example.com would
not be accessible and/or appear invalid from www.example.com even if they both
iframe player.example.com. The user could lose that license and potentially the
ability to get a new one if the website architecture changed or the user can't
figure out that they need to go back to offline.example.com.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 12 December 2014 23:05:17 UTC