> “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.

What I don't understand is why the `sub` claim is not consistent for those users at Google. To my understanding of the OIDC protocol the `sub` should be unique for a specific user.

Additionally as far as I understand if you take over a defunct domain and create a new google workspace with new users those new user account should get assigned a new `sub`.

I agree, in my limited experience the sub remains consistent even when changing the Google Workspace domain. So the email changes but sub remains the same. The issue seems to be clients matching on email/hd claim instead.

I wonder what action is causing the sub to change like the author suggests is happening.

At my current company, if an employee leave and come back, they'll keep the same OID in Entra but they'll get a new `sub` in Google workspace. We had to put in place a process to be able to use an internal tool that used the login with Google.

That's most likely dependant on how the IT department handled the deprovisioning/provisioning of users in our Google Workspace, I unfortunately don't have the details for that.

> I wonder what action is causing the sub to change like the author suggests is happening.

Indeed this would be very interesting.

This issue is also very similar to CVE-2024-25618.

What we did to mitigate this is the following: - Federated login with OIDC - Look for a user based on the sub claim - If they are found: authenticate that user and optionally update their profile (email, name, ...) based on then new id claims. - Else look for a user matching on the `email` claim and link the `sub` to that user - If no user is found create a new one

That sub identifier changing without the underlying user changing may be the core of the bug. It's not fully clear from the post IMO. I posted a little breakdown here: https://news.ycombinator.com/item?id=42701030

I don't think the article clearly states one way or another whether those 0.04% of sub claims changing are legitimate end user changes or not. If those sub changes are legitimately the Google Account changing, I don't think that's a bug on Google's part, but rather is a problem on the clients' side for not validating the sub claim.

If the sub is changing without the Google Account user actually changing, maybe something internally at Google is swapping out those IDs when it shouldn't be. It doesn't look like a UUID from the example I saw, so maybe there's some code somewhere to just change the user's ID if there's a collision or something?

Interestingly, I don't think Google claims that Sign in with Google is fully OIDC-compliant. At least in the overview I linked in my comment, they compare the implementation to OAuth+OIDC, but I'm not sure they claim to be 100% spec compliant.

How would the clients tell if the account has a valid sub change or not if the only piece of information provided is that the sub claim changes? For this particular attack, without having some kind of Google Workspace account identifier for the domain, the sub claim doesn't sound sufficient to validate that it's the same Google account from the client's side. I'm guessing the engineer at the major tech company didn't provide that stat without checking if those users were valid, active accounts.

I really like flatpaks, easy to install and work with. Definitely superior over Ubutnu's snaps. As a user you do have to be somewhat aware that the application is running in a sandbox and won't behave exactly like one running without a container. For example the Belgian digital ID card software does not work in a sanboxed browser. At least not by default a the moment.

USB-c Power Delivery does not require an intel CPU, so I don't see a problem.

I think he was referring to the absurd amount of power some Intel CPUs require.

My SO has an AMD gaming laptop that came with a 135W power supply. Surprised the heck out of me as I typically see Lenovo/Apple laptops with 45W or 65W power supplies. Doesn't seem to be an Intel-only thing.

Then other power-hungry device categories will become the beneficiaries of this. External GPUs with a high power draw, for instance.

don't external GPUs have their own power?

Currently they do. They wouldn't need it if such a high-power connection became the norm.

And what if i do not use a debian based distro for which the ppa works?

Maintaining one package that works on all distros is a lot easier.

I honestly believe matrix will become the go to for (federated) messaging everywhere. The element client has much improved and matrix is continuing to get better.

I'll have to try it again, then. On two occasions several months apart, as soon as I tried to use it again it just didn't deliver calls or messages. The only time I tried to use it and it flat out didn't work :/ might see if I can track down the issue through the logs.

FluffyChat is an alternative client that's also pretty far along

Syphon[1] (although open alpha) too.

[1] https://syphon.org/

as someone who just yesterday was working around what seemed to be a Matrix netsplit on our office/community server (coworkers saw different things on mobile vs desktop vs other servers), i feel like you're glamourizing Matrix. We're still hosting it and committed to it for work, but Matrix servers have been so finicky for years (with improvements)

Signal is still the clear winner rn imho

this simply shouldn’t happen; it’s almost unheard of for mobile vs desktop to get out of sync unless the server is super unhealthy. can you file a bug or ping in #synapse:matrix.org so we can try to help?

> This might not be the right place to ask but I've been looking into matrix and am I right that if you don't want to rely on a central authority then you need to run your own homeserver, which at minimum requires a publicly accessibly HTTPS server?

If you run your own homeserver you are completely independent and don't rely on anyone else.

If you want to join the federation and talk to people on other homeservers you do need a publicly accessible web server with a valid TLS certificate (which you can get for free from let's encrypt).

If you only want to chat with people on the same server you can choose not to join the federation, but this is not what matrix was designed for.

> those homeservers seem very public by default if you just want one for your personal use.

You can disallow public user creation in the homeserver config. Then only users you have created can access your homeserver. Of course anyon in the federation can invite your users to a room etc.

> Which makes it seem a bit risky

I don't think there is a very large risk to running your own homeserver (not more than running other services).

A matrix homeserver can require quite some resources depending on how many users you host and how large the rooms are. Also there is some normal administration required (updating, making sure the cert is valid, ...).

Too bad it is a completely proprietary walled garden and that they do not care about privacy or security.

I would love for matrix to eventually replace discord, but ATM discord is still a better user experience.

Yep, The largest threat to the international FOSS collaboration is the US bullying other countries.

> "apt-get" is the classic tool for Windows Subsystem for Linux

APT is the classic tool for debian-like Linux distributions. FTFY

Considering the fact that there are five times as many Android devices as Windows devices, and the greater ease of use of Termux compared to WSL. I find that highly unlikely. Anecdotally every newbie programmer I've seen try to use WSL has just ended up installing Linux in frustration.

> greater ease of use of Termux compared to WSL

pretty subjective, I'm guessing most people find terminal-based stuff easier/nicer on a computer with an actual keyboard, rather than a (relatively) small phone screen with a touchscreen keyboard.

I believe Termux is also pretty majorly restricted by Android 10 (can only run binary code included within the application package, so no downloading additional linux packages or compiling things locally, I believe)

I doubt it pulls in anybody in the unfinished state its in. WSL does not integrate very well and is miserably slow. My 13yo thinkpad runs circles around WSL running on my workstation. WSL2 is still beta, and given how buggy 1909 still is, I am not installing 2004 on anything I care about. And I recently tried Windows Terminal, but it couldn't even give me an admin prompt without giving every single session elevated privileges, so I gave up after 5 minutes.

By the way, every terminal application you're used to (Terminal.app on macOS, iTerm, the Windows Terminal, Ubuntu's Terminal application) is a terminal emulator. I've tried WSL1 and 2 and couldn't get past the typing latency, awful font rendering, incredibly slow downloads, apt/dpkg bugs, and not syncing with the actual filesystem like Linux/macOS do. For example, I like to copy my dotfiles to ~/Dropbox/dotfiles. This isn't possible on Windows, and if you force it to do so it will corrupt the files.

Termux is a lot more than just a terminal emulator.

There are many kinds of linux users, just like there are many kinds of windows users.