Reporting a user to WhatsApp forwards a copy of recent messages from that chat
wabetainfo.com
wabetainfo.com
This feature is just an extension of manually making a screenshot and attaching it to the messages. As much as I like E2EE, I don't see where the problem lies? It's you who opts in into getting a third party involved. E2EE doesn't mean that no third party is ever going to see the content, it only means that nobody sees it by default.
The only case where the current E2EE security model is changed is when the protocol gains a feature to enable the client to attach a cryptographic proof about the message's content. That would violate the non-repudiation properties of the Signal protocol, but it would make reports more believable as you can't fake them any more with a modified client. As I've said I don't know the implementation, but it's entirely possible that they didn't include any cryptographic proof and keep it equivalent to screenshotting.
Signal achieves non-repudiation by allowing forgery of messages after they have been transferred and verified by the receiver. It is not possible to undo that. You would have to make a special exception at the time the message was transferred which wouldn't be practical in this case.
This all assumes that you believe that establishing forgeability actually achieves non-repudiation in the first place. Facebook might want to pass along the signature information anyway.
If there is a risk that the user doesn't know that the correspondence is sent if they hit the report button, then fb should add a warning, but the feature itself is fine IMO.
~~Even worse, 3 letter agencies~~
Forget I said anything
This feature does not change the privacy story for WhatsApp in any way. You already trust users you are chatting with to not copy or screenshot private messages and share them. You already trust the app to not forward or store your messages without your consent.
[1] See bullet point "Your Messages" under section "Information We Collect" on https://www.whatsapp.com/legal/privacy-policy.
For example rooting a phone by hand is pretty hard. Many tools exist to do it automatically.
That assumes that the decrypted messages aren't signed (e.g. via HMAC), no?
But there are plenty of other ways to implement this. Digital signatures. Or if facebook stores the ciphertext, the recipient could simply reveal the decryption key for the message. Or facebook could compute a MAC over the ciphertext with a key neither participant knows, then the recipient could reveal the ciphertext and decryption key, and facebook could verify the outer MAC to verify authenticity.
It's a step along a continuum where the end-to-end encrypted messenger wasn't uploading plaintext before, and now it is.
Apple's similar previously end-to-end encrypted iMessage went through a similar evolution: now iOS uploads the complete iMessage plaintext history to Apple (with Apple keys) via iCloud Backup.
We now know that Facebook deems it okay to exfiltrate plaintext, post-decryption, from the device in certain circumstances. This means we need to be cognizant and vigilant around the precise nature and boundaries of those circumstances, because "plaintext doesn't leave the device and get transmitted to Facebook" is no longer true.
A tap or two by one of the people you're talking to could upload your decrypted plaintext directly to the person-in-the-middle; this is a relatively significant footgun that we should remain aware of.
Regarding the iMessage backup thing, I fully agree with you that it's a major problem. But it's a different thing.
Also, again, the feature already exists. You can already make screenshots and share them with facebook, with the world, etc. There are entire subreddits that publicly share IM histories with people. This is nothing that facebook can initiate. If the feature gets changed to something that they can initiate, I would agree that it's bad. But this isn't.
It's certainly a different product thing, yes. But from an Alice-Mallory-Bob end-to-end encryption block diagram it's the exact same thing: Bob's device is sending Alice's plaintext, post-decryption, to Mallory (using Mallory's TLS keys).
> If the feature gets changed to something that they can initiate, I would agree that it's bad. But this isn't.
Considering that many (most?) users have app auto-update turned on, it's not entirely certain that Facebook can't initiate it.
I've read HN comments about it, but when I've tried to understand it by searching around it looks like it is encrypted end-to-end and in iCloud backup (as long as you're not in China).
https://support.apple.com/en-us/HT209110#:~:text=We%20design....
https://support.apple.com/en-us/HT202303
Is there some subtlety I'm missing?
That said, on this particular issue I think FB is striking a pretty good middle ground. Keeping things encrypted end-to-end for users, but allowing users to voluntarily report decrypted messages from their end is a good way to combat child abuse imagery and other illegal content without giving FB or governments back door key access.
I have a friend on the data science team at whatsapp and his team is responsible for combatting child abuse imagery groups on whatsapp - it's a huge problem.
A related comment I wrote when this came up previously: https://news.ycombinator.com/item?id=23553997
> Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.
Note that all of the following are entirely different services:
- iMessage (nominally e2e)
- Messages in iCloud (e2e, but with the key stored in iCloud Backup if enabled) - this is a way of synchronizing iMessages across all of your devices (independent of backups)
- iCloud Backup (not e2e)
iCloud Backup is backing up either iMessage plaintext (if Messages in iCloud is off) or iMessage decryption keys (if Messages in iCloud is on), to Apple keys. In private conversations with Apple employees, I understood that this was to be fixed, but then the fix was never released. Then I read this:
https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
You can test this state of affairs trivially:
1. Get an iPhone, turn on iCloud Backup and iMessage.
2. Send and receive some iMessages, and do a backup.
3. Throw the iPhone into the river.
4. Call Apple, and claim you forgot your Apple ID password, and need to reset it. They will verify your identity using other information, and reset your Apple ID password.
5. Get a new iPhone. Log in with your reset Apple ID password, and restore from backup.
6. See message plaintext, decrypted with no key from you, your password, or your now-riverbed-domiciled old phone.
Apple can decrypt full iCloud Backups without the user's password, or the user's device. These backups contain message history, message attachments, and iMessage decryption keys (which can be used to decrypt iMessage ciphertext which has already transited Apple's iMessage service).
Apple is very careful not to ever explicitly lie, but to also say things in such a way that leads people to believe things (that benefit Apple) that aren't strictly true. HT202303 is a very good example of that style. If you don't have a detailed understanding of the different services ("iMessage", "Messages in iCloud", "iCloud Backup", et c) then you will likely misunderstand the statements.
There is no problem. I'm just informing people reading HN of this change. Your messages will now be sent when you report a person/group.
They have added this power to read user data when you report it. All of which I have included in the title.
>for the obvious reason that reporting a user would be meaningless without that.
This is a change from past behavior. WhatsApp didn't forward a copy of messages when you reported people previously. Now they do. Which is what I clearly mentioned in the title. This meaningless way of reporting people was what users were used to.
None of the comments commenting about click-bait are mentioning what is factually wrong with the title. They are just saying they understood it different, which is okay.
If you report them to any other place, like police, HR, etc, you'll likely have to show the discussion as well, or at least tell them about its contents.
This is not a slippery slope, at least not right now.
https://faq.whatsapp.com/android/chats/about-google-drive-ba...
The funny thing is that I cannot find a way to access that backup myself, is anyone aware of a method to download that backup as a data dump and inspect it?
98% of users enable that option. The fact that whatsapp is e2ee is a complete lie.
Use Signal for true e2ee, or if you don't like it, Telegram. Telegram stores everything in the cloud tho. (they haven't disclosed any private messages, and are much more trustworthy than Whatsapp). They just wanted to back up messages without giving it to Google/Apple
It has a good UX which is rare for open source apps. It seems to be based around a decent community. But I don't know why I don't use it.
Even the e2ee thing is not audited properly.
They are just more trustworthy, have open source apps, better usability [ and unlimited storage :) ] .
Signal > Telegram > Whatsapp
IIRC it is stored in your Google Drive under an API key that is dedicated to whatsapp (in some kind of per-app storage). I don't really know much about Google Drive API.
However, I am fairly sure that the key is in the binary on your phone, so it shouldn't be much of a challenge to get access.
I think there was something like this on Github once, that no longer works (due to trivial changes, likely).
Update: https://github.com/YuriCosta/WhatsApp-GD-Extractor-Multithre...
Looks recent, didn't try myself.
I got an iPhone SE and turns out I can't really import the Android backup on an iPhone, and there's no way to access it either.
Some backup.
Damnit why is everything related to mobile so needlessly fecking difficult. I just want to read some damn plain text files that are right there but it doesn't allow me to access for no reason in particular. I hate everything about mobile so much.
The main problem here is that like everything FB related, you are the product, not the customer At least, I haven't found any reasonable explanation about why Google and Apple get an unencrypted copy of your chat history but you can't. (And not for lack of trying - there are always ridiculous answers on Reddit and HN about "but if you could read your messages, so can the bad guys")
This is a pretty bold claim. Do you have a citation for this?
How about instead of guessing and concluding it must be compromised (argument from ignorance), you do a cursory search and get an actual response?
https://security.stackexchange.com/questions/148321/how-does...
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
As for your link, I'm aware how they claim it works, and even if that is all true (we can't audit the source code), then it is still a compromise of E2EE. E2EE is between two devices, a receiver and a sender. The third device also able to receive, without the sender knowing or agreeing about it, is dangerous. Why? Because you can't know for sure the receiver has access to both machines. If you consider laptop and PCs are much less safe than mobile devices, then the danger is obvious.
I don't get it. Does that mean if I have PGP installed on my desktop, and I also have a VNC server installed on it, it's no longer E2E? That seems like an arbitrary distinction to me. If you extend this further, you could also argue that being able to print out the message, or even have a second person look at the screen breaks E2E. I think the main point of E2E is that unauthorized third parties (including service providers) can't read the message, not that only two devices can read the message.
Alice uses a smartphone and a laptop with WhatsApp. Bob only uses a smartphone with WhatsApp. Alice and Bob discuss something secret. Alice assumes only Bob's (secure) smartphone can read the data. Bob assumes only Alice's (secure) smartphone can read the data. They both got physical access to the smartphone, which lowers the attack surface at that moment. Alice's laptop is in her house. As is Mallory.
My problem with above isn't that this works; it is how it works. My problem is that Alice never temporary authorizes WhatsApp Web. My problem is that Bob doesn't know about Alice's 2nd device. These 2 issues are issues which can be addressed and raise the privacy of the data considerably. The gut reaction "oh, its E2EE, so its secure." is dangerous, and untrue.
Yes, I'm aware you can make screenshots and print chats. You can also send temporary messages with Signal though. That's on top of E2EE, because E2EE isn't a panacea.
But there's nothing wrong in this particular change. It happens when you report someone as spam, and you get a clear notification about what's going on.
There's a "cancel" button as big as the "report" button, so you can bail out if you disagree.
There is a 80 character limit.
Btw I meant it as a warning. Your messages may be uploaded when you report a user
By selecting a specific part of the article to highlight in the title, you introduce your own bias before people even begin reading.
Stick to the Submissions Guidelines [1], and use the original title.
“WhatsApp beta for Android 2.20.206.3”
[1] https://news.ycombinator.com/newsguidelines.html
> Please use the original title, unless it is misleading or linkbait; don't editorialize
Sorry but there is zero information in that title. I'm not going to use that. The intention of my post is to make more people aware of this new 'feature'.
If some other user had posted this article with that title, I wouldn't have clicked it and I wouldn't have know of this new change.
That’s exactly the point. The current title is clickbait. If you think the original title is boring, it’s because this is a boring piece of news.
I wouldn’t be worried about “warning” people, since WhatsApp already warns people when they click the report button:
> Most recent messages from this user will be forwarded to WhatsApp
Can you state anything factually wrong with the title? Wikipedia states clickbait as misleading.
Now that I think of it, I should have used 'will' instead of 'can'. You don't have any choice, which 'can' might imply. But that would be even more clickbaity based on your assessment
>I wouldn’t be worried about “warning” people
Okay. I wanted to warn people even before they get this update, so I posted it.
Recent news surrounding WhatsApp has people worried that they’re going to start breaking encryption and violating people’s privacy.
When I first read the title, I thought that WhatsApp was sending a copy of your messages when you report someone without telling you. I’m certain it wasn’t your intent to convey this meaning, but based upon other people’s reactions to the title, I don’t think I’m the only one who read it this way.
> “Users may send recent chat history when reporting”
because that is false. According to the article, you have no choice as to whether you send that chat history. It is a _must_ if you want to report.
Your new suggestion is just as bad because it throws out all context about why anyone would care about just another beta. This isn’t a software release track announcement board.
“Users can now report a copy of recent messages to WhatsApp”
Isn't that wrong? You can only report people, not messages. When you report a person, the messages are sent
> If it's criminal harassment that won't end, you call the police.
This is funny because you clearly haven't realised the police normally won't do anything.
Reporting is necessary if it's spam, harrassment, child porn, etc.
I feel like you're out of touch with the use cases of WhatsApp.
The child porn scenario just seems so bizarre, why would someone send you child porn? And I'm pretty sure the police will get involved in that case.
> If it's someone spamming random numbers, a simple algorithm can raise a flag without any report necessary.
Yet every single major company uses reports as part of their algorithm.
> The child porn scenario just seems so bizarre, why would someone send you child porn? And I'm pretty sure the police will get involved in that case.
That they would but lots of people would much prefer it if the sicko was quickly stop from spreading it further. And there are groups on nearly every chat system that allows private chat groups where they'll send illegal porn etc. It is easy enough to send a message to the wrong person, I am sure you've done it just like I have only with no consquences other embarrassment and saying wrong person.
Obviously, I have no evidence for making such a claim. What I know is
1. Facebook's reputation with regards to privacy.
2. The fact that they paid 20 billion dollars to buy a product without a monetization model. (Which is 20 times more than they paid for Instagram by the way.)
3. Whatsapp's founder left the company after the acquisition due to privacy concerns.
It's enough to be more than suspicious.
When the NSA was talking about metadata collection, they said it was more useful than actual data. Likely because it's already computer consumable, and less dense.
If FB gets your contact lists, and sees who you message, how much, and when, that's probably a hugely valuable commodity to them.
However, metadata is always what it is. If you have someone who is distance 2 from 20 people who died unnaturally, but not distance 1 - that person is likely related to their untimely death.
The reason metadata is useful is because, unlike the text, it is generally required to be unobfuscated to 3rd parties for the communication to be useful to the 1st and 2nd parties.
Just to be clear here, is this your speculation or a known thing?
In India, the popularity of whatsapp is insane. They could run it worldwide by just showing ads to like half of Indian users
I included ' can read when you report'.
The reporting is opt in. The sending of messages tied to the reporting is not
All end to end encryption does is protect you from eve spying on conversations between Alice and bob. Nothing prevents Bob from doxing/publishing all of Alice’s messages.
Edit: it’s true that the signal protocol provides deniability for messages but if Bob publishes Alice’s messages and whatsapp can prove that bob sent and Alice received messages that match those time stamps...
This is why signal deleting logs matters.
The best you can do is not make it possible for Bob to prove that the messages were not forged (however, this is not necessarily a good thing, and in fact the opposite can often be better).
Of course, there's no "reason" field on the report interface, so WatsApp probably won't guess that.
Now change "trampling kittens" for any kinds of unwanted messages.
https://www.flyertalk.com/forum/travel-technology/952359-tho...
And especially his post in 2014 how the takeover deal was interfering with his award ticket
https://www.flyertalk.com/forum/travel-technology/952359-tho...
Yes, they cannot get the messages from the wire, but they are brazen enough to introduce (more[1]) ways to get hold of your messages anyway.
I used to be a "living billboard" for WhatsApp until Facebook bought them and I am sad to say I was correct: they didn't spend 17bn on WhatsApp and then remove the revenue stream from it just because of the goodness of their hearts :-/
[1]: They already upload your messages in an unencrypted file to either Google Cloud or iCloud anyway if you don't actively turn it off - and get all your contacts to do the same.
Would anyone be able to explain it to me? And what kind of extra data did facebook likely receive from adding that feature (which I think coincided with when the creators started to get very unsettled at Facebook).
I included 'can', and I clearly mentioned 'when you report'
"WhatsApp gives option to include recent messages when reporting bad behavior"
'Most recent messages will be forwarded to Whatsapp'
Is this true or are the messages randomly garbled each time so that there is no way for Facebook to figure out the main content
It seems like i get ads based on my WhatsApp messages, but this could be conjecture
Anyone knows how far along (or canceled) that plan is?
Zuckerberg said instead of removing Whatsapp's e2ee, he would add e2ee to Instagram and Messenger and then 'unify the backend',
We both know how likely that is, and how long that will take to be implemented (if implemented at all)
As a other comments in this discussion pointed, e2ee means nothing because (a) the client is closed source, auto-updating, and (b) 98%[0] of the users use Google's cloud backup which is unencrypted (and I suspect was done that way to have a quickly-wiretappable change to the WhatsApp ecosystem without making it patently obvious)
[0] Don't know where that comment took the number from, but it jives with my personal experience. I don't know if it is encrypted on iCloud for iPhone users.
I wonder if they are using the What's App Erlang infrastructure or if they are moving away from Erlang instead.
Do you trust the author of the program? Then E2E doesn't add much. Do you not trust the author of the program? E2E doesn't help. Either way, what's the point? Sure, I guess E2E provides some kind of additional privacy at the margin or something, but you can't rely on it for anything.
The real question is how do you establish trust in the code you run and while OSS provides benefits at the margin or something, you can’t really rely on it for anything.
For an example to illustrate the fallacious reasoning of OSS = trust, consider the malicious compiler that Ken Thompson presented[1].
If I want to do this for any particular package as a one-off, it's two commands.
Again, I’m not saying these aren’t valuable things that make attacks more difficult/expensive but the uncomfortable truth is we haven’t figured out how to truly establish zero-knowledge trust. So on that spectrum, ultimately Guix + OSS is closer to WhatsApp than where we’d like to be.
Maybe the current state is closer to WhatsApp than where we'd really like to be, but that should be a challenge rather than a reason to give up.
I'm curious if you've actually had a chance to read Ken Thompson's compiler virus hack. The Guix bootstrap path from stage0 still doesn't solve the problem as at the end of the day all compilers eventually self-host from a previous version. So whatever compiler you're using for stage0 can have the virus, inject it into the produced binary, & you'll never find it since the virus is in the binary not in the source. Now obviously this is an extreme example and no one actually has any knowledge of whether or not such attacks are practical or have existence proofs beyond a proof of concept.
My overall point though is that everything boils down to trust & the question is who you choose to trust & where. Ultimately, we're all "careless" on that front as there's just too many dimensions to evaluate on. Beyond just basic malware packaged with the code, is the privacy being respected? Are the security practices good enough to withstand attacks? etc etc. Complaining that WhatsApp is slurping a copy of your messages that you are reporting to them & therefore E2E encryption isn't valuable is a fallacious & misdirected argument IMHO.
The point of stage0 is that it doesn't need to be compiled, only assembled, and that it's small enough to inspect the binary or assemble it by hand if you really wanted to. (Not that you necessarily want to, but if you have to...)
More generally each language would need it’s own path from this basic assembler to a compiler implementing that language in C which doesn’t necessarily exist. While initial versions of the Rust compiler were written in C, more recent versions are self hosted and rely on the previous version. This goes for projects like LLVM too since it requires a c++14 compiler to start with.
A better approach is to figure out how to cross compile stage0 and how to make sure the cross compilation step can be trusted. Going the approach of trying to build a “trusted” path from source is noble but IMO ultimately futile.
This is what I mean when I say this as an unsolved problem. It may be getting better but there are fundamental unsolved challenges to this exploration and very little guarantee the task can be accomplished in the first place (ie no mathematical theory that might present a path to follow rather than just trying to accomplish it through sheer effort). Some small part of the problem might get solved but that’s very different from saying that any package will be verifiable in this way.
What would be the stage0 path to running OCaml?
I would probably go via mrustc rather than via OCaml. It saves a lot of builds.
Yep, that's the one.
>More generally each language would need it’s own path from this basic assembler to a compiler implementing that language in C which doesn’t necessarily exist. While initial versions of the Rust compiler were written in C, more recent versions are self hosted and rely on the previous version. This goes for projects like LLVM too since it requires a c++14 compiler to start with.
Sure. This part has largely been done for many languages, including Rust: https://guix.gnu.org/blog/2018/bootstrapping-rust/
...and there's a bootstrap path for the bottom of that graph all the way from Guix's (fairly minimal but not quite stage0 yet) bootstrap binaries. LLVM too; since you mentioned it and I was curious, here's the dependency graph of LLVM 9.0.1 on my system, in GraphViz and PDF formats:
https://terracrypt.net/upload/llvm.pdf https://terracrypt.net/upload/llvm.dot
(That's from `guix graph -t bag-with-origins llvm@9.0.1` on my laptop.)
It's my understanding that being bootstrappable in this way is a requirement for being included in upstream Guix, so generally everything that's available in Guix can be bootstrapped like this.
Now, what's not done yet is the path from stage0 to building the bootstrap binaries, but that's the eventual goal. The rest of it? It's not futile, it's done. Not all software is in Guix, but enough of it is that I'm typing this from a laptop running almost exclusively software from Guix.
Beyond that, as you can tell from your graph there’s an enormous amount of code that’s part of a build from a large amount of projects. Explode that by a factor of 100000x to get the number of lines of code. So even once you’ve proven the source matches the binary, you are still trusting that the source code is of a trustworthy nature in the first place. You can move the trust required around and in some cases reduce it, but ultimately you’re trusting a lot of people and code (heck you’re trusting the good will of general OSS to validate the source itself isn’t malicious).
Like I said, I’m supportive of the effort and guix/nix are great projects and extremely valuable. There’s no theoretical basis though to back the design of solving the trust issue though (the best we have are reputation systems but even that isn’t backed by any mathematical model).
Not yet, but gcc can be built starting from Mes and a few bootstrap binaries (xz, bash, tar, etc): https://bootstrappable.org/projects/mes.html - and that initial version of gcc is 2.95.3, which does have C++ support.
...and there's work being done towards building Mes with M2-Planet (another C compiler by the same author as stage0): https://www.gnu.org/software/mes/
(Although I think the Guix project has shifted to an approach that starts with Scheme instead these days; they have a Scheme implementation of most of those bootstrap binaries now in the form of Gash and Gash Core Utils: https://guix.gnu.org/en/blog/2020/guix-further-reduces-boots....)
In any case, if you can connect the two, and it feels like that's very close at this point, you've got a bootstrap path from that basic assembler to gcc, and from there to... well, the rest of the distro.
>Beyond that, as you can tell from your graph there’s an enormous amount of code that’s part of a build from a large amount of projects. Explode that by a factor of 100000x to get the number of lines of code. So even once you’ve proven the source matches the binary, you are still trusting that the source code is of a trustworthy nature in the first place. You can move the trust required around and in some cases reduce it, but ultimately you’re trusting a lot of people and code (heck you’re trusting the good will of general OSS to validate the source itself isn’t malicious).
Of course, yes, this is a problem. At least once you're able to bootstrap entirely from source you can be pretty confident that the source code you're looking at is what's in the binaries on disk. But yes, that doesn't solve the problem of having a ton of code to review if you need to review it.
But what's the alternative?
I agree, but also if you don't trust the recipient you're sunk to.
Perhaps the better way to do this is to ask for permission to screenshot the message.
either way, if there is no way to send info about the messages that are "offending" there is no real way to police the spread of it. (assuming that you've done your encryption properly.)
1. What is 'recent' messages? That's a big grey area there. They should specify or it's ripe for abuse.
2. If someone suddenly gets 10 reports of abuse then that's a red flag. I would argue that this would require further investigation and by investigation I mean forcing a disclosure such as 1-1 messages.