tobykurien
Support for WhatsApp Web
Hello, I was wondering if WhatsApp Web could work in WebApps. I tried and it worked only the first time. Following times there is (seems) to be a redirect to another domain, so it is unusable.
Information: OS: LineageOS 15.1-20180821-NIGHTLY (Android 8.1.0) WebApps version: 2.18 (installed from F-Droid repo)
Steps to reproduce the problem:
- Open WebApps
- Go to settings and set the User Agent to Desktop (If you don't do this step, you will can't see the QR code, even if you change the User Agent later in the sand box)
- Open a new site, Insert https://web.whatsapp.com/ as the URL and opening it in a new sandbox.
- You will see the QR code,
- Scan the QR code from a second phone using WhatsApp's feature to start a web session.
- The first phone will load a new page, showing your chats. Up to here all is working fine.
- Save the sandbox as Webapp.
- Close the sandbox
- Start the saved sandbox. The page that is being loaded in the sandbox is https://www.whatsapp.com/ and not https://web.whatsapp.com/ (checked by using share URL). In that page, there is a link to go to WhatsApp Web, but clicking it stills show https://www.whatsapp.com/.
Now, if you open a new site again, insert https://web.whatsapp.com/ as the URL and open it in a new sandbox. You will see that you ended up in https://www.whatsapp.com/ again. Unlocking 3rd party domains doesn't help.
If you clear the cache and data of WebApps, it will work one more time.
Expected behavior The expected behavior will be to still be in the web session showing your chats.
What's the use case? WhatsApp is a closed source app. You could let it run in an old phone in your home (or maybe in an Android VM), and in your main phone you can use WebApps + WhatsApp Web. This means, that with a FLOSS app you could chat with your friends.
I was trying in DuckDuckGo browser (also in F-droid), and I see the same problem.
I realized that the steps to reproduce the problem could be shortened.
- Clear cache and data of WebApps in Android's settings (a fresh start of WebApps)
- Open WebApps
- Go to settings and set the User Agent to Desktop.
- Open a new site, Insert https://web.whatsapp.com/ as the URL and opening it in a new sandbox.
- You will be in https://web.whatsapp.com/, and you will see the QR code.
- Do not save the sandbox. Just go back to the list of sandboxes of WebApps.
- Open a new site, Insert https://web.whatsapp.com/ as the URL and opening it in a new sandbox again.
- WebApps will try to go to https://web.whatsapp.com/ but will be redirected to https://www.whatsapp.com/.
I could be wrong, but I'm thinking that WhatsApp servers are doing a kind of tracking. A tracking that might be surpassing the sandboxes of WebApps. The only way to defeat the tracking is by clearing the cache and data of the app.
It is possible to use the shared cache as a way to store tracking data, e.g. a javascript file that gets cached.
Ok I understand, but in that case there is a leak in the sandbox, because even if I start a new sandbox they can still do tracking. I would expect that a new sandbox be a fresh start, like clearing cache and data in Android's settings does.
In the other hand, I think that we could generalize the process as two requests 1.- WebApps sending a request to web.whatsapp.com, and landing in web.whatsapp.com. 2.- WebApps sending a request to web.whatsapp.com again, and landing in www.whatsapp.com
A normal browser in a desktop always land in web.whatsapp.com. There might be something that they are spotting that tells them that it is not a desktop, that it is still a mobile. What could be the difference? I
I'm thinking in the User Agent, but then, why they don't filter it the first time? I will rebuild WebApps with a different User Agent. It could be the resolution. They only get the resolution of the screen once they have displayed the webpage. I will try to changing the DPI (display size).
Ok, I have rebuilt WebApps using the following User Agent taken from User-Agent Switcher plugin for Firefox/Chrome: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.9 Safari/537.36
The problem persist. :/
I too am trying to find a solution similar to this to use Whatsapp Web on mobile, to be able to see full resolution pictures without giving the Storage permission.
I checked, and as soon as web.whatsapp.com receives any request with a mobile UA, it sends a 302 which redirects to the main domain.
$ curl --http1.1 -vv 'https://web.whatsapp.com' -H 'User-Agent: Mozilla/5.0 (Android 8.1.0; Mobile; rv:64.0) Gecko/64.0 Firefox/64.0'
< HTTP/1.1 302 Found
< Location: https://www.whatsapp.com/
$ curl --http1.1 -vv 'https://web.whatsapp.com' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0'
< HTTP/1.1 200 OK
It seems this redirects are handled by the WebView on a lower level, as soon as that 302 appears it never returns. Better dive into the code.
https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldOverrideUrlLoading(android.webkit.WebView,%20android.webkit.WebResourceRequest)
It seems to be possible to at least prevent this redirect. What needs to be done is to completely disallow any possible request with the mobile UA, to avoid poisoning the webview redirect cache. It seems something client-side, since you already mentioned clearing the storage data brings back the correct behaviour.
Maybe something to do with fetching the favicon?
The UserAgent could be spoofed just as you pointed out. But I'm thinking that the problem is within WebView. WebView is adding 'X-Requested-With' header, which shows which app is doing the request. 'com.tobykurien.webapps' in the case of WebApps. This header could be disabled only in the first request, the request of the .html file, but not in following requests, like in images, .js and .css files
More information about the problem here: https://www.stoutner.com/the-x-requested-with-header/
Other browsers based on WebView have the same problem: https://github.com/mozilla-mobile/focus-android/issues/1196 https://github.com/duckduckgo/Android/issues/315 https://github.com/anthonycr/Lightning-Browser/issues/317
Off topic: @somini
Browsers not based in WebView, like Fennec (Firefox) or Firefox Klar (Firefox Focus), both in F-Droid's repos, can be used with Whatsapp web service, just remember to do the request as desktop, not mobile.
I were using them until an app called "Shelter" (free/open Source) came up in F-Droid. It creates an isolated space (a work profile). You may want to take a look at it. You may want to install Whatsapp in the isolated profile. Whatsapp will request access to storage, if you granted it, it will access files in the work profile, but it will not, I think, have access to files in your main profile (I haven't been able to attach a photo taken from the camera in the main profile). Maybe Whatsapp can still see the files with an exploit to the system (you know, you can't trust in a closed source app).
Browsers not based in WebView, like Fennec (Firefox) or Firefox Klar (Firefox Focus)
I think Firefox Focus is just a WebView, if I'm not mistaken. At least it's WebKit...
just remember to do the request as desktop
I want something that Just Works. The redirect means I can't forget it ever, or the app data is poisoned and I need to start over. I did it on my main browser (Firefox) and it's already poisoned. :D
Thanks for the pointer to Shelter, I'll investigate.
In the meantime https://f-droid.org/packages/io.kuenzler.whatsappwebtogo/ could be a solution.
