ToDo: 4100: FPI EXTRAS

[Thorin-Oakenpants]

Items will stay active. Note the setup-perf tag.

This would also close #548 (in the sense that the info is now presented for end users to make up their minds. As for ssl session id lifetimes, I have others means and my own ticket/reminder to try to achieve this

draft

/*** [SECTION 4100]: FPI EXTRAS [SETUP-PERF]
   [WARNING] It is recommended that you keep these prefs active, ONLY relax them if you have
   FPI enabled, *AND* you understand the consequences. FPI isolates these, but it was designed
   with the Tor protocol in mind, and the Tor Browser has extra protection, including enhanced
   sanitizing per Identity. FPI does not protect against repeat first party visits (Tor Browser
   doesn't either for each Identity session). All have a performance impact when active.
***/
/* 4101: [0702] disable HTTP2 (which was based on SPDY which is now deprecated)
 * HTTP2 raises concerns with "multiplexing" and "server push", does nothing to enhance
 * privacy, and in fact opens up a number of server-side fingerprinting opportunities
 * [1] https://http2.github.io/faq/
 * [2] https://blog.scottlogic.com/2014/11/07/http-2-a-quick-look.html
 * [3] https://queue.acm.org/detail.cfm?id=2716278
 * [4] https://github.com/ghacksuserjs/ghacks-user.js/issues/107 ***/
user_pref("network.http.spdy.enabled", false);
user_pref("network.http.spdy.enabled.deps", false);
user_pref("network.http.spdy.enabled.http2", false);
/* 4102: [0703] disable HTTP Alternative Services (FF37+)
 * [1] https://tools.ietf.org/html/rfc7838#section-9
 * [2] https://www.mnot.net/blog/2016/03/09/alt-svc ***/
user_pref("network.http.altsvc.enabled", false);
user_pref("network.http.altsvc.oe", false);
/* 1403: [1203] disable SSL session tracking (FF36+)
 * SSL Session IDs speed up HTTPS connections (no need to renegotiate) and last for 24hrs.
 * Since the ID is unique, web servers can (and do) use it for tracking. If set to true,
 * this disables sending SSL Session IDs and TLS Session Tickets to prevent session tracking
 * [1] https://tools.ietf.org/html/rfc5077
 * [2] https://bugzilla.mozilla.org/967977 ***/
user_pref("security.ssl.disable_session_identifiers", true); // (hidden pref)

The only diff in the numbered items is that for alt svc I added the line
Edit: new link for ref [1]

PS: and we would add the section to the index.

👍 or comment (and hurry up, I'm impatient)

[earthlng]

alt-svc headers can be used for cross domain tracking

how? please explain

[Thorin-Oakenpants]

search for alt-svc headers come to mind here

I thought it actually said what I said, but instead it's implied. Parts of that doc are out of date (at least I can tell from some of the things they say they do - TB 8* isn't that old). Maybe that isn't the case any more?

[earthlng]

to me, alt-svc in that sentence is just mentioned as one example for "all associated means" ("... [which] MUST adhere to this design principle as well.").
But whatever the case may be, they definitely kept it vague and in the realm of possibilities ("could") but you made it an absolute: "can be used"

Maybe that isn't the case any more?

when they enabled it they didn't say a word about cross-site tracking. They could have just enabled H2 and kept Alt-Svc disabled if they had any concerns. I don't see why anyone would use Alt-Svc to redirect clients to a 3rd-party in the 1st place but maybe I'm missing something.

[Thorin-Oakenpants]

I'll ask Arthur. Failing that we can just take the line out (but I did want to give a reason as to why it's disabled)

[Thorin-Oakenpants]

all associated means that could be used for cross-domain user tracking (alt-svc headers come to mind) MUST adhere to this design principle as well

Thats basically the full sentence. Using my awesome verbal reasoning skills, to me it clearly says that alt-srv is one of the associated means that (edit: could) allow cross-domain tracking. That's the subject. The verb and object are immaterial. But that may not be what the writer intended.

I think the key word here is could, and they're probably not sure, but then why single out alt-svc headers as the example.

Anyway, email sent to Arthur.

[Thorin-Oakenpants]

