> 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
> “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 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.
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.
> 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, ...).
My Guess is that it is mostly a security through obscurity thing for now, we do not know exactly how they mark the audio. When someone figures this out I believe that it should be possible to filter this out.
It would be interesting if they found a way to watermark the audio in such a way that removing the mark makes the audio unusable.
Except that centralization will eventually give rise to corruption =p. It's and endless debate I guess. But for an organization like ICANN my vote goes to decentralization.
Yep, I wished matrix would replace discord and all other proprietary crap. Unfortunately the UX is still a bit lacking, but if you somewhat know what you are doing it's great.
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