User.js: some TBB stuff

[earthlng]

quick link: all esr-60 tortrac tickets

:small_red_triangle_down: DONE

• [x] enforce dom.event.highrestimestamp.enabled=true - https://github.com/ghacksuserjs/ghacks-user.js/commit/74f029566ecbd757abac025e1e7ec45add1ac6d6
  
  
  
  • although they are talking about deprecating it it, but it would still hang around in ESR60 1485264
  
  
• [x] sort out FPI vs Tor vs HTTP2/AltSvc/SSL Session IDs - https://github.com/ghacksuserjs/ghacks-user.js/commit/ac4e764c37560a32edddb1deb12cd7bca9c20a7e
  
  
  
  • see #571 (and we did some homework on it in #548 )
  
  
  • HTTP AltSvc - tor 24553
  
  
  • HTTP2 - tor 14952 , also see tor 27260
  
  
  • SSL Session identifiers - tor 17252
  
  
  • Mozilla OA tests: bugzilla 1337868
  
  

---

:small_red_triangle_down: THINKIN' 'BOUT IT

• security.webauth.webauthn tor 26614
  
  
  
  • might revisit in a Tor Browser diff, meanwhile it's only disabled in TB because they haven't vetted it yet
  
  

:small_red_triangle_down: NAH

perf / timing

