
Riot/Matrix enables cross-signed verification and E2E encryption by default - Arathorn
https://blog.riot.im/e2e-encryption-by-default-cross-signing-is-here/
======
myu701
Between this announcement, reading the deep dive, catching the "this Week in
Matrix", and the work of the creator of Mistborn, my tech-support-coerced
family Signal groups are soon going to have their days numbered.

Bravo Matrix contributors! This work in my mind is as close as we can get to
the golden days of Pidgin being able to talk to everything and everyone, and
having E2EE default is a must-have these days. So amazing to watch the
progress of this from 'a few HN talking heads' to 'hundreds of contributors
and dedicated staff'.

While Matrix will feel less secure than Signal since the feature just landed,
having the E2EE data be self-hosted, federation-possible, and support multiple
clients, removable-users-from-groups, and other features Signal is working on
but tight-lipped about, means the trade off is increasingly trending towards
worth the cost of migration to another client.

Matrix is just so much more collaborative and less authoritarian than Signal.
Don't get me wrong, I currently use Signal above all others, DMs, groups,
calls, the works. But the cloak and dagger radio silence, reticence to accept
PRs, and lack of even basic documentation to self-host your own Signal server
do eventually leave me with a sense that, while I'm glad for free access to
this most-secure-for-my-use-case software, even free apps on phones and
desktop could be improved.

------
jooize
Awesome! Thank you all for making Matrix and Riot a user-friendly and
trustable messaging platform.

> Finally, we no longer nag and block messages even when an unverified session
> appears in a conversation - the user’s shield going red is your cue to warn
> you that badness may be happening.

As with dialogue boxes stealing focus, without mitigation, not warning exposes
me to a window of risk when an unverified session appears around the moment
I'm sending a message. Assuming there is zero latency of the shield, being
human I can anyway not expect to react in time and abort my sending of the
message to the potentially adversarial session. If a new session appears and I
submit a message within a time period (to be determined), I need some form of
mitigation to prevent sending that to the new untrusted session.

An immediate idea is to send to all except the new session(s), and ask about
sending to the new. That would avoid interrupting the flow of the writer.

~~~
Arathorn
mm, that could be a nice solution.

------
svtiger
Soo proud of the Matrix Team!!! You are doing great work! Thanks for the
transparency and doing your best to implement this protocol. Can only imagine
the moving pieces and hard work to get this right.

I've had the pleasure of meeting some of the core team and they are some of
the smartest and humblest people.

Looking forward to the realization of a unified and open
messaging/communication layer with the help of your thoughtful effort.

This work may sometimes be thankless. But here to say the community
appreciates you all; including all the open source contributors working on the
clients, server implementations, and supporting software (bridges, extensions,
bots)!!

~~~
Arathorn
Thank you - the thanks is hugely appreciated; E2EE-by-default has been a
never-ending project with a lot of moving parts, and given the end result is
basically invisible if successful, and the enormous blogpost is a bit
indigestible, it's really nice to hear the encouragement and positive
feedback. Thank you for believing in Matrix and supporting us!!

~~~
svtiger
You and your team deserve it and much more!! Actually love how you put things
in one place. The API documentation is a good example. Rather not have to
search around and go from page-to-page searching for things; feels like a
feature to me;)

This is what I'm talking about. Responsive communication from all levels. And
not just because it's HN and "like we gotta look good now because we announced
something." Responsiveness has be consistent and the baseline throughout my
involvement with Matrix as an organization and a community.

Also really appreciated the full workup on the latest release. Know with
developing like 15+ applications is hard enough, getting information out to
the community in a thorough way is such a heavy burden on top of all the other
work going on.

Few questions -- Any timeline on when:

* account-password/backup-key-passphrase will be consolidated (end-of-summer possibly -- _fingers crossed_ );

* ‘trust on first use’ (TOFU) will be integrated;

Think those two features will be important for improving UX.

Also, encrypted search via Seshat: Simply, YESSS!!

~~~
Arathorn
:)

So, cryptographic login (i.e. consolidating login password and recovery
passphrase) is a fairly challenging task, which is why we descoped it from
E2EE-by-default. For instance, we need to make sure we don't break clients
which don't want to do cryptographic login (e.g. Riot single-sign-on, or those
who don't support E2EE). We also need to make sure that users can reset and
rotate their passwords without losing their E2EE history. We'd also have to
completely rewrite the registration/login process in Riot (again). We can't
commit to timings on it, but based on the feedback from E2EE-by-default it'll
be pretty high on the todo list.

TOFU is much easier, and hopefully we can sort it out as part of incremental
fixes having now gone live. We almost snuck it in before release, but it'd
have pushed things out even further. [https://github.com/vector-im/riot-
web/issues/12719](https://github.com/vector-im/riot-web/issues/12719) is the
bug to follow here.

But yup, these will be the difference between today's 1.0 and an (even) better
UX.

