[tbb-bugs] #14952 [Applications/Tor Browser]: Audit HTTP/2 and SPDY if needed

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Aug 17 05:19:41 UTC 2018

#14952: Audit HTTP/2 and SPDY if needed
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  task                                 |         Status:
                                                 |  needs_review
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-linkability, tbb-usability-      |  Actual Points:
  website, tbb-performance, ff60-esr,            |
  TorBrowserTeam201808R                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
Changes (by arthuredelstein):

 * status:  new => needs_review
 * keywords:
     tbb-linkability, tbb-usability-website, tbb-performance, ff60-esr,
     tbb-linkability, tbb-usability-website, tbb-performance, ff60-esr,


 Replying to [comment:44 gk]:

 > 1) Is the disk avoidance requirement respected in case there is some
 caching going on?

 I took two approaches to try to confirm that HTTP/2 is respecting disk

 '''1.''' In the first approach, I read through the caching code and
 installed breakpoints using gdb:

 To write to the cache, nsHttpChannel.cpp calls

 I repeatedly hard-reloaded
 https://commons.wikimedia.org/wiki/Vincent_van_Gogh, and I confirmed this
 code location was hit repeatedly with "network.http.spdy.enabled" and
 "network.http.spdy.enabled.http2" set to `false`, and also with both set
 to `true`. I used the Network Monitor tab to confirm that files were
 loading via HTTP/1.1 GET requests in the first case, and HTTP/2.0 in the

 This indicates to me what I gathered from reading the code: that both
 HTTP1 and HTTP2 are using the same caching mechanism. So that gives us at
 least some hope that the private browsing policies are the same.

 Then I looked at AltSvc. The AlternativeServices.cpp uses DataStorage.cpp
 to store its AltSvcMapping data (the mapping between primary
 scheme/host/port and alternate service scheme/host/port). DataStorage has
 three DataStorageType values:
 * DataStorage_Persistent
 * DataStorage_Temporary
 * DataStorage_Private

 Only the DataStorage_Persistent type is sync'd to disk. So I wanted to
 confirm that DataStorage_Private is being used. So I put a breakpoint
 where AlternateServices.cpp stores a mapping:
 and then repeatedly visited an AltSvc header demo served at
 I confirmed there that mPrivate was always true, and thus
 DataStorage_Private is used in Tor Browser.

 '''2.''' The second approach was to use parent-process JS to measure the
 cache's disk consumption. I experimented with Firefox and Tor Browser.
 First I entered the following code in the Browser Console:

 let logDiskConsumption = () => Services.cache2.asyncGetDiskConsumption({
   onNetworkCacheDiskConsumption: x => console.log(x),
   QueryInterface: XPCOMUtils.generateQI([
 setInterval(logDiskConsumption, 250);

 This code logs the number of bytes found in the disk cache every 250 ms.

 In Firefox 60.1.0esr, I confirmed that "network.http.spdy.enabled" and
 "network.http.spdy.enabled.http2" were set to `true` by default. Upon
 running the above code, I could see the disk consumption monotonically
 increasing until the wikimedia page was fully loaded. Then the disk
 consumption stopped increasing (and remained constant at 2722816). The
 Network Monitor indicated HTTP/2 was being used.

 In Tor Browser 8.0a9, I manually set "network.http.spdy.enabled" and
 "network.http.spdy.enabled.http2" to true, because they were false by
 default. Then I ran the same code in the Browser Console, and confirmed
 that the total disk consumption remained constant at zero. Again, I used
 the Network Monitor to confirm HTTP/2.0 GET requests were being used.

 (I also checked a Private Browsing Window with Firefox 60.1.0esr and saw
 no disk consumption. And ran the code in Tor Browser with
 "private.firstparty.isolate" set to false, again with no disk

 From the results of these two approaches, I am persuaded that normal HTTP
 caching, at least for loading web pages and images, is avoiding disk
 caching in Tor Browser 8.0a9, when we activate HTTP2. Also, in reading the
 HTTP2 code, I didn't find any special cases of data being written to disk
 that raised concerns. Nonetheless I can't rule out that anything at all is
 written to disk that isn't also with HTTP1.x, but that will require more
 comprehensive research.

 Setting this for review in case more investigation is needed for this

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

More information about the tbb-bugs mailing list