• check what TBB do with some of the timing prefs (from #457 ) regardless of RFP
  
  
  
  • dom.enable_performance (4603) which I THINK controls
    
    
    
    
    
    • dom.enable_performance_navigation_timing
    
    
    
    • dom.enable_performance_observer
    
    
    
  
  
  • dom.enable_resource_timing
  
  
• consider adding the two RFP prefs for 4500 if only for info's sake (from #457 )
  
  
  
  • NAH, defaults are what we want, but confusion could be an issue. Better to be cautious than inform end users of something they don't need to fiddle with - see https://github.com/ghacksuserjs/ghacks-user.js/issues/571#issuecomment-444361475
  
  
  • privacy.reduceTimerPrecision
  
  
  • privacy.resistFingerprinting.reduceTimerPrecision.microseconds
  
  

• enable HWA tor 9145
  
  
  
  • source
  
  
  • > we finally enabled hardware acceleration for improved browser rendering performance after applying a fix for a long-standing bug, which often caused crashes on Windows systems with graphics cards, e.g. from Nvidia
  
  
  • I have no idea what that means for non-windows users
  
  
  • NOTE: we now have a SETUP-PERF tag on it
  
  

wasm

• wasm * wasm_ionjit + wasm_baselinejit - tor 21549

ua spoof

• tor 26146 - i am interested in what they do
  
  
  
  • personally I think they should limit OS to "windows" only given 1. they can live with breakage and users expectations 2. giving away free entropy is never good 3. extremely few sites will go to the lengths required to unmask the real OS and if they do, they gain nothing more than if the UA had given it away anyway 4. some methods such as TCP/IP FP'ing are moot in TBB, and TBB also disables JS by default
  
  

---

original post

just dropping this here for later ... [merged into above]

[earthlng]

maybe worth considering adding a new section FPI Alternatives and move that stuff there. If the TBB guys are confident that it's sufficiently mitigated by FPI it should be good enough for our purposes too.

However I don't think it's a good idea to enable HWA, especially in TBB because lots of cards ie drivers are blacklisted and it's easy to detect if HWA is enabled or not. It's kind of curious too because they still limit the CPU to 1 core. I mean if #s of CPUs and CPU performance overall is a concern then GPU should definitely be as well.

[Thorin-Oakenpants]

https://blog.torproject.org/comment/276515#comment-276515 .. on enabling HWA

Don't you know that:

• D2D renders fonts differently?
• only WebGL has a so-so sanitizer (ANGLE), other calls are direct?
• DXVA has different versions and no sanitization of videos?

[earthlng]

But we need to make sure ... that they haven't applied their own patches

They didn't mention anything about custom patches in the 2 tickets about HTTP2 and TLS session IDs.
But they'll keep HTTP2-Push disabled (for now?)
If you want to make sure, the easiest way would be to ask Arthur.

[Thorin-Oakenpants]

Sure. Not doing anything until 8 final is out, because who knows what will get reverted. I only mentioned it because TBB has/had a lot of changes to networking under the hood.

I have some reservations about TBB TBH. Arthur has stated in the past that with FPI, they want to enable all cookies, including 3rd party, in the future. Now they're removing restrictions on other items (SSL session ticket ids, altsvc, http2), and now HWA ...

I get that they have a different threat model, and users can change to a new node at will (which wipes everything), but FPI does not protect against repeat 1st party visits - although to be fair, a VPN even though you might share the IP with others, doesn't either.

Anyway, I'm more concerned with FF. TC's looks like the perfect answer to me.

[Thorin-Oakenpants]

FYI: re wasm: https://old.reddit.com/r/TruthLeaks/comments/96qmmq/webassembly_is_a_privacy_security_nightmare_it/

question: isn't wasm governed by uMatrix's script ? It's still a script, right?

[Atavic]

Yes, subset of JS:

a webpage needs to run JavaScript in order to launch webassembly programs

https://forums.informaction.com/viewtopic.php?f=10&t=25081#p97951

https://github.com/stevespringett/disable-webassembly#security-considerations

https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=1456308

[Thorin-Oakenpants]

FYI:

• Article: https://youbroketheinternet.org/trackedanyway
• Paper: https://svs.informatik.uni-hamburg.de/publications/2018/2018-12-06-Sy-ACSAC-Tracking_Users_across_the_Web_via_TLS_Session_Resumption.pdf

Haven't read it yet. TBB has a different threat model. I don't care if they allow SSL session ticket IDs. Personally, for me, this will stay disabled. Needs more analysis. eg. does this impact HTTP2 etc (having to negotiate a new handshake on every request?), what mechanisms can clear them, etc?

[Thorin-Oakenpants]

^^ @earthlng check your mail, FYI, we'll see what happens

[Thorin-Oakenpants]

https://arthuredelstein.github.io/tordemos/os-detection-font-css.html

Well, that went well: I'm on some sort of triple hybrid system

Edit: https://arthuredelstein.github.io/tordemos/media-query-font-detection.html also fails for me, but the font list is rather limited

[crssi]

That is actually bad, isn't it?

[earthlng]

Both of these demos are tailored for TBB. The 2nd one could also be used to detect your configured font when fonts are generally disabled with browser.display.use_document_fonts=0

[Thorin-Oakenpants]

https://www.zdnet.com/article/cloudflare-ends-captcha-challenges-for-tor-users/ - might explain why HTTP2 was also enabled (after ensuring it was covered by FPI of course)

[Atavic]

Cloudflare reCAPTCHA De-anonymizes Tor Users via Cryptome 2016

[Atavic]

TLS Session Resumption reduces the load for every handshake, but allows tracking between TLS Sessions and can be defeated by closing the browser (so that it clears the TLS cache).

[earthlng]

a bit late but thanks for the link :jeans: :kiss:

[Atavic]

The actual speed gain while using TLS Session Resumption is minimal: https://github.com/MrAlex94/Waterfox/issues/768#issuecomment-434476025

[Thorin-Oakenpants]

FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1499478#c6

To rehash, TBB went with a UA spoofing solution that limited OS to Windows on Desktop and Android on Android. But then allowed JS to return either Windows, Android, Linux or Mac (to reduce breakage I assume). Seems as if Mozilla intend to follow suit (see linked comment).

[Thorin-Oakenpants]

Slightly OT: FYI: https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/

QUIC stands for "Quick UDP Internet Connections" and is, itself, Google's attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things

[Atavic]

On IP terms, TCP is stateful and requires acknowledgment of each segment, while UDP is stateless. The only sane use of UDP over TCP should be for video streaming and not whole sites.

https://github.com/quicwg
https://datatracker.ietf.org/doc/draft-ietf-quic-http/

So g00gle will serve HTTP/QUIC Endpoints? Section 2.2 of the last link above tells us it will be done via an Alt-Svc: header field and I'll gladly strip away that headers.

[Atavic]

...that is: 0703 disable HTTP Alternative Services

[mparnelldmp]

Another one from Waterfox https://github.com/MrAlex94/Waterfox/issues/799

[Thorin-Oakenpants]

FYI: https://old.reddit.com/r/netsec/comments/a1d6hl/stealing_webpages_rendered_on_your_browser_by/

also: huh?

Is this some sort of bug or server config: go to https://www.cc.gatech.edu/ and it is secure, view the PDF and it's not

[parseword]

For whatever it's worth, that server is jacked up. It only supports TLS 1.0 and its clock is running 20 minutes behind. I keep security.tls.version.min at 3 so I can't connect at all; curious why it would show different security statuses for the index vs the PDF, though.

[Thorin-Oakenpants]

I'm still quite keen to create a FPI alternatives section, but with the prefs left active. We've focused on SSL sessions (yup, talked to death), HTTP2 (no one really knows), and AltSrv (alt-svc headers can be used for cross domain tracking) .. but lets not forget OCSP cache is also isolated.

[Thorin-Oakenpants]

setting dom.event.highrestimestamp.enabled to true. This might seem to be counterintuitive at first glance but the effect of setting that preference to true is a normalization of evt.timestamp and new Event('').timeStamp. Together with clamping the timer resolution to 100ms this provides an effective means against ...

I think we enforce the pref as per comments in OP re "This might seem to be counterintuitive"

[Thorin-Oakenpants]

check what TBB do with some of the timing prefs

TB 8.0.3

• 4603 dom.enable_performance = default false (true in FF)
  
  
  
  • they leave dom.enable_performance_navigation_timing & dom.enable_performance_observer as true (we don't have these, but looks llike 4603 is a master pref)
  
  
• 4602 dom.enable_resource_timing = default false

These are already covered by RFP (we checked when the bugzilla for them were dome). I can't currently re-find the tor ticket comment where it was tested and confirmed by Arthur. Also Tor Browser is kinda out of whack with deprecated prefs and these RFP alts - it will take them time to sort everything out (not much happening in all the 8.5 hardened versions on this), meanwhile they are just erring on the side of caution, I guess.

Moving to ignore for now. They'll come up again in a TB diff down the track

[Thorin-Oakenpants]

Do you want to do anything about security.webauth.webauthn etc

[Thorin-Oakenpants]

I don't think we need to do anything about this

• https://trac.torproject.org/projects/tor/ticket/26614
• https://bugzilla.mozilla.org/show_bug.cgi?id=1432542

/* xxxx: disable Web Authentication API [FF60+]
 * [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API ***/
user_pref("security.webauth.webauthn", false);

Tor is only disabling it because they haven't vetted it. - Reopen this issue if you think otherwise. Other than that, this will no doubt come up again when we do a TB diff (but man, its taking them a long time to get Quantum Tor Browser sorted out!)

[Thorin-Oakenpants]

Update: re https://github.com/ghacksuserjs/ghacks-user.js/issues/491#issuecomment-442756129 re Stealing Webpages Rendered on Your Browser by Exploiting GPU Vulnerabilities

Tom Ritter emailed me back.

1) This paper is from 2014. I'm not sure why or how to made the news cycle last month.
2) The attack vector for this is an attacker running an application accessing GPU memory locally on your computer. It's not a malicious website.

We're not concerned about this attack vector - if someone is running native code locally (even as a different user) - we aren't in a position to defend against these types of side channel attacks.

My bad, not sure why it popped up on my radar TBH. Old paper and system is already compromised. I really must think more before I type (note to self: think MOAR)