Henri Sivonen:
> 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.

Hrm.. What is the nature of the barrier between the $EVILBLOB and the
CRM host, then?

Can $EVILBLOB decide to alter the address space of the CRM host at will?

If so, what prevents it from going rogue and eliminating/ignoring your
salt entirely, or from being exploited and using the same
device-information gathering APIs that are allowed in the CRM host to
gather sufficient information about the device to break out of the
sandbox?
 
> > 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).

Well, adding a full round trip over Tor will actually be quite
expensive, and I suspect will ultimately result in the
generation+transmission of the third-party trackable identifier *and*
the the jailed identifier, which will also still be a tracking issue.

Is there a reason why we couldn't simply change the single salt that is
currently passed in to be based on url bar host + iframe url host,
instead of just iframe host, and avoid the extra round trip?


-- 
Mike Perry

Attachment: signature.asc
Description: Digital signature

_______________________________________________
dev-privacy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-privacy

Reply via email to