- From: <bugzilla@jessica.w3.org>
- Date: Tue, 09 Dec 2014 01:08:54 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269
David Dorwin <ddorwin@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|adrianba@microsoft.com |ddorwin@google.com
--- Comment #4 from David Dorwin <ddorwin@google.com> ---
https://github.com/w3c/encrypted-media/commit/a27235240e0b178906ab98e7142bb58e9dafb1e1
normatively requires that distinctive identifiers be different by EME-using
origin, which is a step towards the requested combination of origins. Also, an
"iframe Attacks" section was added in
https://github.com/w3c/encrypted-media/commit/3580fd77fbe0c01ec12e34075d093b7d4a1bc2ec
We should continue to discuss how to address the underlying concern.
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.
* Introducing this new type of separation for this single purpose may be
problematic. For example:
i. Communicating this to the user could be difficult.
ii. User agent implementations may not support storage by such combinations.
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.
3. Appearing as a different user/device to the EME-using origin may have
undesirable results for the user.
Possible other solutions to the underlying problem include:
A. Blocking third-party access.
* see #user-tracking in the spec.
* This is similar to "Blocking third-party storage" in the Web Storage and
Indexed Database specs.
* It is simpler to prevent mixed origins than to partition based on origin
combinations.
* This may prevent legitimate use cases like the originally proposed solution.
B. User alerts and prompts may discourage abuse.
* Especially if based on a combination of origins, though this suffers many of
the same UX problems as the originally proposed solution.
* See #iframe-attacks.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 9 December 2014 01:08:56 UTC