On Tue, May 20, 2014 at 5:33 PM, Mike Perry <[email protected]> wrote: > Is this sandbox architecture described anywhere?
Not really apart from the Hacks post, this thread and the thread on the governance list. > Is it just OS-level sandboxing Yes. >, or are you also running Adobe's code in some kind of > NaCl/asm.js/bytecode VM as well? No. >> > 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. I don't see a reason (other than people being busy) for us not to document our build environment. With proprietary systems, providing outright VM images probably wouldn't work, I imagine. > In fact, if there is any component of Firefox that should have > reproducible builds as a hard requirement, this seems like candidate 0. My understanding is that the actual first focus is/will be OpenH264 so that we could both not sandbox it and not have to tell users to trust a non-Mozilla entitity. >> > 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? I'll put this on my list of things to ask Adobe about. > 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. Cool. > 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? As currently planned, you should be able to do that. Each new salt results in some server load-causing initialization, so the main concern I see is unhappiness over making the system more chatty in a way that translates into server load (and user-perceived latency, but considering that Tor itself adds latency to buy privacy, I expect you to be OK with added user-perceived latency to buy privacy). -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