Also, ssl session tickets last for 24 hrs, so I updated that in OP too ( see table right colun page 7 of https://svs.informatik.uni-hamburg.de/publications/2018/2018-12-06-Sy-ACSAC-Tracking_Users_across_the_Web_via_TLS_Session_Resumption.pdf )

[Atavic]

Tracking Clients Using HTTP Alternative Services

[earthlng]

If you read the security considerations for Alt-Svc @ https://tools.ietf.org/html/rfc7838#section-9 the tracking risk is arguably the least worrying.
The problematic part tracking-wise is the "persist" parameter and you could easily remove that in HTTP/1.x headers but for H2 it's recommended to use a frame in binary form and you can't tamper with that. (once again I have to say FUCK H2!)

The spec also says that Alt-Svc are OPTIONAL and clients don't have to honor it. AS is kind of a security/privacy nightmare for the sole purpose of load balancing. IMHO AS should die a quick death.

I'd prefer to not commit the FPI ALT section because FPI doesn't solve all the problems with H2 + AS.
We can relax the session IDs for performance reasons and because it's covered by FPI but we can do that without moving it somewhere else

[Thorin-Oakenpants]

Just focusing on that pref (and not the new section), shouldn't we give a reason? So if " * alt-svc headers can be used for cross domain tracking" is not the main reason, what should we say? or link to?

[earthlng]

https://tools.ietf.org/html/rfc7838#section-9

[Thorin-Oakenpants]

I'd prefer to not commit the FPI ALT section because FPI doesn't solve all the problems with H2 + AS.

That's what the section header explains. They might be acceptable or "solved" with Tor, and Tor Browser extras such as sanitizing on New Identities etc, but not in FF as far as we are concerned. And same for ssl session ids.

We can relax the session IDs for performance reasons and because it's covered by FPI but we can do that without moving it somewhere else

I do get that ssl session ids are at a different point in the network stack (see GeKo's comments). But I don't follow this logic?

People keep asking about HTTP2 - we've had two massive threads about it. And it'll get worse with TB8* enabling it, in fact all three prefs.

What do you suggest we do then, because the section info I crafted need to go in, IMO.

[Atavic]

Re: security considerations for Alt-Svc

The guy who proposed that has a blog where some Security Considerations are explained better.

[Thorin-Oakenpants]

Here is Arthur reply to the question: can alt-svc headers be used for cross-domain tracking

Yes, I think they can, in the sense that there is an AltSvc mapping stored in browser memory that maps primary domains to alternate domains. This is a global stateful mapping, so in principle a website could use it to track with the following steps:

1. User visits primary.com: server sends header AltSvc: uniqueid345024.tracker.com
2. In a second tab, user visits firstparty.com: page sends third-party request to primary.com and AltSvc mechanism redirects it to uniqueid345024.tracker.com

[crssi]

What do you suggest we do then, because the section info I crafted need to go in, IMO.

HTTP2 and Alt-Svc are quite new. I don believe disabling those will lead to breakages, but everything about those two smells like hell security/privacy wide.

If you are asking to disable those or not... I vote to disable them.

[Thorin-Oakenpants]

^^ I meant what are we going to do with them in regards to grouping them or adding the extra info. We do not intend to make them inactive. As for breakage, there is none (as discussed in other threads). The only drawbacks are performance

I don't mind the extra section, but they don't really belong together, except that 1) TBB differs and people will say "but why do you disable them" and 2) they are all mitigated to some degree by FPI and 3) they are all perf related.

We can always tag each of the three with [SETUP-PERF] so that's not an issue. But I don't want to repeat the section header info across three prefs, and I think that information is really important to include - but we should be able to do it with creating a new section.

Also the new section is kinda weird, as in it's not an ALTernative to FPI (we want them active regardless of FPI). Which for better or worse I called them EXTRAs. So this then has a different format and purpose to sections like RFP ALT and might confuse people, IDK - e.g they might think these should only be active IF they have FPI on.

So sure, lets not do this new section, but FFS, I'm not going to NOT put the info into the user.js given all the discussions and threads. Let's put this shit to bed.

[Thorin-Oakenpants]

bumping!

Someone else suggested an "alts" section for these, I tried to work it in, but then they went all quiet and changed their minds and left me looking like a complete idiot, which I look like anyway, no help required in hindsight, while elegant for the common thread re Tor Browser, and the common thread in perf that users would flip, and the common thread in being mitigated somewhat with FPI, they simply do not belong together. So we'll just have to do the following

