[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #19417 [Applications/Tor Browser]: asm.js files should not be cached to disk in Tor Browser and no linkability risk
#19417: asm.js files should not be cached to disk in Tor Browser and no linkability
risk
-------------------------------------------------+-------------------------
Reporter: gk | Owner: tbb-
Type: defect | team
Priority: High | Status:
Component: Applications/Tor Browser | assigned
Severity: Major | Milestone:
Keywords: tbb-disk-leak, tbb-linkability, | Version:
GeorgKoppen201606, TorBrowserTeam201606 | Resolution:
Parent ID: | Actual Points:
Reviewer: | Points:
| Sponsor:
-------------------------------------------------+-------------------------
Comment (by gk):
Replying to [comment:12 mcs]:
> Replying to [comment:11 gk]:
> > After thinking about it more it seems to me there is the additional
risk that this mechanism could be used to embed supercookies. Like,
deliver JS to a user that contains an identifier -> get that into the
asmjscache -> once this is loaded anywhere ping the identifier back.
> >
> > Looking at https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-
compilation-and-startup-performance/ does not rule that scenario out:
> > {{{
> > The cache entry is keyed on: the origin of the script, the source
characters of the asm.js module, the type of CPU and its features, the
Firefox build-id (which changes on every major or minor release).
> > }}}
> > Note this would be especially problematic for Tor Browser users as we
are currently not changing the build-id.
> >
> > Not sure what "the origin of the script" means but I doubt "URL bar
domain". It could mean as well that the asmjs cache is not caring about
starting SOP either.
>
> They do use principals in the asmjscache code, so maybe there is some
protection (not enough for us though).
>
> Are you now thinking that we should unconditionally disable the
asmjscache?
Well, doing so with `javascript.options.parallel_parsing` set to `false`
does not work at least. :) What to do depends on how serious the issue is.
If there are no linkability issues then making it just obey PBM is fine
with me. If it can get used to track users across sites then we might want
to disable it first and then enable it successively as soon as this is
fixed.
I actually tried to find proper sites that could be loaded in an iframe
AND would exhibit asmjscaching but I failed so far. Seeing what is
happening on the user's disk in this case might actually be revealing. Who
knows what "origin if the script" boils down to given that nobody was
caring about user privacy much in this case anyway.
> I spent a little time trying to figure out how to cleanly disable the
cache when in private browsing mode (I was hoping progress would be
reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1047105 but that
has not happened so far).
>
> For web workers, it might work to avoid calling JS::SetAsmJSCacheOps()
inside dom/workers/RuntimeService.cpp when in private browsing mode.
>
> For content windows, I think we could make changes inside
dom/base/nsJSEnvironment.cpp to ensure that AsmJSCacheOpenEntryForRead()
and AsmJSCacheOpenEntryForWrite() do nothing when operating inside a
private browsing mode window.
Seems to be worth a try to me.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19417#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs