Great to see implemented in Android Codebase.

Messaging? Whithout having read any deeper I guess this means Whatsapp. No suprise that Google, otherwise known more as an evil monopolist is talking warmly about interoperability.

No this is for Google Messages first and foremost but the Google impl will be an AOSP API so that other android messaging apps can all share the same implementation.

Also WhatsApp isn't even google. That's Meta/facebook.

Sure WhatsApp is not Google and it is very strong. That's why Google supports interoperability in this case.

> Whithout having read any deeper I guess …

May I suggest an antidote to this?

RFC 9420: https://www.rfc-editor.org/rfc/rfc9420.html. Its abstract:

> Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.

So, it’s just the end-to-end encryption stuff with double ratcheting and such, not anything about a particular message format.

>So, it’s just the end-to-end encryption stuff with double ratcheting and such, not anything about a particular message format. This makes it a very valuable element for interoperability, and I think might make bridging work better?; but it’s not sufficient for mixing messaging services in any way, nor is Google proposing anything like XMPP of “implement this and you can federate with our service”.

There's ongoing work at the IETF to create a new protocol called MIMI (More Instant Messaging Interoperability)[0], which will use MLS as its E2E crypto layer.

There are Google reps on the working group, amongst others.

[0] https://datatracker.ietf.org/group/mimi/about/

MLS is built upon ART, Asynchronous Ratcheting Trees.

Given the amount of messaging apps Google creates and buries over the years, it makes sense to put some of the code in a library for reuse to increase velocity :)

And make them interoperable!

Should make a plugin for pidgin...

Maybe Google will be releasing an entirely new app to adopt this new interoperability spec... we haven't seen a Google messenger being retired in what... almost a full year? :)

If you read the article, it mentions they will be open sourcing the implementation through android.

maybe they will ditch the protocol over the years and come up with new protocols instead

I'm a bit surprised to see how centralized MLS seems to be? It seems like someone has to act as a coordinator, for the ratchet to work?

I reviewed Matrix's https://arewemlsyet.com/ recently, after getting again curious about MLS. Activity definitely trailed off after some initial excitement. But they did have some chatting about how they wanted a decentralized MLS, https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentral...

Also, note this article here is from July 19, 2023. Have we seen any further activity since this announcement?

MLS just handles the encryption part. MIMI should handle decentralisation. Combining the two should allow for E2EE interoperability between all kinds of chat services and servers (hopefully allowing for some decentralised chat services like XMPP becoming relevant again), but just MLS isn't going to cut it.

MIMI isn’t decentralised (having just come back from IETF118 i can confirm this firsthand) - much like MLS, each conversation has a hub.

Matrix however is decentralised, and decentralised MLS is live and well and in active development - we need to update arewemlsyet.com.

Hi.

I watched an ietf video of meeting, second last maybe? And they were discussing types of users.

Companies, like Google WhatsApp

Corporates. Govt.

End users with own servers.

The idea was end users should not be part of the decentralized network as you cant ask FB to network with a 1 person server but isnt matrix.org already able to do that? Why take that functionality away when it works without problems? Yes spam but it can be managed

It’s great to state intent, but when exactly it’s supposed to happen?

Also, strangely enough, this post is by “Privacy Engineering Director”, but google’s messaging is not implemented by privacy team, so is this going to be “privacy team developed proof-of-concept abandonware” to be never picked up by the product team?

I'm familiar with some parts of that team and I can say there is no capacity for development of proof-of-concepts. They are not engineers in the way you're thinking.

What does that even mean? I think it's entirely reasonable to ask if this has a chance of being adopted and supported long term (and entirely reasonable to not be particularly polite about it).

Google has a long history of abandoning products that aren't ads or search, especially messaging products. Nearly forty messaging products by my count.

I read this as “your very specific hypothesis of team structure leading to abandonware is factually incorrect” implying it’s some other team building it and therefore we have no idea how much resource is invested in this.

As a counterpoint, the DMA is requiring “Gatekeepers” like Google to enable interoperability for their messaging systems, so this protocol (or some other alternative implementation) is likely required to avert billions of dollars of fines.

Right, but abandoning projects at Google is an endemic problem. The specifics of a team are almost entirely irrelevant.

What it means is, if it is ever created, the privacy engineers will be acting in a guidance and advisory role and not actually literally building the product.

>Without robust standardization, the result will be a spaghetti of ad hoc middleware that could lower security standards to cater for the lowest common denominator and raise implementation costs, particularly for smaller providers.

This seems to be based on the same sentiment as expressed in XKCD-927[1]. We will fix a standardization mess by introducing a new standard that covers all the existing use cases. Dunno if efficient end to end encrypted groups with thousands of users actually counts as an existing use case. There doesn't seem to be any way to make such a thing practical in actual use.

[1] https://xkcd.com/927/

We all love xkcd but the incredulity wears thin. This isn't like 14 existing groups with 14 standards and a 15th bro coming up with a 15th standard. This is more like 14 existing groups with 14 standards coming together and saying let's replace our 14 standards with a single 15th standard.