> WhatsApp can now read your recent messages when you report a user
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 problem is that you submitted the post with a misleading title. "WhatsApp can now read your recent messages when you report a user" implies that they've acquired some new power to read user data when in reality it's you who are forwarding them a copy, for the obvious reason that reporting a user would be meaningless without that.
> implies that they've acquired some new power to read user data when in reality
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.
It's not ok on HN where clickbait titles and editorialized titles are not ok, 'factually correct' or not. You can't just say we should agree to disagree on whether to have clickbait or editorialized titles.
Whatsapp is the most popular messenger in this world. People need to know this new change in this update. It is end to end encrypted, but now they have started collecting messages, the first way being when you report them. You can't opt out.
You can opt out by not reporting users. You can already block someone for any reason whatsoever. Nothing requires you to report them.
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.
The difference is that a screenshot may be fake. If the intermediary is revealing user private messages, it’s a stronger evidence than just making up a photoshopped screenshot.
I imagine that the API-based uploads of the recent decrypts from the user being reported can also be faked, so I'm not sure that this is a very important distinction.
Assuming whatsapp uses the same message franking mechanism Facebook's encrypted chats use, no. Ciphertexts are authenticated so that the contents of them can be verified using a key held on Facebooks servers (and crucially that key allows you to forge those transcripts, so someone can't use the stolen key to publicly confirm the contents of someone's messages as with DKIM). See https://eprint.iacr.org/2019/016
There is some difference in the skill level required to convincingly craft a fake screenshot versus to spoof an API request, but yeah, it's not a huge difference.
The fact that it's an API request will make it easier to create checks. For example, they could check if the length of the messages match with the length of the encrypted ciphertext the server sent. In theory you can do with this a screenshot already, by redigitizing the content, but it's harder. Or they could check whether the received/sent/etc dates match with what the servers recorded, etc.
> I imagine that the API-based uploads of the recent decrypts from the user being reported can also be faked, so I'm not sure that this is a very important distinction.
That assumes that the decrypted messages aren't signed (e.g. via HMAC), no?
End-to-end MACs don't help because the recipient knows the key and thus can generate a valid MAC on a fake message.
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.
I somehow don't think FB's world class engineers would fall for the cryptographic doom principle, so this would imply MAC-then-Encrypt-then-MAC, no? :D
While there is certainly a MAC using a key shared between sender and receiver using either an integrated authenticated encryption algorithm or encrypt-then-MAC this key will be known to the recipient and is thus useless for proving authenticity to a third party. But facebook could add an additional MAC using a key only known to them over the already authenticated ciphertext.
It can all be faked with a lot of effort, but proving it's an effort beyond F12 is just a refresh. But if you're going to such extremes you wouldn't trust server data/logs at all either, you don't know if they've been manipulated or not. You wouldn't trust anything, so the whole thing itself doesn't matter unless you had them say it directly to you.
Does it mean messages can be read without agreement? Let's imagine "a glitch" where operator sees that user has opt in, but they didn't - can they see messages?
I don't know the implementation on the client, but in theory it can be implemented locally on the client only, and I made the above statements under the assumption that it's how it's implemented. The user issues the report command in the UI and the client takes its local copy and uploads it to the server as part of the report. So it's mainly a convenience feature.
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.
>That would violate the non-repudiation properties of the Signal protocol,...
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.
So is there a way to capture user's screen without user knowing and essentially bypassing the end to end encryption altogether? (the images would be sent to a different endpoint for example)
The report feature is initiated by the user. Only the copy of the user's correspondence who sends the report is sent.
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.
No. WhatsApp does not keep delivered messages, and, by default, messages are end-to-end encrypted and cannot be read by WhatsApp.[1] As shown in the screenshots of the reporting feature in the article, reporting causes your phone to send (forward) the relevant messages from your phone to WhatsApp as part of the report. For reporting a user or business, the relevant messages are "most recent messages" from the user/business. For reporting a group, the relevant messages are "most recent messages" in the group.
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.
No. If Alice reports Bob, the report only includes the most recent messages from Bob to Alice as forwarded from Alice's local copy of their chat. No other messages are made available to WhatsApp. None of Bob's other messages to other people are included, nor could they be since Alice wouldn't have them. In your scenario, if Alice was law enforcement or cooperating with law enforcement, her reporting Bob and then them subpoenaing WhatsApp would only grant them circuitous access to messages from Bob they already had on Alice's device.
> As much as I like E2EE, I don't see where the problem lies?
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.
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).
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.
HT202303 has a list of things that are end-to-end encrypted. iCloud Backup is not in that list. Furthermore, it says:
> 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:
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.
Facebook should definitely make it explicit that by reporting, you share the last N messages with that account with Facebook and make them accessible to Facebook employees/contractors.
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.
> Regarding the iMessage backup thing, I fully agree with you that it's a major problem. But it's a different thing.
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.
The problem isn’t the feature per-se, it’s facebooks track record with user data and a lack of trust. This is explicitly something you would not want Facebook in specific doing because you want to keep them at a further distance
So it is not only Facebook that has complete access to the message history, but also Google.
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?
I don't know if it is included in your Google takeout.
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
Seems like the messages were e2ee, and when they got to the last e they were decrypted and then immediately uploaded to a third party because yay cloud.
Federation is no panacea either, it's also a privacy tradeoff, since the communication metadata is distributed across multiple servers operated by different people (unless you only communicate with people on the same homeserver that hosts your own account).
There is no "official" way for you to download it.
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).
I tried it, but I can't seem to get it to work. Possibly because I don't know the "device ID" of my Android phone since I lost it.
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.
There are 3rd party products who convert WA data from iOS to Android and vice versa (and also, you might be able to get your data using a new android device or even android installed in a VM).
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")
Thanks for pointing this out. I suspect this why Google agreed to store all the backup data of a competing company for free. Google would have had no interest in storing Facebook's end-to-end encrypted data for free unless it could read it and possibly resell it back to Facebook.
It is a bold claim, indeed. What about WhatsApp Web though? I wonder how that works. I guess it connects to the device via a 3rd party (Facebook's) to send the data over HTTPS? Does it use public-key authentication where the key is only known to the WhatsApp Web client? Either way, it is a compromise on E2EE.
I suggest you read the guidelines for this website [1]
> 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.
>then it is still a compromise of E2EE. E2EE is between two devices, a receiver and a sender.
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.
I hate Facebook and WhatsApp as much as anyone else who cares about privacy.
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 nothing wrong with it. I'm posting it because it's a new thing in Whatsapp, the worlds most popular messenger, and I wanted people to know of this change.
Your wording choice for the title makes it seem otherwise. It makes it sound like it's some big warning or big deal. Perhaps choose your words more carefully?
It’s a good thing you edited your original suggestion:
> “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.
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.
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.
There is nothing factually wrong with the current title. Nonetheless, it is misleading.
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.
Then block them. When is reporting necessary?
When someone calls your mobile and harasses you, you block their number. If it's criminal harassment that won't end, you call the police.
Who needs reporting for directessages, this is just odd.
Perhaps, I use WhatsApp daily and was never harrased, spammed or sent child porn.
Although, I still don't understand why a block wouldn't suffice.
If the same user is harrasing you, and you block it then problem solved. If it's a more sophisticated harrasment where users change, then reporting one of them won't do anything better than blocking.
If it's someone spamming random numbers, a simple algorithm can raise a flag without any report necessary.
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.
> Although, I still don't understand why a block wouldn't suffice. If the same user is harrasing you, and you block it then problem solved. If it's a more sophisticated harrasment where users change, then reporting one of them won't do anything better than blocking.
They can block the device.
> 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.
While I share your general suspicion I don't think they need to see the messages to get a lot of privacy-violating use out of WhatsApp.
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.
Maybe true, however computing power has increased substantially since then. It's quite easy for them to index all the messages and search for them later, or setup alerts on key words.
Metadata is more useful than data in the sense that data may be “encrypted” using a different unknown scheme between every two users (e.g. a hitman may discuss “a job”, a bribe might be described as “a gift”, a non public stock tip might be “weather is going to be good tomorrow”).
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.
You send them the messages, by opt-in, your version seems to suggest something else. Simplest thing is to just stick to the guidelines and use the original title, then add the thing you want to highlight in a comment. The other way ends up taking a non-clickbait title and making it clickbait.
You're now quibbling over my characterization of your characterization of the clickbaity title, which is fun but not really the point. The point is 'don't editorialize/rewrite titles into clickbait, please'.
That's what most people don't seem to get with E2EE: The messages are still readable to the software, so with a simple software update they can be trivially extracted. E2EE doesn't provide so much benefit if you don't also control the client software.
People think end to end encryption is a magic cure for OpSec. It’s 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...
It's impossible to prevent Bob from publishing all Alice's messages (barring tech that can forcibly erase them from Bob's brain).
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).
E2EE is for communicating with a trusted person without third parties listening in through technological means. Anything else is out of scope. This includes what you mention here, where the person you're communicating with isn't actually trusted.
It's pretty hard to imagine a circumstance in which I would be reporting a WhatsApp user. This isn't like a public forum. These are one-on-one conversations or group chats with people who were specifically invited. If someone was a problem, I would just block them. Why would you ever report someone? I haven't ever heard of this happening.
Imagine someone trampling kittens and sending the result to random strangers. Sure, you can ignore them... but the kittens would still keep dying. So you report it and hope for the best.
Now change "trampling kittens" for any kinds of unwanted messages.
Maybe this is the time that people understand that even perfect E2E-encryption doesn't mean anything if you cannot either somehow trust (for some level of trust) the entity who produces the endpoint - or perfectly control your endpoints at a network protocol level.
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.
Remember how whatsapp for years didn't let you delete sent messages even if the other person hadn't yet received it? I assume there was some major privacy reason why it worked that way for so long because it was obviously pretty horrible from a user experience standpoint.
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).
With (popular) messaging apps now subject to draconian measures to introduce a backdoor, I am now skeptical of these messenger apps, since all an intel agency has to do is push a backdoored binary down the wire to a device, and the user is (usually) unaware that their messages are tapped by the agency. Even with reverse engineering of the app, it could be difficult to determine if it's compromised or no longer 'privacy aware'.
Although this feature probably isn't a big concern, I am curious because you can't report without sending "recent" messages to WhatsApp, and "recent" is vague enough to mean "previous 500" or so. Again, probably not an issue since you presumably don't have much message history with someone you are reporting, but a bit of a strange decision from a privacy perspective.
There have been several unofficial reports of Facebook unifying the backend messaging among Instagram, WhatsApp and FB Messenger. If and when that happens, E2EE on WhatsApp will finally be completely gone.
Anyone knows how far along (or canceled) that plan is?
Given that Jan Koum and Brian Acton both left a few hundred million USD on the table, and the reason was supposedly "changes to whatsapp that FB promised they wouldn't do", I would assume it is going to become perfectly wiretappable.
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 had a notification on Instagram the other day explaining that, for now on, all messages can be read if reported. Instagram never claimed to have e2ee, but it shows they are aligning the policies across the 3 apps.
This seems mostly fine. I'd prefer to see it as a box you have to affirmatively check (such that you can still report someone without opting in to sending the messages). But... I can't really get riled up about this.
It's also been clear to me for a while that Whatsapp is scanning message content & meta-data for use in FB ads. Talk about something in a Whatsapp chat and pretty soon an ad in FB about the thing shows up.
E2E encryption in closed source automatically updated programs doesn't provide any real assurance: whoever makes the program can subvert your privacy at any time.
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.
Are you verifying that all your OSS binaries you’re running match a reproducible build hash that’s been validated by multiple trusted sources? If not, you’re already engaging in a level of trust.
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].
Not GP, but: although I'm not currently doing this consistently (I don't have the resources to set up build servers and there aren't many build servers for my distro yet) the distro I use does make it pretty straightforward to do this: https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
If I want to do this for any particular package as a one-off, it's two commands.
Reproducible builds are a step up but remember that it requires you to build with the exact same binary-identical toolchain. If that’s already compromised your guix challenge isn’t really doing anything of value.
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.
I mean, sure, we're not there yet. If the Guix folks are able to get a bootstrap path going all the way from something like stage0, though, we'll be in a pretty good place I think: http://bootstrappable.org/projects/mes.html
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.
Never said anyone should give up but my point is that to my knowledge there's no actual proof of how to solve this. We're just stumbling in the dark trying ideas.
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 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.
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...)
Are you referring to https://github.com/oriansj/stage0? This stage0 gets you a basic C compiler. An impressive achievement for sure. I don’t see how it really solves anything though.
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.
>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.
...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:
(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.
I’m saying stage0 is a massive incomplete lift. If you notice that Rust chain starts at g++ - can g++ be built from the basic assembler you listed?
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).
>I’m saying stage0 is a massive incomplete lift. If you notice that Rust chain starts at g++ - can g++ be built from the basic assembler you listed?
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.
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.)
According to the article, recent messages will be sent to whatsapp on reporting contacts or groups just like we sent messages to other users. There is no mention of E2E encryption implemented by whatsapp and its loopholes.
To achieve truly E2E encryption one must assume the channel they communicate with is not secure and then perform encryption themselves. For example you can exchange keys offline and then send messages encrypted with PGP between each other. You could also convert encrypted messages to text, so that it is less obvious it is encrypted.
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.
So it can also read the messages of the reported user? Without their permission, other than what is covered in fine print? I understand this can be used to fight abuse but it seems to open up some hard questions for WhatsApp privacy.
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.