Hacker News new | past | comments | ask | show | jobs | submit login

Hi HN, op here.

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




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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: