ToDo: 4100: FPI EXTRAS - Githubissues

Thorin-Oakenpants commented 5 years ago

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.

:+1: or comment (and hurry up, I'm impatient)

earthlng commented 5 years ago

alt-svc headers can be used for cross domain tracking

how? please explain

Thorin-Oakenpants commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Tracking Clients Using HTTP Alternative Services

Thorin-Oakenpants commented 5 years ago

While we're waiting ... rather than add a new issue, I'll dump this here

/* 4505: control timer precision (FF58+)
 * [WARNING] For info only or testing
 * [1] https://bugzilla.mozilla.org/1424341 ***/
   // user_pref("privacy.reduceTimerPrecision", true); // default: true
   // user_pref("privacy.resistFingerprinting.reduceTimerPrecision.microseconds", 1000);
/* 4506: control timestamp fuzz/jitter (FF60+)
 * [WARNING] For info only or testing
 * [1] https://bugzilla.mozilla.org/1425462 ***/
   // user_pref("privacy.resistFingerprinting.reduceTimerPrecision.jitter", true); // default: true

Initially we decided to leave it out since defaults are what we wanted, and people didn't really need to know - a feature initially used by Mozilla to fine tune and test against breakage. Even the jitter wasn't added for two more releases

But it's kinda stable now. Having as much info as possible in the js is damn handy. And useful for testing. And they have big fat warning tags. So I think we can now add em to the user.js.

Any objections or nits?

earthlng commented 5 years ago

objection your honor! The only thing this adds is confusion and unnecessary baggage to an already massive user.js. If you want the info somewhere, add it to the RFP sticky. Please

Thorin-Oakenpants commented 5 years ago

It's already in the RFP sticky (well jitter isn't, but I'll add it). I know we (you and me) initially said to not add it because it adds confusion. I just think it's ok now to add it - but then again, I'm probably over-estimating end-users? Better to err on the side of caution? The other side is people always asking about why isn't this pref or that pref etc. So torn between knowledge is power and end-user stupidity

No worries dropping it, but interested in what others say. It was just a thought.

Thorin-Oakenpants commented 5 years ago

RFP timing stuff: OK, so I NAH'ed it in #491

FPI: Can I do a commit and close this. When I hear back from Arthur, I'll forward his email to you and if required we can tweak the entry. Just :+1: if you're happy with this

earthlng commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Thorin-Oakenpants commented 5 years ago

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 commented 5 years ago

Re: security considerations for Alt-Svc

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

Thorin-Oakenpants commented 5 years ago

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:

User visits primary.com: server sends header AltSvc: uniqueid345024.tracker.com

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 commented 5 years ago

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 commented 5 years ago

^^ 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 commented 5 years ago

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 :cat2:

Thorin-Oakenpants commented 5 years ago

thanks for finishing that for me :cat2:

Woofy-Wolf commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

^^ 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 commented 5 years ago

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

arkenfox / user.js

ToDo: 4100: FPI EXTRAS #571