-
Notifications
You must be signed in to change notification settings - Fork 513
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ToDo: 4100: FPI EXTRAS #571
Comments
how? please explain |
search for 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? |
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.").
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. |
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) |
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. |
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 ) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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 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. |
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? |
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.
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. |
Re: security considerations for Alt-Svc The guy who proposed that has a blog where some Security Considerations are explained better. |
Here is Arthur reply to the question: can alt-svc headers be used for cross-domain tracking
|
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. |
^^ 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. |
bumping! Someone else suggested an "alts" section for these, I tried to work it in, but
Assigning to 🐈 |
thanks for finishing that for me 🐈 |
@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. |
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) |
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.
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 |
^^ 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 |
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).
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. :) |
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
The only diff in the numbered items is that for alt svc I added the lineEdit: new link for ref [1]
PS: and we would add the section to the index.
👍 or comment (and hurry up, I'm impatient)
The text was updated successfully, but these errors were encountered: