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.

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?

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.

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.

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?

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

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?

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

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

That is actually bad, isn't it?

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

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)

Cloudflare reCAPTCHA De-anonymizes Tor Users via Cryptome 2016

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).

a bit late but thanks for the link 👖 💋

The actual speed gain while using TLS Session Resumption is minimal: BrowserWorks/Waterfox#768 (comment)

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).

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

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.

...that is: 0703 disable HTTP Alternative Services

Another one from Waterfox BrowserWorks/Waterfox#799

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

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.

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.

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"

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

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

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!)

Update: re #491 (comment) 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)