[Cryptography] Signal planning to drop support for plaintext SMS

Natanael natanael.l at gmail.com
Thu Nov 3 21:59:35 EDT 2022

Den fre 4 nov. 2022 02:06Phillip Hallam-Baker <phill at hallambaker.com> skrev:

> On Tue, Nov 1, 2022 at 9:40 PM Rick Smith <me at cys.me> wrote:
>> On Nov 1, 2022, at 1:12 AM, William Allen Simpson <
>> william.allen.simpson at gmail.com> wrote:
>> >
>> > We're talking past each other.
>> Correct.
>> > This is a usability issue.
>> I’d say it’s a threat issue. If you perceive no threat when plaintext
>> resides on a third party server, then you are correct for that situation:
>> it is entirely a usability issue.
> OK so I am going backwards and forwards on this because I have this
> end-to-end secure platform that was originally designed to support
> end-to-end secure social media and a James Bond villain has just bought out
> my favorite social media platform.
> So of course, end-to-end secure EVERYTHING:
> https://www.ietf.org/archive/id/draft-hallambaker-everything-00.html
> But, but...
> In order to build a user base, the application has to provide backwards
> compatibility so people can use one app to interact with Mastodon, Twitter
> and EVERYTHING. And that means that there will be encrypted and public
> forums through one tool.
> And even if it is just EVERYTHING, there will be completely public feeds
> on it and so there will be red and black merged.
> I am thinking that the more sustainable approach is one app for red and
> black social media but with distinctive UI chrome to identify which mode
> you are in. Something like the Black border for InPrivate window in
> Edge/Chrome.

I have plenty of ideas on the UX part of this. There's numerous concepts
already in use in apps that have similar concerns, like "vaults" which
needs an extra PIN to unlock, different backgrounds on messages marked
sensitive, etc.

If you for example look at the MS Teams documentation for GDPR and other
legal compliance features, the sensitivity of data of different types can
vary a lot and you might have retention requirements for one channel and
deletion requirements for another channel and strict requirements to not
mix the two (which might be enforced by filters/alerts on different types
of customer data).

A universal solution needs to support defining many different types of
channels / rooms / interfaces with different access controls and UX and
retention / deletion policies.

Slightly off topic, it might just be a good idea to treat chats /
asynchronous inboxes / collaborative document editing as different sides of
the same coin, since it's all just different ways to express ideas over a
network. For example, I've already mentioned an idea of a messenger built
on top of a distributed database with document editing, which would allow
you to do things such as link ephemeral chats with persistent documents on
which you record and edit and organize quotes from the conversation which
you want to keep.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20221104/9de5433b/attachment.htm>

More information about the cryptography mailing list