• easy: give each of these a perf tag: 0702, 0703, 1203
• messy AF: feed the relevant parts of this shit in with them (which I think is all of it)

  [WARNING] It is recommended that you keep these prefs active, ONLY relax them if you have
  FPI enabled, AND you understand the consequences. FPI isolates these, but it was designed
  with the Tor protocol in mind, and the Tor Browser has extra protection, including enhanced
  sanitizing per Identity. FPI does not protect against repeat first party visits (Tor Browser
  doesn't either for each Identity session). All have a performance impact when active.

Assigning to 🐈

[Thorin-Oakenpants]

thanks for finishing that for me 🐈

[Woofy-Wolf]

@Thorin-Oakenpants , I know you closed the issue, but could you answer a question about SSL session tickets? I read this thread and #548 too. It sounds like FPI and (especially) TC together defeat the privacy problems of http2, altsvc, and even ssl session ids ... but I'm not sure.

I think that I create two separate ssl sessions if I visit example.com from two different temporary containers, say tmp11 and tmp12. Does this overcome the concerns we have about ssl session ids (and http2 and alt services)? I'm inclined to enable all three features if Temporary Containers defeat the privacy & security problems.

Not sure, though.

[Thorin-Oakenpants]

Temporary Containers solves the issue of first party repeat visits in the same session (they get cleared anyway when FF closes) with SSL session ids, because they have Origin Attributes (FPI, PB, containers). This is a unique id

So you do a google search from their web page (I'm not sure what happens if you search from Activity Stream, as that has a hidden container id of 5, but should just treat pass the search to google which opens a new webpage = new container id). Later on (I assume the original google tab is closed), you do another search = new container, new ssl session id. If you have changed IP (VPN, or in Tor Browser, a new identity) in the meanwhile, then you should look like a completely new visitor.

Of course there would be other factors to consider: e.g opening a google result should be a new tab, strip utms etc. And on an android phone, google is linking you in other ways. I'm just talking about the ssl session id.

---

HTTP2 & AltSvc are a little different as they would / could "leak" the same info each time. Temporary containers would effectively do the same job - i.e starting from new when revisiting a site (in a new container) in that there would no AltSvc info to draw on, but as for HTTP2, IDK exactly, I think you just end up using what the servers decide and it doesn't really do anything?

---

Long story short, a new TC is like a new identity in Tor Browser (not that everything is cleared or OA'ed). If you're using TC then you could probably drop FPI - there are only a couple of things TC's don't cover (I think HSTS is one, but IMO that's already mitigated by using the inbuilt preload (50K domains) + HTTPSEverywhere (125K domains) & clearing and then removing permissions from SiteSecurityServiceState.txt.)

FPI & TC = awesomeness, but one drawback is cross domain logins. And depending on your threat model, you could really drop the three prefs and get a little performance back. Depends how you configure TC. Remember, if you're already logging in, there's no point - e.g. I don't use TC (yet), but I assume you can set up / whitelist some domains - e.g for me, it would be GitHub (which I log into, so no big deal)

[crssi]

I have FPI+TC, where TC is configured in a way that left mouse click (LMC) stays in the same container and the middle mouse click (MMC) opens a new tab in a new container if the target domain is different as source.
So with LMC there is no cross domain logins breakages.
This is my TC settings (default as a base):

General
  Automatic Mode: Check
  [PERSONAL CHOICE] Container Name Prefix: %domain% #
  [PERSONAL CHOICE] Random Container Color: Check
  [PERSONAL CHOICE] Container Icon: fingerprint
  Container Number: Reuse available numbers
  Delete no longer needed Temporary Containers: 2 minutes after the last tab in it closes
  Click [Save]
Isolation
  Per Domain
	Domain pattern: *
	  Always open in new Temporary Containers: enabled
	  Click [Add or Edit]
	Domain pattern: duckduckgo.com
	  Always open in new Temporary Containers: enabled
	  Click [Add or Edit]
  Global
	Mouse Clicks on Links should open new Temporary Containers
	  Middle Mouse: If the clicked Link Domain does not match the active Tabs Domain (Subdomains won't get isolated)
	Click [Save]
NOTE: CTRL+SHIFT+T = Undo closed tab(s)

Additionally to upper, I am also using Context Plus for container migration, since MAC and Containerise did not prove to be efficient and reliable.

Cheers

[Thorin-Oakenpants]

^^ even though I have google search always open in a new tab, I am so conditioned to right click context menus that it doesn't matter (for me) on any website - I also make a lot of use of control-click. But for sure, TC is only as good as you understand and config it

[Woofy-Wolf]

Thanks for the reassurance @Thorin-Oakenpants and @crssi . I'll take a perf boost where I can find it, especially considering all the other preferences that degrade performance -- no disk cache, no hardware acceleration, etc.

Ooh fun, configuration comparisons...

Unlike @crssi , I've never gotten the per-domain settings of TC to override global behavior in quite the way that I wanted. Instead, I temporarily change the global settings when necessary. For cross-domain logins, I choose NEVER for "Navigating in Tabs should open new Temporary Containers" (and then re-enable it). I put Startpage.com in its own permanent container, but I disable the Multi-Account Containers preference when I need to click to the next page of search results (the TLD is the same for the next page, but different subdomains trigger new containers anyway).

General
  Automatic Mode: Check
  [PERSONAL CHOICE] Container Name Prefix: tmp#
  [PERSONAL CHOICE] Random Container Color: Check
  [PERSONAL CHOICE] Container Icon: circle
  Container Number: Keep counting
  Delete no longer needed Temporary Containers: After the last tab in it closes
  
Isolation
  Per Domain
	Domain pattern: [blank]
	  Always open in new Temporary Containers: disabled

  Global
	Navigating in Tabs should open new Temporary Containers
	  If the Navigation Target Domain does not match the active Tabs Domain (Subdomains won't get isolated)
	Mouse Clicks on Links should open new Temporary Containers
	  Middle Mouse: Never
	  Ctrl/Cmd+Left Mouse: Always
	  Left Mouse: If the clicked Link Domain does not match the active Tabs Domain (Subdomains won't get isolated)	  

Multi-Account Containers
	Open new Temporary Containers if a Permanent Container Tab tries to load a Domain that isn't assigned to "Always open in" that container
	  Enabled

The only unsolved problem I have with TC is store checkouts that use third-party processors like PayPal. (Edit: Actually, that's not right. I narrowed the cause to either user.js or UMatrix/UBO filters. I gave up and use Chrome when required (with the same complement of filters, so it's probably my user.js).

Overall I'm very happy using FPI and TC. "Context Plus" is a good tip, crssi. I'll try it out. :)