Henri Sivonen: > On Monday, May 19, 2014 2:43:19 PM UTC+3, Mike Perry wrote: > > I just saw > > https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/ > > and I'm a bit concerned. > > Note that a FAQ has now been appended to that post.
Unfortunately. The FAQ still does not answer most of my questions. > > Obviously, it will be simple enough for Tor Browser and other Free/Libre > > Firefox derivatives to disable this DRM mechanism, > > Many derivatives don't disable the NPAPI, though. Does Tor Browser? If > not, why not? We do in fact hard-block (via C++ patch) all NPAPI plugins from loading into the Tor Browser address space, except for Adobe Flash. We do allow the Flash plugin to load into the address space, but disable it by default through Mozilla's XPCOM plugin service APIs, and warn the user and ask for confirmation when they attempt to enable it. We also warn them again if they leave it enabled across a browser restart. Even when the plugin is enabled, Flash objects still default to click-to-play. Some members of the Tor community are not satisfied even with this compromise, as Flash has proven to be an utter disaster for browser security, and has an ignorant (if not actively malicious) attitude towards privacy issues and browser proxy settings. The fact that Adobe is still involved in this DRM scheme does not exactly inspire confidence in us for this reason, either. > Considering that the CDM will be sandboxed but NPAPI plug-ins aren't, > it would be more rational for Tor Browser to support downloading the > CDM than to support NPAPI plug-ins. After, all if the sandbox doesn't > have bugs and the networking goes over Tor, the CDM should be no worse > for privacy than cookies or IndexedDB (see below). It is still not clear to me after reading the FAQ that this is the case. As the FAQ also mentions, unless the CRM host sandbox binary is reproducible/deterministic, it is difficult to know for sure that it is providing whatever privacy properties the spec and source code claims. It will also be impossible to produce hardened builds of it with ASAN or similar mechanisms. Will the CDM host source code be compiled by Mozilla, or Adobe? > > but I'm worried about the long term effects of giving the web a > > persistent device identifier (which that blog post mentions, > > The post mentions it specifically to explain what we are doing about > it. To make we are doing clearer, we are: > 1) Making Mozilla code gather the device-identifying raw data instead > of letting the CDM have that level of system access. > 2) Hashing the Mozilla-code-gathered device-identifying information > together with a per-origin browser-generated secret and letting the > CDM see the hash. > 3) Allowing the user to clear the per-origin browser-generated secret > to have the browser generate a new one. (Doing this will introduce > latency to your next use of the CDM with the origin for which you > cleared the browser-generated per-origin secret.) Is there a bugzilla ticket and/or spec document that describes the implementation of this hashing mechanism? From what you've said, it sounds like the exact same per-origin secret will be re-generated after it is cleared, unless there is a randomized/salted input step to the hashing process that you did not mention? If the hash that is produced *is* salted, I am now wondering why the CDM host would need to gather device-identifying information at all? Also, what does "origin" mean in this context? Is a third party iframe considered to have the URL bar domain as its "origin", or is the "origin" here the one used by the same-origin policy (ie the iframe source url domain)? > > but I can't find direct reference to in the EME draft spec). > > EME doesn't specify DRM. It specifies an API for talking to a DRM > component (that it calls a CDM). It just happens that node locking > (making the user unable to migrate DRM keys from one device to another > on their own as opposed to re-requesting keys from the DRM server) is > a feature that Hollywood-approved DRMs tend to have. Node-locking as implemented by an extractable, persistent, unsalted identifier is a non-starter for us, and it also effectively criminalizes privacy for stock Firefox users, via the DMCA. > > It seems to me that a device identifier will quickly be abused by more > > than just streaming media sites. What will prevent banking sites, > > government sites, and even sites that are simply hostile to privacy from > > requiring the receipt of a device id before allowing access to their > > content? > > The CDM will be sandboxed and the ID the sandboxing host exposes to > the CDM will be > 1) not reversible to permanent device-identifying info (see "hash" above) > 2) compartmentalized per-site and resettable, so no worse as a > tracking identifier than the site setting a cookie or storing some > data in IndexedDB or localStorage. > > > Have these issues been considered? > > They have. In fact, we considered this such an important point that > addressing it was part of the initial announcement. Search for "By > contrast, in Firefox the sandbox prohibits the CDM from fingerprinting > the user’s device." in the very post you linked to! If the same identifier is re-generated for a given origin, it doesn't much matter. Again, the post is still not clear on this and other important privacy points, even with the FAQ addition. -- Mike Perry
signature.asc
Description: Digital signature
_______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
