[tor-bugs] #12671 [meek]: Does meek's network-facing browser run javascript?

[Tor Bug Tracker & Wiki]

#12671: Does meek's network-facing browser run javascript?
------------------------+-----------------
     Reporter:  arma    |      Owner:  dcf
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:
    Component:  meek    |    Version:
   Resolution:          |   Keywords:
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-----------------

Comment (by dcf):

 Replying to [ticket:12671 arma]:
 > Can Amazon S3

 (meek doesn't have anything to do with S3. You're thinking of
 [http://www.cs.utexas.edu/~amir/papers/CloudTransport.pdf CloudTransport].
 If meek used an Amazon service, it would be their CDN
 [[doc/meek#CloudFront|CloudFront]], not their storage service S3.)

 > Can Amazon S3 pass javascript to meek's network-facing browser (i.e. the
 copy of Tor Browser that it runs with a separate profile), and it will run
 it?

 No, the headless browser doesn't interpret anything it receives, except to
 base64-encode it and pass it back to meek-client.
 [https://gitweb.torproject.org/pluggable-
 transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/firefox/components/main.js#l1
 Here is how the protocol looks.] We use an [https://developer.mozilla.org
 /en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIHttpChannel
 nsIHttpChannel] and read the response with [https://developer.mozilla.org
 /en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIBinaryInputStream
 nsIBinaryInputStream] as a binary string.

 It's like when you do an XMLHttpRequest; the browser doesn't interpret or
 run or display the response, even if it happens to contain HTML. It's not
 as if we put a URL in the address bar and then read the response by
 walking the rendered DOM.

 And of course, there's no way for the CDN to affect what gets rendered in
 your actual Tor Browser, because all that the CDN sees (and all the
 headless browser sees) is encapsulated Tor TLS. The CDN is about as
 privileged as your ISP or guard.

 > Seems like disabling javascript would provide a way for S3 to
 distinguish meek users from the typical web user, but leaving it enabled
 would be sad (and surprising) for users who prefer to disable javascript.
 That said, there are already other ways for S3 itself to learn that it's a
 meek user, and there shouldn't be a way for an external observer to learn
 whether they run it? And in that case it would be wise to lock down meek's
 browser at least as much as tor browser itself?

 You're right that we don't try to hide from the CDN; we need at least that
 much from them. After all, the hidden domain name in all the domain-
 fronted requests points straight to a meek-server instance on a Tor
 bridge, so there is a trivial distinguisher. (E.g., Google would just
 block the domain meek-reflect.appspot.com if they wanted to.)

 [https://gitweb.torproject.org/builders/tor-browser-
 bundle.git/blob/5400da654020a34edb9edee70a0583a89231c4fe:/Bundle-
 Data/PTConfigs/meek-http-helper-user.js Here are the extra settings we
 apply in the headless browser], mainly undoing some of Tor Browser's
 configuration like the proxy setting. Other settings are inherited from
 Tor Browser. We could disable JavaScript there, but I don't know whether
 you'd call it defense in depth or voodoo. For example, we could also
 disable image loading, in order to prevent the headless browser from
 loading a tracking gif or something, but the extension doesn't work in a
 way that could cause it to want to load an image.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12671#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online