digitalcourage.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Diese Instanz wird betrieben von Digitalcourage e.V. für die Allgemeinheit. Damit wir das nachhaltig tun können, erheben wir einen jährlichen Vorausbeitrag von 1€/Monat per SEPA-Lastschrifteinzug.

Server stats:

817
active users

Lenny

Staggering how far will go to de-anonymise users.

arstechnica.com/security/2025/

I was actually surprised it took so long because this is not a new loophole. We discussed this issue almost 10 years ago in a different context: allows to circumvent the secure origin policy.

github.com/w3c/webappsec-csp/i

I made a PoC back then

lgrahl.de/examples/dc/webrtc-c

which still works to this day. It is also hard to prevent because the PoC doesn't do anything that is forbidden. It leverages a currently essential part of the STUN protocol.

Don't get me wrong, I'm all in for making an effort to remove all user-controllable input, but now we might see shortcuts being taken to get things fixed quickly, potentially destroying a bunch of nice and niche use cases along the way.

Ars Technica · Meta and Yandex are de-anonymizing Android users’ web browsing identifiersBy Dan Goodin

And I might have an idea on how to fix the STUN protocol to prevent this: How about we don't send ICE username and password in clear but as a salted hash. The salt is sent along in the STUN binding request, right next to the hashed ICE username.

The result would be that the input is still user controlled but the input itself is never actually exchanged, nor is it static, so it can't be used for exfiltration or fingerprinting.

Instead of

USERNAME:
- Username: foo:haxx0r

it would be

HASHED-USERNAME:
- Salt: <random N bytes>
- Hashed-Username: your-favourite-hash-algorithm(salt, 'foo:haxx0r')

There are potentially some other user-controlled values (like TURN credentials) which are then hopefully fixable in a similar fashion.