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

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.