On Tue, May 20, 2014 at 3:22 PM, Mike Perry <[email protected]> wrote: > We do in fact hard-block (via C++ patch) all NPAPI plugins from loading > into the Tor Browser address space, except for Adobe Flash.
Oh. Interesting. > 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. Then you have a way to run Adobe Access DRM without a Mozilla-controlled sandbox. > 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 CDM not having network access on its own (i.e. its communications with the outside world will be mediated by Firefox) will be an improvement then. > 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. Correct, except if you get close enough to the same build environment and parameters as Mozilla, you might be able to convince *yourself* that the Mozilla-provided executable was built from the disclosed source even if you fall short of convincing the *CDM* that your build was. > Will the CDM host source code be compiled by Mozilla, or Adobe? By Mozilla. > Is there a bugzilla ticket and/or spec document that describes the > implementation of this hashing mechanism? Not yet. > 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? The plan is to generate the secret randomly and remember (in the browser) which origin has which secret associated with it. That is, the secret will work as a per-origin salt to the hash of the device-identifying info. > 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? The salt comes from the browser, which is assumed to be controlled by the user. It is the User Agent, after all. The user is the adversary in the DRM threat model. Therefore, the anti-cloneability of the identifier cannot depend on browser-provided data (i.e. it has to have some CDM host-gathered device-specific data hashed into it). > 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)? To be decided. >> > 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. Salted and semi-persistent (persists until the user asks the salt to be forgotten). -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
