beef tallow and red meat baby.

but nothing prevents improvements now, right? Just giving the user more fine grained tools at data host. Just like you did way back when.

It is admittedly a hard balance to strike. But the platform hosts should still be able to do better without modifying scopes or standard:

For example:
- I want Google drive to let me limit access to just some folders. I choose, not the app.
- I want Slack to let me limit access to some channels.

Yeah I can see how they're likely to be imperfect but... It could still help these conversations maybe?

Maybe it's time to define e2ee levels? L1 is no plaintext sitting on servers. L5 is full Signal implementation with verified public keys in person.

Maybe someone has done this already?

For what it's worth, I don't think you and I are that far apart on what we're suggesting. I think tools are mature enough that DMs should be properly e2ee for all new designs.

I was only saying that if some use cases are not as well covered as Signal, that's not a reason to give up entirely.

Agreed, it's tricky to communicate. But there is still a real difference between plaintext everywhere and some subtle active attacks still exist.

I see email calendar widgets now in gmail... I think they work well? But maybe they don't look at other shared calendars?

But yeah, anyways, more of this type of functionality indeed.

almost like there isn't a commercial interest in making that happen ;)

My sense is that most people will not read carefully but will assume there's some security in DMs. "Elon can read your DMs" is surprising to most people.

I don't think any dev should implement e2ee. But if you're going to implement DMs on a growing, major platform, you should really try.

One shouldn't exaggerate security features, for sure. For example, if Bluesky implemented basic MLS and said "DMs are pretty secure, but not as secure as Signal", that would be great.

Thank you for doing that.

Yes, like I said, if your argument is "it's still hard", no disagreement.

But when you categorize it under "roll your own crypto", you're associating it with "never", and that's the logical and definitional mistake.

Well, I tried twice to make my point, but you sidestepped it both times. I don't think you're trying to understand it.

Good luck. I hope you don't build a plaintext-everywhere DM system.

If you say "I still think it's too hard to implement this safely" ok, that's your opinion that's valid.

But when you say "I hear that I shouldn't roll my own crypto, so this thing I don't want to do, I'm going to call it 'roll your own crypto'", that's not an opinion anymore, that's just incorrect.

The problem is that this isn't a difference of opinion, you're just factually wrong and you have two cryptography engineers telling you so.

You're reaching the *opposite* conclusion that "don't roll your own crypto" was meant to convey.

Also, there are a number of vetted cross-platform implementations of MLS. So not only is there no need to roll your own crypto, there's no need to roll your own crypto *implementation*.

Surely, it's possible to screw up integrating the library, but that's still better than plaintexts everywhere.

Using the right terminology matters here, because when you conflate issues and label @durumcrustulum.com 's recommendation as "rolling your own crypto", you're implying that her recommendation goes against broadly accepted security engineering. That's not the case.