It's a possibility, but it's not how these kernel panic viewer websites are currently implemented. They do the decoding on the clientside, with the data stored in the URL fragment, which is not sent to the server by default.
Still good to have alternative implementations, though. The Javascript could be silently stealing the URL fragment on only specific requests, so there's no real way to audit it to be sure.
If you decode it and open the link, you are potentially leaking data to whoever controls the domain of the URL.
It's a possibility, but it's not how these kernel panic viewer websites are currently implemented. They do the decoding on the clientside, with the data stored in the URL fragment, which is not sent to the server by default.
Still good to have alternative implementations, though. The Javascript could be silently stealing the URL fragment on only specific requests, so there's no real way to audit it to be sure.
Link previews even! Just paste it into a group chat and everyone’s message clients will happily issue a GET request.
That's not how it works. The chat app requests the link preview and caches it.
This sounds like the panicky adverts from 20-odd years ago "YOUR COMPUTER IS LEAKING YOUR IP ADDRESS!!11!!""2!!2!!"
You can decode a QR code by hand. It’s usually not worth your while but it’s understandable.
This is about a second step of decoding.
Qr -> URL -> Panic Log