-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can the CDM communicates back to base itself? If it can then it can send the salt, along with any other data it has collected. Can it collect web history data in any way? If so there should be some contingency on DNT. A salt delete API (no read access) would make that available to open source privacy extensions such as EFF's PrivacyBadger.
Mike baycloud.com > -----Original Message----- > From: dev-privacy [mailto:dev-privacy- > [email protected]] On Behalf Of Henri > Sivonen > Sent: 21 May 2014 18:01 > To: [email protected] > Subject: Re: Did W3C EME just criminalize privacy? > > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJTfQU+AAoJEHMxUy4uXm2JXMEH/irjUcDk6KR51hIaM6zyQp6p ah0uZsh8ceIcQ9Zyzk+3tUCArE8SnmsOf5gLUzVRXaAB2/ORkKjUSpzU8xdFKscd UxJ+kes3E9Z7EJ3qwmYMq1gebUS1TYIEH0cNfOUlCGAhYX8v+Y2meFQ6M6jMzIPp ZYgyFpjjHvxX4yNSUEYaTMaQhJ79YwzUXC9u8bReguLOQ4u6JzbyygyqZd9Bqn+t FcEpcL54ESMtQEuJ9NsO1DeMm5HsXrGnMkHOpQtf76Kn4rIqfLEHsVaDL07X7IRB aTDrxT9ah3MfCE3eA/IzVqUMPbwRF3YcA2nAg0L55M4OTrEoQKjfX+1xSVFR5ZU= =8Cav -----END PGP SIGNATURE----- _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
