[tbb-dev] update

Richard Pospesel richard at torproject.org
Tue Dec 12 18:26:44 UTC 2017

Hey Browser Devs,

Flew into Austin yesterday for the Y'all Hands.

This past week I've been investigating the root cause of #17933 and
#15599 (pdf loads going to the default circuit rather than the first
party domain).  Technically speaking #17933 is now no-repro as it dealt
specifically with the download button which now doesn't make any network

As explained in the comments of #15599 the default circuit is being used
by XMLHttpRequests made by pdf.worker.js.  The offending requests occur
in the context of a Web Worker.  For some reason, requests created in
the context of the Worker inherit the global default nsIPrincipal (which
the first party domain is derived from) which has an empty first party
domain (which ultimately forces use of the --unknown-- circuit)

I've verified that requests from the pdf.js 'foreground' (?) context is
associated with the correct circuit.  My preliminary reading suggests
that there is a one-to-one mapping of Web Workers to Tabs (ie there's no
sharing between tabs, unlike with Shared Workers or Service Workers) so
there doesn't seem to be any web-standards reason why pdf.worker.js
'context' shouldn't share a nsIPrincipal with the calling pdf.js

My next line of inquiry is to learn about/investigate of nsIPrincipal's
work and determine whether we can fix Workers to inherit their caller's
nsIPrincipal.  I would imagine there's some thread-safety considerations
to be made here, since Workers allow for background concurrent js.  Need
to see if in practice the get their own thread or if they operate on the
same thread as the js 'UI' thread.


More information about the tbb-dev mailing list