On the one hand it provides a greater user-experience if Whatsapp can figure out the URL and preview information about the posted URL (like any social network does today, even we do it at STOMT when you attach an URL to your feedback).
On the other hand i do not get why they send it after every character. Makes it even faster but creates a bunch of unnecessary requests. Not very user friendly. They could do it after they recognize a finished URL (as soon as there is a space). And as pointed out in the tweets it COULD harms the users privacy.
In order to produce the link preview, probably. As far as why it's character by character, I don't know, but that doesn't seem very sinister to me. Checking URLs letter by letter is sloppy, especially if you're not even trying to do auto completion, but it doesn't reveal any more information than a complete url could. Anyway, I would think they are expecting people to paste URLs in, not type them.
I've written code to fetch sites and give a preview, for a bookmarking bookmarklet. This involves analyzing the html for title and to select best image to represent the page. That of course necessitates retrieving the page, either through the client or server.
It's not sinister so much as that Whatsapp is sending the requests directly from the user's phone (not through a proxy, etc) which is exposing the end user's IP address and full user agent string to the website hosting the page. This information could be used to identify the end user which goes against Whatsapp's whole "Privacy and Security is in our DNA" thing. (https://www.whatsapp.com/security/)
Knowing that WhatsApp produces link preview cards, I frankly don't see anything here that I didn't already expect and assume was happening - these cards come from somewhere that is neither me nor my conversation partner. This can't be a surprise to anyone who was concerned about privacy.
If WA proxied the request, it would be WA snooping on the conversation, and that would be a way larger problem because they would accumulate that metadata for EVERYONE.
If you don't want cards or external requests in the conversation, you obfuscate the url with any of the myriad methods people use to get past anti-url filters in forums etc.
I see, thanks. So, the lookup is done from the sender's client, not the recipient, correct?
I was actually looking at it from the perspective of it was being done on the server, rather than the client, and people were concerned about information collection about where they're linking to (or something).
This is a good heads up for people with special security needs using proxies to access HTTP. Most people are willing to visit URLs they send in messages from their IP addresses in a browser, or already have before they send the message, but I can see how it's worth knowing about, especially with the additional information disclosure.
This makes me think of another potential privacy risk: if you paste a URL in WhatsApp, or click Android's share button and select WhatsApp, it doesn't add a space after the url. Most users are probably aware that they have to add a space, but if they forget, WhatsApp will probably send the first word of the rest of the message to the server. (Similarly if you paste a URL at the start of an already-written message, but maybe that's even more contrived.)
I'm going to have to disagree with that. The TLS connection is not part of the conversation... it has no ability to intercept messages, encrypted or otherwise.
It's merely just another e2e communication between the client and another party, albeit through another protocol.
One aspect is the lack of debounce, but also revealing the endusers ip and user agent. They could proxy external link requests via whatsapp servers without breaking end to end encryption. wonder what iMessage does ?!
Could you explain how that would work? Right now they seem to be doing it client side thus not ever seeing the URL themselves. If they were to have a proxy said proxy would need to know the URL to fetch. Is there some alternative solution?
> They could proxy external link requests via whatsapp servers without breaking end to end encryption.
What good is E2E if you are going to send the plaintext home anyway? Doing these requests on the device is stupid, but proxying them through FB servers would border on malicious.
Did you all know that chrome does this too? May sound obvious but I always had assumed that nothing is sent until you press enter for some reason (yeah I know, search prediction would be impossible without that). But one day I was type in a path on a test URL and noticing my server getting hit on - every single letter.
You've got me angrily reading the article while asking myself if WatsApp would be stupid enough to lose that mostly won case. (It's in our supreme court, I hope they will announce it illegal to widely block a communication channel and to coerce companies into releasing broken crypto.)
No, WatsApp didn't get informed of what URL you entered on the message. The site owner gets a notice, as does the user's ISP, and a lot of people in between. But WatsApp can not tell what URL was typed.
Yeah but tbh, its still not e2e encrypted. It just means WhatsApp is ignorant.
So they are in the clear legally, but morally, its still dubious to do that given its effectively disclosing what is often a substantial portion of the conversation.
And, transmitting an URL usually has no use beyond accessing it. They are doing what the user expects, it's just lacking some communication and power-user tools to override the default behavior.
I'm not sure that's what a user would expect; if anything, I'd think users would expect the opposite, that internet requests potentially with identifying information are not being sent to third parties based on what they've typed into the box without hitting send.
> And, transmitting an URL usually has no use beyond accessing it. They are doing what the user expects, it's just lacking some communication and power-user tools to override the default behavior.
Let us just say there are certain things that can cause legal complications merely accessing it and not reporting it is technically still a crime.
WhatsApp is probably the last entity that I would be worried about reading my message. WhatsApp is trying to sell you a promise where nobody, other than the recipient, can know the content of your messages. Having the owner of a site whose URL is included in a WhatsApp message in real time as it is compose breaks that promise - now the site owner and many more people (DNS server operators, both ISPs at the very least) have information about the content of that message.
Yes, Chrome does it as well, but I expect that as it's a web browser. I know the tradeoffs when browsing the web and expect that my requests will be visible across the Internet. That's just how web browsing works.
However, WhatsApp is selling a solution that is meant to provide privacy. When I write a URL in an SMS, my phone does not try to preemptively retrieve it to display a preview. WhatsApp may be encrypting the message, but it's identifying me to a server while I'm composing it, which is enough to completely destroy any level of privacy or anonymity that I would expect.
Maybe not SMS but newer versions of iMessage will prefetch urls to generate a preview. I don't recall if it happens as you type (like WhatsApp) or after you hit send though.
> WhatsApp's end-to-end encryption ensures only you and the person you're communicating with can read what is sent, and nobody in between, not even WhatsApp. This is because your messages are secured with a lock, and only the recipient and you have the special key needed to unlock and read them.
I suppose that I'm not surprised. You can't audit WhatsApp's source code, and even if you could, you can't guarantee what you're putting on your device matches the source code. Yet another closed source, inherently untrustable system.
Even with open source you don't know what you're putting on your device matches the source code (unless you're part of the 0.00001% that would compile their own mobile apps).
Even if WhatsApp is not about privacy there seems to be a difference here.
Am I misunderstanding, or are these requests happening just because someone is typing a message that happens to contain some string that looks like a URL. At least with a browser, you are entering things that are supposed to ultimately result in HTTP requests.
Some browsers may send what you type in the address bar to a search engine - I know that Chrome does. So again, I wouldn't be surprised if this is done - that's what web browsers do. They don't make a claim of providing privacy and security.
Does anyone else really not like autocomplete everywhere constantly sending beacons and data about what you're typing?
I realized I accidentally had a password copied to my clipboard and I pasted into into my address bar. Well great, I didn't push enter, didn't search for the password, but now I have to change my password because it was sent to google because autocomplete.
It's very frustrating because often times people are not aware they are exposing sensitive information via URLs for internal resources.
I posted this not because I was angry on having a GET request sent to my server on a char by char basis. My main concerns were privacy related, since I posted this some additional things came to light:
1) This leaks the IP address of the person writing the msg
2) When property="og:image" is used it also leaks the User Agent and Android version [1]
3) When presented with invalid headers as a reply it can cause a crash on IOS, which mean this is a potential RCE vector [2]
4) It leaks the exact time an URL is typed into a chat
5) It's on by default, this is the default behavior in E2E encrypted conversations [3]
I don't use WhatsApp, I found this out by accident as I just have a habit to tail my logs. I know though that Signal doesn't
do any of this pre-fetching. I am aware this is a 'feature' but there's no place for it when security is involved.
These are all expected behaviors and are the correct decisions if the user expectation is that URLs generate preview cards.
If the connection was not made from the client (aka 'leaks the IP address') then it would need to be proxied (aka central point for 5eyes to monitor to get all WA client urls) or the servers would need to know the contents of the messages (aka break e2e and we are still back to a central monitoring point.)
Of course it will send user agent info, so that it can provide a better preview card if the site supports taking advantage of this info. If it only provides this when you explicitly try to send the info then it is doing what the user told it to do.
The header bug is interesting and if it is actually a WA problem you should report it.
Of course it leaks the exact time a URL is typed into chat. I can't even imagine what you are trying to say here since this is a point that is without a point. We have already established what it is trying to do and in that context this point makes no sense.
It is on by default and is the default behavior because this is what users expect. The secure features of WA are a bonus, but are not the raison d'etre here and when it comes down to it WA is a messaging app and it prioritizes usability when the feature is not an egregious security problem. In this case it is not a major security problem so usability and expectations win.
68 comments
[ 3.9 ms ] story [ 116 ms ] threadSomeone down at HQ is laughing their asses off right now.
simple really
[0]https://pbs.twimg.com/media/DCRsz7mXUAAEbKK.jpg [1]https://pbs.twimg.com/media/DCSyWs0XcAAQb2N.jpg
On the other hand i do not get why they send it after every character. Makes it even faster but creates a bunch of unnecessary requests. Not very user friendly. They could do it after they recognize a finished URL (as soon as there is a space). And as pointed out in the tweets it COULD harms the users privacy.
I've written code to fetch sites and give a preview, for a bookmarking bookmarklet. This involves analyzing the html for title and to select best image to represent the page. That of course necessitates retrieving the page, either through the client or server.
See this tweet for the info exposed: https://twitter.com/0xjomo/status/874585822158352384
They did the right thing here. It might be good to add a "do not show URL previews" option, but it's not currently broken.
If WA proxied the request, it would be WA snooping on the conversation, and that would be a way larger problem because they would accumulate that metadata for EVERYONE.
If you don't want cards or external requests in the conversation, you obfuscate the url with any of the myriad methods people use to get past anti-url filters in forums etc.
I was actually looking at it from the perspective of it was being done on the server, rather than the client, and people were concerned about information collection about where they're linking to (or something).
This is a good heads up for people with special security needs using proxies to access HTTP. Most people are willing to visit URLs they send in messages from their IP addresses in a browser, or already have before they send the message, but I can see how it's worth knowing about, especially with the additional information disclosure.
Pick one.
Why is no one saying anything about end to end crypto?
Whatsapp shouldn't be able to see my messages, isn't that what they say themselves?
doing a GET request over the internet is already violating e2e
It's merely just another e2e communication between the client and another party, albeit through another protocol.
Telegram seems to proxy the requests.
So Whatsapp wins with crypto here.
What good is E2E if you are going to send the plaintext home anyway? Doing these requests on the device is stupid, but proxying them through FB servers would border on malicious.
Facebook has literally told courts they can't decrypt WhatApp traffic. I wonder if that court case in Brazil is still pending.
By comparison, no one ever said "There's no way Google could read my search terms".
A more accurate comparison would be regarding Allo.
Yeah this is a much bigger deal, for sure, as it's a messaging app - just pointing out similar case in a different application.
No, WatsApp didn't get informed of what URL you entered on the message. The site owner gets a notice, as does the user's ISP, and a lot of people in between. But WatsApp can not tell what URL was typed.
So they are in the clear legally, but morally, its still dubious to do that given its effectively disclosing what is often a substantial portion of the conversation.
And, transmitting an URL usually has no use beyond accessing it. They are doing what the user expects, it's just lacking some communication and power-user tools to override the default behavior.
Let us just say there are certain things that can cause legal complications merely accessing it and not reporting it is technically still a crime.
http://www.stf.jus.br/portal/processo/verProcessoAndamento.a...
However, WhatsApp is selling a solution that is meant to provide privacy. When I write a URL in an SMS, my phone does not try to preemptively retrieve it to display a preview. WhatsApp may be encrypting the message, but it's identifying me to a server while I'm composing it, which is enough to completely destroy any level of privacy or anonymity that I would expect.
Yep you are right. They even tout this in their Security Page.
https://www.whatsapp.com/security/
> WhatsApp's end-to-end encryption ensures only you and the person you're communicating with can read what is sent, and nobody in between, not even WhatsApp. This is because your messages are secured with a lock, and only the recipient and you have the special key needed to unlock and read them.
Am I misunderstanding, or are these requests happening just because someone is typing a message that happens to contain some string that looks like a URL. At least with a browser, you are entering things that are supposed to ultimately result in HTTP requests.
I realized I accidentally had a password copied to my clipboard and I pasted into into my address bar. Well great, I didn't push enter, didn't search for the password, but now I have to change my password because it was sent to google because autocomplete.
It's very frustrating because often times people are not aware they are exposing sensitive information via URLs for internal resources.
I posted this not because I was angry on having a GET request sent to my server on a char by char basis. My main concerns were privacy related, since I posted this some additional things came to light:
1) This leaks the IP address of the person writing the msg
2) When property="og:image" is used it also leaks the User Agent and Android version [1]
3) When presented with invalid headers as a reply it can cause a crash on IOS, which mean this is a potential RCE vector [2]
4) It leaks the exact time an URL is typed into a chat
5) It's on by default, this is the default behavior in E2E encrypted conversations [3]
I don't use WhatsApp, I found this out by accident as I just have a habit to tail my logs. I know though that Signal doesn't do any of this pre-fetching. I am aware this is a 'feature' but there's no place for it when security is involved.
[1] https://twitter.com/0xjomo/status/874585822158352384 [2] https://twitter.com/dr4ys3n/status/874725257722179584 [3] https://mastodon.social/@rysiek/9146943
If the connection was not made from the client (aka 'leaks the IP address') then it would need to be proxied (aka central point for 5eyes to monitor to get all WA client urls) or the servers would need to know the contents of the messages (aka break e2e and we are still back to a central monitoring point.)
Of course it will send user agent info, so that it can provide a better preview card if the site supports taking advantage of this info. If it only provides this when you explicitly try to send the info then it is doing what the user told it to do.
The header bug is interesting and if it is actually a WA problem you should report it.
Of course it leaks the exact time a URL is typed into chat. I can't even imagine what you are trying to say here since this is a point that is without a point. We have already established what it is trying to do and in that context this point makes no sense.
It is on by default and is the default behavior because this is what users expect. The secure features of WA are a bonus, but are not the raison d'etre here and when it comes down to it WA is a messaging app and it prioritizes usability when the feature is not an egregious security problem. In this case it is not a major security problem so usability and expectations win.