Building end-to-end security for Messenger
engineering.fb.com
engineering.fb.com
Messaging: https://engineering.fb.com/wp-content/uploads/2023/12/Messen...
Labyrinth E2EE storage: https://engineering.fb.com/wp-content/uploads/2023/12/TheLab...
---
Comments by:
Jon Millican https://twitter.com/JonMillican/status/1732582565884702982
Matt Green https://twitter.com/matthew_d_green/status/17325670516070893...
Alec Muffet https://alecmuffett.com/article/108588
... “
Okay, can someone give a good guess as to what's the real reason to do this? Not like all the feel-good BS - what's the business case? How is this gunna make them money?
It seems this just makes them lose access to a ton of data to mine for advertisement. I chat with a friend on IG about something and I immediately get ads for it. It's a bit creepy, but I feel it's working the way they'd want it to (never bring up watches, you will get watch ads for the next 6 months)
Are they bleeding a lot of user to Signal/Telegram b/c they lack encryption? (my impression is only nerds care about encryption)
Are they getting harassed by requests from law enforcement?
Are they in hot water b/c of child porn?
Do they need plausible deniability?
I don't really get why they're rolling this out. Like what's their angle. Seems like something users don't care too much about and they lose a ton of valuable data
Also: https://techcrunch.com/2023/07/11/teen-and-mom-plead-guilty-...
They must be able to do good targeted advertising without message contents, with public likes and other data on scrolling behavior, especially as AI tools improve. Maybe having this data is more trouble than it's worth. Data is a liability as well as an asset.
I worked for FB briefly. It was enough to convince me that the "it's the right thing to do" is definitely not relevant to this question.
- I don't really see it making sense as a PR move to build trust. I think outside of the tech sector they are doing fine on that front. The vast majority of people use their Bytedance, Meta, Tencent, etc. apps and aren't considering their encryptedness.
- I don't think this announcement will get any substantial press coverage
- It could be preemptive so that they don't get bad PR when they end up being "complicit" in getting people sent to jail for abortions (in the US) or being gay (in some African countries) or whatever
Exactly this. With the recent laws passed they see how their altruistic "save the children" partnerships with law enforcement could be twisted for causes that aren't as popular everywhere.
Also it cost money to serve all those warrants.
If that is true, good. But it'll take a very many doing "the right thing"s before I would trust anything Zuck owned.
1. More and more people care about this, eg journalists, politicians, etc. Apple has been talking about this a lot, although some being propaganda for messages, but their customers are already somewhat aware of private messenging.
2. It may not degrade ad targeting that much. I imagine doomscrolling does it way more: you engaged with this post, you ignored that one, and so on.
But at the end of the day, their ultimate end is to make more money. If they do the right thing it isn't out of some altruistic motive. It's because they think that by doing so will make them more money.
[Redacted Friend's Name]: What? How'd you manage that one?
Zuck: People just submitted it.
Zuck: I don't know why.
Zuck: They "trust me"
Zuck: Dumb fucks.
https://www.esquire.com/uk/latest-news/a19490586/mark-zucker...
He was saying “I could be anyone” not “I can’t be trusted.”
With Zuckerberg's and FB's track record, their business decisions ought not to be trusted.
This is the most autistic thing I have read on the internet this year, second to a personal friend sperging out thinking he was going to wife up the first girl he met at a party.
https://www.eff.org/de/deeplinks/2022/04/eu-digital-markets-...
How would you refute that? Trust users to check that some code is the same on both devices? What would prevent a bad actor from MITMing the whole thing from the start?
That stuff is very hard to get right within a single app.
Now do it across mutually-antagonistic companies with incentives to not cooperate.
The E2EE only means the message is not readable "in transit" (as in after it leaves a Facebook client)
However it does make it a bit more difficult for them to spy on a conversation, which is arguably a good thing.
e2e isn't a tech issue, it's a trust issue. Do you* trust FB?
* You in general.
As opposed to the prior step, "0. Analysis During Composition", in which the Messenger client is doing all the metadata analysis/collection while you are typing, and already knows all the tags its going to assign to you for Meta, before the message is encrypted.
Sure, third parties won't be able to see your message. But you did give Meta permission to analyse your content prior to posting.
This anti-pattern is all over Meta's products. You can see it in use when you type an update in Facebook using a browser - just try to leave your comment un-posted, or close the page, etc. Every single keystroke prompts Meta's analysis - which is completed when you press "Post" (prior to encryption/transfer ..)
So this is some slick positioning on the part of Meta's technical PR managers ..
I believe this is the future in a GDPR world. The server sends a list to the client of 1000 ads, and the client decides which to show based on all the data available locally and a big local neural network model to decide which you're most likely to click.
"...when a Brave Ad is matched to you, it is done on your own device, by your own device, inside Brave itself. Your personal data never leaves your own device."
The mechanism is very similar to what you describe.
[0] https://support.brave.com/hc/en-us/articles/360026361072-Bra...
E2EE is great but does not help at all if you don't want Facebook to read your messages and profile you based on their content / who you talk to etc.
If the client just leaks the plaintext or leaks any information about the plaintext that encryption is supposed to protect then the encryption scheme cannot be described as "end to end".
Answer - Message content wasn’t used for advertising. I believe it had been tried at some point and found to be sort of useless. But people like you won’t believe that, so end to end encryption might help build trust and increase engagement.
Personally I doubt that any more than low single digit percentages of people care at all about E2EE. Even me, as a tech person, I don't care about it, and I actively avoid Signal because of the inconveniences that E2EE causes.
This has been a very big effort to implement, and FB no longer deploys those kinds of resources on vague whims. I think most likely something to do with regulations, and not wanting to be on the hook for user message content, but it's just wild guessing really.
Secondly, please educate yourself about what the government actually thinks about the ad business you’ve described as “shady”. Even if it was “shady” to show ads based on preferences and never reveal or sell those preferences to a third party … the elected representatives in government really like having social media ads as an option in elections.
Here, read this so you can learn how government actually influences social media to do their bidding - https://knightcolumbia.org/blog/jawboned
> The senator’s office told Katie that they really wanted to ban that practice but knew they would never get it through the Senate since so many campaigns relied on the tools for their elections. So instead, they said they were going to pressure tech companies like ours to ban the use of the tool in the hopes that if one of us did so, the others would as well. Although we did not stop using Custom Audiences entirely, Facebook and other platforms did dramatically reduce the targeting options for political advertisers.
(EU)
Considering it was Meta’s policy to scan even when not mandated, it seems like an internal shift in attitude.
[1] https://fortune.com/europe/2023/10/26/eu-chat-control-csam-e...
I'm one of them and I don't like this.
The argument being that some assurances typically associated with E2EE (that "even we can't see what you're doing") are shakier without a disinterested third party serving the application to the user. If you have some target user `Mr. X`, and you operate the distribution of your app `Y`, you could theoretically serve them a malicious app that sidesteps E2EE. And since it's just a web app: the blast radius is much smaller than if you were to go through the whole update process with Google or Apple and have it distributed to all users.
Most people I know using FB messenger do so on desktop via facebook.com and the app on mobile. I don't see them removing the former any time soon but if the web only version still exists for mobile users perhaps that will go.
> “Okay, well, WhatsApp — we have this very strong commitment to encryption. So if we’re going to interop, then we’re either going to make the others encrypted, or we’re going to have to decrypt WhatsApp.” And it’s like, “Alright, we’re not going to decrypt WhatsApp, so we’re going to go down the path of encrypting everything else,” which we’re making good progress on. But that basically has just meant completely rewriting Messenger and Instagram direct from scratch.
1: https://www.theverge.com/23889057/mark-zuckerberg-meta-ai-el...
So they could still be sending their server data like ‘likes watches’ without technically breaking the encryption.
A kind of fatigue is setting in when it comes to Fb messenger and Instagram. They have already bloated these apps and they can’t really add any other gimmicks. So they are trying the “other” gimmick now.
My take is or guess is - they are doing it because they really have nothing else to do.
It's about them not losing customers to the competition that does offer E2EE
It's a PR move to _say_ they did it.
Nearly 1/4 of women have done abortion in their lifetime. And there are also co conspirators like husbands, Uber drivers, nurses and doctors.
I have no side to take in this discussion, but just wanted to point out that the USA is not the only country that exists. I know it sometimes seems that way on Hacker News, but I promise you that there is a big wide world out there that has nothing to do with the Supreme Court :)
However, metadata is still un-encrypted, same as on whatsapp. Meta knows who you talk to, and when - this is juicy enough for both ad-targeting, and government surveillance.
Metadata is still data!
Let's imagine a situation where all the messages from Meta's platforms are leaked. On other scenario message content is plaintext, but senders, receivers, timestamps and locations are encrypted (on top of app usage behaviour).
On the other scenario, all the contents are encrypted, but the metadata is public.
We would know to whom everyone, in anytime, in any location, in which interval has talked to.
Which is more dangerous or damaging?
I’ll start first off the top of my head:
- The (real) identity of you and every person you talk to
- The time of the messages
- The location they were sent from
- The specific device used to send them
- A sentiment analysis: were the messages positive? Negative? Depressed? Anxious? Sarcastic?
- A description of the pictures that were sent (for example by an on-device AI model)
- A transcript of any voice memos/videos
Read receipts.
User is typing indicators.
And if you’re sending media they have on record that means they can look up the exact same media and still have it qualified as metadata
According to their paper, they are doing client fan-out:
"Messenger uses this "client-fanout" approach for transmitting messages to multiple devices, where the Messenger client transmits a single message `N` number of times to `N` number of different devices. Each message is individually encrypted using the established pairwise encryption session with each device."
This means, the system is only as secure as its client registration protocol. They don't write a lot about it:
"At registration time, a Messenger client transmits its public Identity Key, public Signed Pre Key (with its signature), and a batch of public One-Time Pre Keys to the server. The Messenger server stores these public keys associated with the user's device specific identifier. This facilitates offline session establishment between two devices when one device is offline."
If I interpret this correctly, the server can, at any time it desires, silently add new clients. Those devices will receive all messages directed at that user, and will be able to decrypt it.
I guess that's in line with their bla-bla about setting user expectations:
"Our focus is on determining the appropriate boundaries, ensuring that we remain true to our commitments, setting the correct user expectations, and avoiding creating meaningful privacy risks, while still ensuring that the product retains its usefulness to our users."
Don't forget, their commitments are making profit and exploiting user data.
I remember Telegrams founder saying they don't use E2EE because you can't store messages with full E2EE, which obviously BS because matrix does it, and now Facebook too.
Now they say there is no "elegant" solution. https://telegram.org/faq#q-why-not-just-make-all-chats-39sec...
The fact that they go to such lengths to convince us that they are doing a favor with their insecure-by-default approach has always rubbed me the wrong way.
It's perfectly legit to store end-to-end encrypted data in its encrypted form and then secure the key material in some manner not visible to the cloud service provider. The Telegram folks have tried their darndest to convince us that this isn't really an option, and so therefore they must go insecure-by-default, even though they also pitch themselves as a bastion of secure messaging.
It's always rubbed me the wrong way, since their claims are so obviously false. Which makes me assume they either don't know their domain well enough to be trusted to do any end-to-end encryption properly, or they have some hidden agenda. Neither of those make me want to treat any part of the Telegram chat experience as secure.
Encrypting metadata is also really hard. See the Matrix (and XMPP) community for detailed discussions on why that is.
I use and advise others to use E2EE encrypting tools, all are open source, audited and popular.
Fake sense of safety is worse than understood unsafety.
I see there's some effort here on history sharing. Does that effort allow recovery of a chat history after an unrecoverable death of a primary phone? That's (honestly) the only usability thing I care about when it comes to E2EE.
But there is a trick to prevent brute forcing of a weak and easy to remember password like your four digit phone unlock PIN. The trick is to have a secure element chip in the datacenter, with storage encrypted by a private key that can't be extracted from the chip. The chip stores an encryption key that unlocks your backup, but it can't be extracted from the chip unless you present it with the right weak password. The chip's firmware rate limits and caps the number of attempts to unlock the backup, and if too many attempts are made it ultimately erases the key and your backup is permanently lost. So you're protected against brute forcing even with a weak four digit unlock code. If you know the unlock code from your old phone and enter it into your new phone, the secure element validates it and releases the key so you can restore the backup.
Obviously you have to trust the manufacturer of the secure element for this to work, but it's probably a good compromise for most users because losing your backups when your phone dies is quite bad. I know Google's Android backup uses this method and I believe iCloud does as well. It seems like Messenger supports this too but you have to choose your own PIN because Messenger doesn't have access to your main phone unlock code.
I might screenshot some important messages, but that's about it.
Ah yes, a HSM. Thus transferring the foundational "trust me bro" from Apple to someone like Thales Group.
Let's hope the HSM supports secret backup well enough to protect against server failure, and yet not so well as to allow the unlock attempt limiter to be bypassed.
Secrets backup for HSMs from a certain vendor—that you may or may not have named in your comment—I've worked with is actually the easy part. You just make copies of it and all the key data and check it into a git repo, because all of that data is protected by an HSM secret. Distributing that HSM secret among several HSMs for redundancy is also pretty easy.
The hard part is all the administration around it, specifically around custody of the smart cards that contain chunks of the HSM secret: where are they protected, where are the backups of the cards, who has access to them, coordinating sufficient card custodians to meet quorum, etc. You need to meet quorum to provision HSMs with the same secret.
The real "trust me" part of this is arguably less that the vendor backdoored the HSMs, and more that Apple pays the vendor support contracts (that hardware eventually fails) and maintains the knowledge continuity for the teams responsible for administering these HSMs as people join or leave those teams over time.
For what it's worth, this is pretty much why you don't see HSMs used often at less mature companies.
To be fair I haven't done any disaster recovery yet, so it might not work that well...
Source: https://support.signal.org/hc/en-us/articles/360007059752-Ba...
I also stumbled over that; only the link from the other whitepaper is broken, the one on the parent page works.
Ultimately, WordPress is as secure as any other piece of software, but the ecosystem is so large and varied that there’s a low bar for many add-on plugins. A lot of enterprises build their own plugins for that reason, rather than using the full power of the ecosystem.
(Disclaimer: I’m also a member of the WordPress security team, but not speaking on behalf of them.)
If by "cost" you mean Meta being in the business of siphoning user behaviour, Meta controls the E in E2E a.k.a the apps, so it's a matter of trusting them to not do covert on-device analysis + result exfiltration.
Many cybersecurity engineers passionate about this stuff have worked for Meta. They, too, would have blown the whistle at some point.
Not saying they do it, again it's about trust in the context of:
- Meta (the company, not the employees) having a bad track record
- Meta's business model being what it is (building profiles and selling tooling around that), creating tension with privacy matters
Plus, it's going to help with fighting bills like the Online Safety Bill and Chat Control when huge corporations join us; so bottom line: great news!
Certainly not good for their user base, as (as many pointed out) it's not safe if the clients are all closed source. This promotes a false sense of security, which is worse than an understood lack of security.
They already have an end-to-end encrypted messaging application: it's called WhatsApp. I have seen so many people (and have myself been) bitten by WhatsApp's E2E implementation: messages lost because your phone was barely online and you "read" the message but didn't fully receive it, leaving you to awkwardly ask people to re-send things. Plus the constant need to backup your messages because if you don't you can lose access to them forever. Plenty of my family have lost messages/images that were sent to them and were important to them.
I'd rather not deal with this. Sometimes I want all my messages to be stored on a big company's servers. They should at least give people the option to choose.
> Messenger has always allowed clients to operate off of a small stored local cache, relying on a server-side database for their message history. Neither WhatsApp nor Secret Conversations operated in this manner, and we didn’t want all users to have to rely on a device-side storage system. Instead, we designed an entirely new encrypted storage system called Labyrinth, with ciphertexts uploaded to our servers and loaded on-demand by clients, while operating in a multi-device manner and supporting key rotation when clients are removed.
[0] There was this chip bag from a major chip manufacturer and it proudly claimed the bag was plastic free (might even have been compostable), but it was the thinnest, loudest, crinkliest bag you’d ever heard. It seemed like the chip manufacturer board meeting went like this: “The people want us to cut out plastic! For the environment or something. Don’t they know how much easier and more profitable plastic bags are?? You know what? If they want plastic-free we’ll give them plastic-free... We’ll make them regret even asking...”
That bag didn’t last long before it vanished never to be seen again.
Also, many biodegradable plastics are more brittle than more common plastics. They only way to keep the bag flexible in that case is to make it thinner.
The first line of the article suggests that it's an option
Messenger does. You can have a normal chat and a private, end-to-end encrypted chat at the same time with the same person, both completely separate.
I wonder what changed. Maybe testing showed that people actually prefer them to be separate?
Let's consider you have Instagram users on one-side, and Facebook users on one-side.
As long as you have at least one contact using only Facebook (like your parents), then you have to be active on both platforms in order to talk to your contacts.
If the two platforms would be unified, then you would be active only on Instagram for example.
Will Messenger eventually use IETF MLS?
Edit: nvm just read the last paragraph of the post
How do you think Signal notifications work?
I looked at the whitepaper and they didn't even mention it.
The reason e2e encryption got enabled is to make people feel safe.
I was always very impressed by this-- every service that sends emails should support this. Even banks don't!
If they can set the PGP key they can also change the email. If the account recovery team allows access to recently removed emails as part of the recovery process then it should also allow contacting those addresses without a recently added PGP key.
Logically adding a PGP key is equivalent to changing the email, the previous person can't access the messages anymore. If the recovery process handles these cases differently it is a flaw in the process.
E2E messaging is a better product. Offering it free (at a loss) makes it hard to beat.
What's more, some major govts may be prompted to ban E2E, so they keep their data and kill Signal and others, while they are the 'good guys'.
FB can probably create a 99% accurate ad profile on you with just metadata, likes and tracking you on the web. If not they can push local profiling models on your phone.
With all that said, I still think it is a genuinely good thing for humanity as it is now, and I am cautiously optimistic.
Even if they don’t have the key, they don’t even care about messages itself anymore 1. It’s risky business, regulations might hit you hard 2. Metadata is good enough for them 3. They own the client, so they know how to extract more than useful data in the end.
E2EE is important marketing trick nowadays, most users see it as if this makes them completely anonymous to companies like Meta. After all ads are their only source of generating money. They will do whatever it takes to satisfy advertisers, not the users.
That doesn't prevent a malicious update from coming around and just sending the entire database wherever, but nothing stops that from say, Element, if you're not actively vetting the updates. The best you can really do is hope that nobody compromises it (or that if somebody does, it gets caught as early as possible). Thankfully it seems like outright compromises to this degree are rare (as far as we know) whether the software is open source are closed source.
Basically imo it's a mixed bag. I don't see any obvious way to push the status quo vastly far forward because there's no way to really prove, especially to non-technical users who aren't cryptographers and programmers, that the software is 1. secure 2. doing what it says.
The gold standard is and probably always will be analyzing the binary itself, with disassemblers, debuggers, etc.
You can argue then lets just use open source. Ok but is it that much of a security guarantee? Open source products are of limited functionality. It is great for web servers and frameworks, stuff developers care about. When it comes to feature rich client applications the track record is not nearly as good. Also who is going to pay the server costs?
A passing grade is a block of garbled encrypted mess for which they have no unlock key.
Why is that a problem for cheap phones?
Hell, on Amazon right now I can find a brand new 99 Euro 'Chinese Brand' Android phone with 128GB of storage and 8GB of RAM. Granted, I wouldn't recommend anyone actually go and buy that one, but it shows even if you're tight on cash and need a phone with lots of storage you can get it even on rock bottom prices.
Only Apple is the one left who shortchanges you in 2023 wiht 64GB base storage even at +500 Euro phones, but that's an Apple-only problem, not a smartphone problem.
Still, I'd much rather pay a bit extra for more storage on a phone to keep my encrypted messages locally than in the cloud of some shady app like Telegram that's "FREE" and yet needs to finance it's massive cloud bills somehow.
That end-to-end security also didn't rely on Facebook.
Not sure how this could work nowadays, I have closed my facebook profile many years ago.
In a world of continuous data breaches, exfiltrations, malicious Three-Letter Agencies, incompetent and decades-behind-the-curve legislators, trust is a paramount factor. Trust that a given communication system's first allegiance is to the interlocutors(A), trust that my data won't be subjected to surveillance capitalism, trust that it won't be stripped mined for reflecting advertising right back at me for useless shit I don't want, trust that I can speak my mind without needing to continuously look over my shoulder with one eye pealed for powercenter goons sicked on me by partisan logic.
If you want me to trust your system, show me the complete source code, show me the disinterested third-party security reviews, show me what can happen at the ends, show me that it's not compromised by secrecy laws, along the full chain of custody.
A problem for our age, one step at a time ..
A) See? Even this assumption is a cardinal mistake!
Edit: Trust, but verify. Trust needs to be earned.
I think this is a bit extreme and not really plausible for something like messenger at its scale.
Sounds like you set yourself up to never trust anything.
I mean, do you fly on airplanes without having inspected the flight code? Or do you put your money in a bank without having inspected the accounting code?
I don't need to see the code for it to fail my audit though:
- Phone number attached to real identity is required
- Metadata is not e2e
- Contact list is not e2e
I finally took off my pink-tinted glasses when I noticed they restored old deleted messages once they released the new Messenger, the one we have today which replaced old facebook chat feature.
Probably it was for my "convenience" but what I know /s.
Don't forget the authorities in the mass surveillance industry.
If any mobile phone that logs in can query and read the history, why cannot the server? What's the trick?
Asides from iMessage, they pretty much have most of this working for WhatsApp from the perspective of the user. The challenges they've mentioned seem like they've mostly been solved in WhatsApp? I could be totally naive here though.
Impressive theater though.
That approach puts a lot of trust in the HSM vendor, though.
One specific area where I'd love to see more focus and attention is the web as a platform for E2EE applications. Currently, because of the inherent problems related to application delivery and trust relationships on the web, every step forward in E2EE adoption is a step away from webapps being first-class citizens -- even as PWAs keep becoming more viable for a wider range of use-cases otherwise. Even though an increasing number of companies maintain web implementations of their E2EE apps, these are always the fallback option when nothing "better" is available; the tech to make E2EE secure in webapps doesn't exist yet, but companies also have a unrelated incentives to push users to native apps. There are no serious efforts to remedy the situation and develop tech that would make it possible to deliver secure E2EE through the web.
The post mentions a couple of relevant goals:
> 3. Control over endpoints
> 8. Third-party scrutiny
They also mention the Code Verify extension[1], which may seem like a solution, but does not stand up to scrutiny: It only notifies the user of unexpected changes in the app, but does not prevent them. The detection logic it implements also seems trivially bypassable, and in more ways than one. Even if it was sufficiently enforcing application integrity, an extension like Code Verify is unlikely to ever become widely-adopted enough to make a dent. And of course it's not even available in all browsers on all host platforms.
There are also other similar extensions that suffer from similar shortcomings.
Browser vendors could solve the problem by providing APIs that allow the kind of integrity enforcement needed, akin to SRI[2], but that would mean you first have to agree on a standard and then implement it consistently everywhere and then webapps could slowly start adopting it. And because of past failures like HPKP[3], browser vendors would probably be hesitant to even start considering anything like it.
I believe a solution is possible using only the currently available web APIs, however, and for the past few months I've been prototyping something that's now at a stage where I can call it functional. The general idea is that using service worker APIs and a little bit of cryptography, a server and a client application can mutually agree to harden the application instance in a way that the server can no longer push new updates to it. After that, the client application can be inspected manually with no risk of it changing unannounced, and new versions of the app can be delivered in a controlled way. While my prototype is nowhere near production-grade at this point, it's nearing a stage where I'll be able to publish it for public scrutiny and fully validate the concept. Until then I'll be implementing tests and examples, documenting the API and threat model, and smoothing out the rough parts of the code.
If anyone's interested in collaborating on this or just hearing more details, feel free to reach out. I'd love some early feedback before going fully public.
[1] https://engineering.fb.com/2022/03/10/security/code-verify/
[2] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
My ideal solution to this problem would be Web Bundles[1] signed by the server's TLS key[2], combined with Binary Transparency[3] to make targeted attacks impossible to hide (and maybe independent Static Analysis[4] to make attacks impossible to carry out in the first place), but work on many of those standards seems to have died out in the last few years.
[1]: https://wpack-wg.github.io/bundled-responses/draft-ietf-wpac...
[2]: https://datatracker.ietf.org/doc/html/draft-yasskin-http-ori...
[3]: https://datatracker.ietf.org/doc/html/draft-yasskin-http-ori...
[4]: https://datatracker.ietf.org/doc/html/draft-yasskin-http-ori...
The way it works is the server returns a unique service worker script every time, and the script file itself contains an AES key. The user trusts the server not to store this key and the server never sees it again. This AES key is then used to encrypt all persisted local state and sign all cached source files. If the server replaces the service worker, the key is lost and local state cannot be accessed. If the server somehow replaces a source file, its integrity check will fail and the webapp will refuse to load it. If the server manages to skip the service worker and serve a malicious file directly (e.g. because the user did Shift+F5), the malicious file won't have access to any local state because the service worker will refuse to give it access. The server can destroy all local state and then serve a malicious application, but the user will immediately notice, hopefully before interacting with the app, because suddenly all their data is gone.
Signed web bundles with binary transparency and independent review would be far superior, if they actually existed. (Which sadly, they don't right now.)
Was source code released? Can I build Facebook messenger with private cicd running on my own silicon? If not, there is no encryption worth a damn. You have to be very very stupid to believe otherwise.
What Facebook is doing here is deploying a massive honeypot.
> 2. Nobody (not even Meta) should be able to forge messages to appear to have been sent from someone they weren’t.
From a business perspective, it makes perfect sense. Users want security and Meta don't want to be responsible for the data communicated.
One question I have is how Meta will comply with UK law on E2E [1]:
> Meta has been a leading industry player in the fight to tackle child sexual abuse. For over a decade, Meta has utilised hash matching technologies to enable it to detect child sexual abuse material being shared on its platforms. This has made it one of the leaders in detecting and reporting online child sexual abuse, providing law enforcement with leads to safeguard children and arrest child sex offenders.
> However, Meta and other companies are now planning to implement E2EE, without similar technologies in place, across their messaging platforms such as Facebook Messenger and Instagram Direct Messages. The roll out of E2EE is likely to happen later this year. The National Center for Missing and Exploited Children (NCMEC) estimate up to 70% of Meta referrals could be lost following the roll-out of end-to-end encryption.
Firstly, I would like to know what the UK government does with all of these referrals. Given the current state of UK policing, I predict it's almost nothing. Local government was itself complicit in child exploitation [2].
It appears this E2E implementation may have some form of backdoor anyway [1]:
> The Safety Tech Challenge Fund is a UK government funded challenge programme that first ran from 2021 to 2022. The fund was designed to support the development of proof-of-concept tools to detect child sexual abuse material across E2EE environments, whilst upholding user privacy. The fund demonstrated that it would be technically feasible.
> It is recognised though that each and every online social media platform and service is different, and therefore solutions will need to be tailored. Therefore, companies such as Meta should utilise their vast expertise and engineering resources and build on the outputs of this fund and develop solutions for their individual platforms/services.
> In addition, some of the UK’s leading cryptographers have written an academic paper outlining a variety of techniques that could be used as part of any potential solution in E2EE to provide both user privacy and security, while protecting child safety and enabling law enforcement action.
"The fund demonstrated that it would be technically feasible" - you can't leak information from a message without leaking information. The same method used to detect harmful content could also reveal information about the messages. For example, if an E2E message was delivered with hashes of images inside the message, it could also be used to detect political decent memes.
[1] https://www.gov.uk/government/publications/end-to-end-encryp...
[2] https://en.wikipedia.org/wiki/Rotherham_child_sexual_exploit...
Give us an app where everything, including metadata, is end-to-end encrypted and works at "web scale". No one other than the people in the conversation can know who is talking to who and when. Then figure out a way to pay the bills to run the infrastructure and pay the people working on the app and also make a profit. (A novel idea: Maybe charge people to use the app?)
If I could raise enough money to replace my dayjob, I would totally do this. I'm guessing it's not doable, but I put together a quick Google Form to gauge interest. If anyone would be interested, please submit the form[1]
[1] https://docs.google.com/forms/d/e/1FAIpQLSe1sl5MI1Mxna6RBTXB...
> Maybe charge people to use the app?
Who will pay for a service that's offered for free by at least 3 major messaging apps?
* there’s lots of free competition, including Signal, which is free and decent.
* you’d probably need to open source it if you want to convince anyone it was trustworthy
* what if you want to message somebody that doesn’t want to pay?
Of course maybe a huge company could work this out… but it seems fundamentally very hard
Any sort of project that actively tries to minimize data collection will not be profitable. At least not in this current economic system. They will have to be non-profit (Signal, etc), or run by volunteers (Cwtch, Briar).
If the network or server has no idea where to deliver an encrypted message, then the only way to guarantee delivery is to send all the messages to all the users to unpack to see which ones are relevant to them, which fails "web scale"
The Briar way of doing things actually solves an important E2EE usability issue. Since the cryptographic identity is the only identity, it is much harder for the user to end up using the system without a verified identity.
>No one other than the people in the conversation can know who is talking to who and when.
This also means the infrastructure cannot block messages. Or tell the difference between spam and legit messages. Effectively you can DDoS a client with messages.
Not necessarily. Eg as a simple model, assume that you 'send' a message by publishing it to something like a usenet group (and perhaps that group charges you a fraction of a cent for doing so).
There's no denial-of-service for a client that receives a lot of messages, distributed or otherwise, but still outsider don't see who is sending what to whom.
SMTP is an example of this succeeding, as problematic as that protocol is.
https://en.wikipedia.org/wiki/Veilid
> Veilid is an open-source, peer-to-peer, mobile-first, networked application framework.
> The framework is conceptually similar to IPFS and Tor, but faster and designed from the ground-up to provide all services over a privately routed network.
> The framework enables development of fully-distributed applications without a 'blockchain' or a 'transactional layer' at their base.
> The framework can be included as part of user-facing applications or run as a 'headless node' for power users who wish to help build the network.
https://gitlab.com/veilid/veilid
https://youtube.com/watch?v=Kb1lKscAMDQ
> VeilidChat is a chat application written for the Veilid distributed application platform. It has a familiar and simple interface and is designed for private, and secure person-to-person communications.
https://gitlab.com/veilid/veilidchat
Previously:
Veilid is an open-source, P2P, mobile-first, networked application framework
180 points 4 months ago 71 comments
https://news.ycombinator.com/item?id=37118124
Cult of the Dead Cow wants to save internet privacy with new encryption protocol
141 points 4 months ago 79 comments
https://news.ycombinator.com/item?id=37018404
https://gizmodo.com/cult-of-the-dead-cow-launches-veilid-enc...
If I owned the largest messaging networks, I would enable end-to-end encryption by default too.
I will trust FB only if metadata is also encrypted, their code is audited by a trusted 3rd party organization, and they can prove they are running only the audited code in production. And even then I would have some doubts.
Maybe. I don't live in that country. If perfect secrecy isn't achievable, I rather not let domestic actors to peek at my data.
>uses a dodgy protocol
What do you mean by dodgy protocol?
I don't know if this is still true, but because of this, I have serious doubts about anything security related coming out of FB.
[1] Being intentionally vague here as to not dox him.
This is because encryption needs keys, but when you talk to your friend over these services, under no point did you personally exchange any keys. This means that you’ve decided to let the service generate and keep the keys for you.
It’s like getting a deposit box at the bank but instead of keeping your key, you give your key to the bank to keep.
What would stop the bank from opening your box would be its own ethics policy and the quality and depth of their internal processes. They are not physically prevented from bypassing them however.
It’s still a W with these rudimentary E2E chat implementations because your ISP and government might find it a lot more difficult to read but it’s not quite exactly super strong security.
https://support.apple.com/guide/security/imessage-security-o...
This is about to change with contact key verification and transparency, though.
A BIG part of successful encryption is key exchange.
A successful SSL/TLS man-in-the-middle attack exchanges false asymmetric keys.
They keys are still generated and kept using software they wrote.
Second, they also control who they trade the keys between.
This is contrasted to some chat apps (which are painful asf to use) where you have to manually exchange keys, meaning you have to engage with the party you want to talk to and so you can confirm who you are really encrypting messages for. It’s physically impossible to be given the wrong person’s key because you personally had to get them.
[1] https://security.apple.com/blog/imessage-contact-key-verific...
[2] https://engineering.fb.com/2023/04/13/security/whatsapp-key-...
Of course, if the software is not open source, that's hard to police. But abstracting away the key generation from the user doesn't mean that the services can read your messages.
Even with that, there are still two concerns:
- Compromised clients: either malicious updates or buggy code.
- Security design issues: for example, if iCloud can just surreptitiously add keys to your account, it can trivially make the security moot. (I am aware this is currently an issue, though apparently it is finally going to be resolved somehow.) At least this one is tamper-evident though.
I hope I'm not misrepresenting reality here. Either way, software with reasonably strong E2EE guarantees that still has decent user experience is more possible than it ever has been. The last remaining problem is account recovery, and Apple has a bit of a leg up on this one since a lot of Apple users will have multiple devices that they can use as a backup, even if they lose a device and forget their password simultaneously.
- To ensure that you message is unreadable, you must correctly encrypt the data symmetrically or asymmetrically with a key. Well we can assume Apple or Meta can do this properly.
- Second, as the sender or recipient, you MUST verify the authenticity of the key, whether you are using asymmetric or symmetric encryption.
In TLS/SSL, key verification is handled by third parties called certificate authorities.
In SSH, key verification is handled by comparing the key signature that the SSH client displays.
Most of these services right now do not do either (trusted third party or display of a key), therefore it cannot be verified overall. (That said, some people said they are doing what SSH is doing soon.)
I’m happy Apple is doing those things to exchange your own key between your own devices. This is already way better than most services. However, that problem is orthogonal to the problem of key exchange between you and a recipient.