- 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