Henri Sivonen: > > 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.
Is this sandbox architecture described anywhere? Is it just OS-level sandboxing, or are you also running Adobe's code in some kind of NaCl/asm.js/bytecode VM as well? > > 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. Hrmm. In theory, yes. But in practice, if you do not publish your exact build environment config and build machine setup scripts, as well as your Profile Guided Optimization files, even such manual verification will be extremely costly and tedious, and will be unlikely to actually happen with any frequency. In fact, if there is any component of Firefox that should have reproducible builds as a hard requirement, this seems like candidate 0. > > Will the CDM host source code be compiled by Mozilla, or Adobe? > > By Mozilla. Do you have a plan for producing AddressSanitizer+UBSanitizer and/or assert-enabled builds that are capable of using a live Adobe $EVILBLOB? We are considering providing AddressSanitizer-enabled Tor Browser builds, as both a hardening option, and to help us sniff out bugs. Would we be able to get the CRM host component in an ASAN+UbSan+Assert enabled form for use with these builds? > > 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). Ok, this makes sense then. Or at least, it makes as much sense as DRM can possibly make. > > 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. 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. In any world in which we allow this thing to run, we would want the ability to patch Tor Browser to additionally/alternatively salt the identifier with the URL bar domain, rather than just the iframe domain. To be completely clear, the salt is handed to the CRM host by browser code that we can modify, if we disagree with your decision on the iframe scoping of this salt? > >> > 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). Alright. This seems like it might actually be the most reasonable way to go, modulo CRM host build issues. -- Mike Perry
signature.asc
Description: Digital signature
_______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
