It looks like a dirty hack, but works quite nicely.
However, I couldn't figure out how the webapp works:
why do I have to scan a QR code?
why does the mobile application has to be connected to the internet the whole time?
what kind of communication is happening?
is there any speculation about that?
Perhaps the QR scanning connects the phone and the browser via some token stored somewhere and used to both authenticate and send/receive messages.
Think of the "token" as a channel. Phone sends all messages to that channel. Browser gets messages from the channel.
This is obviously not the whole picture. For example, the web app can scroll back and "load" previous messages.
It's weird though. Why would they go through such a router? It would make a lot more sense to just use the QR scanning to authenticate, and then let the browser receive messages in the same way that the phone app does: directly from the server(s).
(Note: I have an iPhone and so can't test it myself, but I can read the client js code)
My guess is that they are routed through the phone. That's certainly something that Apple would have a hard time allowing which might explain the android onlyness. They are clearly using WebSockets and the phone receives messages but only in so far as the phone. For a E2E encryption they would have to routed through the phone, which it seems they are from the look of their code. Again only guessing, someone should packet sniff it and lmk.
Based on your speculations I'd say that the QRCode is the IP adress of the WebApp + some kind of token.
Scanning it allows the phone to connect to the browser and act as a proxy to transfer messages?
I'd guess its some form of transient-key cryptography. When you scan the QR code, the smartphone app tells the WA servers to 'allow' the web browser to send/receive messages as itself.
Thinking a bit more it could be that the messages are routed through the phone itself, and so it requires the app to be running and connected.
The QR code contains data unique to your web session. You're already authenticated to WhatsApp on your phone. So the data in that QR code is sent back to WhatsApp's web server, through your phone, and they connect the open web session to your account. Websockets make it seamless.
Perhaps the QR scanning connects the phone and the browser via some token stored somewhere and used to both authenticate and send/receive messages.
Think of the "token" as a channel. Phone sends all messages to that channel. Browser gets messages from the channel.
This is obviously not the whole picture. For example, the web app can scroll back and "load" previous messages.
It's weird though. Why would they go through such a router? It would make a lot more sense to just use the QR scanning to authenticate, and then let the browser receive messages in the same way that the phone app does: directly from the server(s).