Post B08PbHNQtAPRDDZ0RU by bagder@mastodon.social
(DIR) More posts by bagder@mastodon.social
(DIR) Post #B05RADIZYqZrB8dGbY by daniel@gultsch.social
2025-11-09T16:58:47Z
0 likes, 0 repeats
I started going to IETF meetings. Those events take place 3 times a year, with ~1000 people attending in person and another ~1000 remotely. A good chunk of those are paid to be there and some are employed by big companies like Apple and Google. This is the place where the fundamental fabric of the internet is constantly being improved. TLS 1.3, HTTP/3, MLS to name a few.With this in mind I have no fucking clue what Moxie was on about when he said interoperable protocols are stuck in the 1990s.
(DIR) Post #B05RAEIxosU6Idp5qy by giacomo@snac.tesio.it
2025-11-09T20:59:58Z
1 likes, 0 repeats
@daniel@gultsch.social#QUIC (and #HTTP3) exists to serve the interests and needs of #Google.In particular 0-RTT is basically a low-level cookie that allows deterministic user tracking below and before #http: if it will ever spread, disabling or deleting cookies, even out-lawing them, won't be a issue for #SurveillanceCapitalism.So these days what happens at #IETF is much more lobbying than engineering. Overpaid engineers lobby against the users to further cement the power of their corporations.I wouldn't call these as "improvements".These days, sadly, IETF is the place where the fundamental fabric of the internet is constantly being ^^enshittified**.@lorenzo@snac.bobadin.icu
(DIR) Post #B06LzSFDLai7ja4W5A by chrysn@chaos.social
2025-11-10T08:06:29Z
0 likes, 0 repeats
@giacomo @daniel @lorenzo IETF protocol specs regularly include sections with privacy considerations just like security considerations. These point out such problems and guide implementers to get them right (eg. to only use 0RTT if user tracking is of no concern because cookies would be on anyway). If a browser implements that wrong, it's for other lacks but awareness.
(DIR) Post #B06LzTU8jaFBaA3wzA by chrysn@chaos.social
2025-11-10T08:07:16Z
0 likes, 0 repeats
@giacomo @daniel @lorenzo I did not review that particular spec, but for those I do, I'd raise hell before publication as #IETF if such problems were unaddressed, and know many other reviewers who would do the same.
(DIR) Post #B06LzUZUhA7Yx3ZjyC by giacomo@snac.tesio.it
2025-11-10T11:03:43Z
1 likes, 0 repeats
Well @chrysn@chaos.social, I really appreciate your good intentions and will to fight for users' #privacy.But I was not talking about you or the few independent developers who still volunteer at #IETF these days.I was talking about IETF effects on the Internet standards as a whole.I'm afraid the impact of a few independent engineers is not going to balance the power of organized and well funded #BigTech lobbyists.As an example, let's stay on topic and look at RFC 9001, "Using #TLS to Secure #QUIC".All that is said about the impoved ability of the server to identify (and thus track) the user are in two lines about session resumption (emphasys mine):Session resumption allows servers to link activity on the original connection with the resumed connection, which might be a privacy issue for clients. Clients can choose not to enable resumption to avoid creating this correlation.Now please notice the #hypocrisy: the wording is set up as if clients should opt-in, but it's pretty unlikely that users will be given a choice between a personal data leak at protocol level and an imperceptible increase in connection time, in particular with 0-RTT where " Endpoints cannot selectively disregard information that might alter the sending or processing of 0-RTT".So while I'm pretty curious about @bagder@mastodon.social's perspective, I see that #Google managed to get a protocol designed to thwart user privacy and reduce its own server costs (even just the energy consumed during TLS hadshakes, amount to thousands dollars each day).This way, if EU would decide to forbid tracking cookies at all, Google would get a competitive advantage over all other #AdsTech companies.Now a properly working IETF would have rejected such shit, knowing that it would have been leveraged against people (and democracies) though #Chrome browsers and #Android defaults.CC: @daniel@gultsch.social @lorenzo@snac.bobadin.icu
(DIR) Post #B06X8vSfBhfOS156X2 by chrysn@chaos.social
2025-11-10T12:52:25Z
0 likes, 0 repeats
@giacomo If users use a browser that does not help them protect their privacy, it's a personal, or market, or regulation failure.The technical concern is not new to QUIC: even TLS 1.2 had resumption options with similar properties, and privacy aware browsers such as Tor browser have limited them for ages <https://gitlab.torproject.org/legacy/trac/-/issues/4099>.I've seen solo participants' concerns been addressed in documents backed by 100k employee companies. IETF is certainly not infallible, but generally, review works.
(DIR) Post #B06X8wmYHFAaXzOVAe by giacomo@snac.tesio.it
2025-11-10T13:47:33Z
1 likes, 0 repeats
@chrysn@chaos.socialIf users use a browser that does not help them protect their privacy, it's a personal, or market, or regulation failure.This is victim blaming.We are not talking about a browser that "does not help people protect their #privacy", but a protocol designed by #Google (that produce #Chrome) and open washed by their geek-friendly pr dept, #Mozilla (that produce #Firefox) with the goal to track people even when they disable or delete #cookies.The technical concern is not new to #QUIC: even #TLS 1.2 had resumption options with similar properties...Yet the innovation here is exactly 0-RTT, that hook a user identifier on the first ip packet.Sure #TorBrowser does the right thing since 2019, and so do #LibreWolf disabling security.tls.enable_0rtt_data in about:config.But why such obvious low-level tracking tool has been allowed in an Internet standard aimed at consumer usage?I agree with you, it's not for lack of awareness if mainstream browsers support this "feature".But it should be up to IETF to not let such user hostile feature enter in a protocol standard.They let it pass instead.It was not because of lack of engineering awareness.As many other formally independent institution, #IETF was subject to regulatory capture by #BigTech. The few independent engineers (like you) are there to preserve the public illusion of independence, so that #Surveillance can leverage the public trust. A sort of #EthicsWashing or #OpenWashing at protocol design level.
(DIR) Post #B08PbG75aRk3IEuRKS by electrostep@mammut.gogreenit.net
2025-11-10T00:03:43Z
0 likes, 0 repeats
@giacomo @daniel @lorenzo @bagder , you've written a book on the subject. It's the above claim of about #QUIC (and #HTTP3) true?
(DIR) Post #B08PbHNQtAPRDDZ0RU by bagder@mastodon.social
2025-11-10T00:06:47Z
0 likes, 0 repeats
@electrostep @giacomo @daniel @lorenzo no
(DIR) Post #B08PbI0mWrsvBFyQm8 by electrostep@mammut.gogreenit.net
2025-11-10T06:02:51Z
0 likes, 0 repeats
@bagder @giacomo @daniel @lorenzoThank you for responding.Just to add to the discussion, it would be great to see any counter-arguments for https://blog.cloudflare.com/even-faster-connection-establishment-with-quic-0-rtt-resumption/, if anyone has the time to contribute
(DIR) Post #B08PbIuRBwP7xs0sWe by giacomo@snac.tesio.it
2025-11-10T08:29:11Z
0 likes, 0 repeats
@electrostep@mammut.gogreenit.net#Cloudflare concerns on 0-RTT are about reply attacks.But what prevent an hyperscaler like #Google (that really have no issue at recording data about each user) to just save the last used pre-shared keys within the user's account profile and then identify the user on #QUIC client helo despite the user having deleted the authentication cookie from the browser?@bagder@mastodon.social @daniel@gultsch.social @lorenzo@snac.bobadin.icu
(DIR) Post #B08PbJonoNUUmgNtNg by electrostep@mammut.gogreenit.net
2025-11-11T08:54:31Z
0 likes, 0 repeats
@giacomo @bagder @daniel @lorenzo@giacomo, it seems that Google can equally do the same with the IP Address + User Profile combination. I'm sure this is what they are doing at the moment. The last pre-shared key doesn't add any additional privacy loss in that scenario, does it? Unless I am missing something
(DIR) Post #B08PbKSrPRX8mv7soq by giacomo@snac.tesio.it
2025-11-11T11:23:03Z
1 likes, 0 repeats
@electrostep@mammut.gogreenit.netIP addresses change over time.That's why #Google still uses good old authentication cookies to keep the user authenticated and link their requests to a user profile. And #GoogleAnalytics still use cookies to track the user navigation on a single website and so on...And that's why if you delete cookies you reduce their ability to deterministically identify you. They can still identify you if you let them execute #JS in your environment and fingerprint your browser, but IP alone might not be enough alone.That's where #QUIC 0-RTT fill the gap: it's basically a low level session identifier sent with the very first IP packet.You can read 2 lines about that in RFC 9001, in the section about session resumption (but not among "Security Considerations":Session resumption allows servers to link activity on the original connection with the resumed connection, which might be a privacy issue for clients. Clients can choose not to enable resumption to avoid creating this correlation.Nice clients have to opt-in, but browsers don't let users opt-out.@bagder@mastodon.social @daniel@gultsch.social @lorenzo@snac.bobadin.icu
(DIR) Post #B08YDKbo7WstsBwWJ6 by electrostep@mammut.gogreenit.net
2025-11-11T12:03:51Z
0 likes, 0 repeats
@giacomo @bagder @daniel @lorenzoThank you for explaining! But 0-RTT handshake is bound to the same domain/identity. It would not work fpr tracking across different domains and is not persistent either - it changes as frequently as IP address could, right?
(DIR) Post #B08YDLx77nWQ2Yv39k by giacomo@snac.tesio.it
2025-11-11T13:05:09Z
1 likes, 0 repeats
@electrostep@mammut.gogreenit.net0-RTT handshake..Preventing the handshake is the whole selling point of 0-RTT in #QUIC.It's there to track users, obviously, but its genuine innovation that make it suitable for server to server communications is the reducted connection time (no #TCP handshake and no #TLS handshake).is bound to the same domainSure.It would not work fpr tracking across different domainsNot needed if you control all of those different domains.Let's make an example.In your #openwashing #firefox you login in gmail and in another browser open #GoogleSearch establishing a #HTTP3 connection over #QUIC. Google know you are from IP X so he can record your google search activity with your identity.Google also save the pre shared keys (PSK) assigned to each of your QUIC connections in your profile. ¹Then you disconnect, and clear browser cookies logging out of #gmail.Then you connect to a brand new network, recieve a new public IP and make a new search on Google search.To establich a connection QUICly (pun intended) the browser send to www.google.com the PSK from the last session.So Google can simply identify you by looking for the PSK in the database, on the very first IP packet even if you removed all cookies and changed IP.And obviuouly, once Google know you have an active QUIC connection from the new IP, that IP will be enough to track you on all sites you visit on their #cloud servers and on all sites you visit that use their #spyware (#GoogleFonts, #GoogleAnalytics, #DoubleClick and so on), whatever the browser.You change IP again? Not an problem: the next #HTTP3 connection will leak your identity again.it changes as frequently as IP address could, right?This question is incorrect.The pre shared key is bound to a session that can span different IP over time as the user move among networks. That's the whole point of it, what allows the zero in 0-RTT: the first packet is used to resume a previous existing TLS connection.and is not persistentIt must persist enough to be useful.____¹ Google does not need to save such data to restore the QUIC connection since your browsers will send the PSK encrypted with the Google's public key in the first QUIC packet. BUT saving the PSKs in your profile (or an hash, don't focus on details) Google is then able to reidentify you like if you were sending a cookie.@bagder@mastodon.social @daniel@gultsch.social @lorenzo@snac.bobadin.icu