[Cryptography] Signal planning to drop support for plaintext SMS
phill at hallambaker.com
Fri Nov 4 21:08:22 EDT 2022
On Fri, Nov 4, 2022 at 1:59 AM Natanael <natanael.l at gmail.com> wrote:
> Den fre 4 nov. 2022 02:06Phillip Hallam-Baker <phill at hallambaker.com>
>> 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.
>>> > 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:
>> 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
> 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.
I am thinking different backgrounds / window frames with user ability to
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.
That is exactly what my proposal is proposing. The only difference between
asynchronous and synchronous is the use of a presence service as opposed to
As LISP folk know, lists are a powerful base structure, can use them
to represent pretty much anything. Blockchain is simply an append only log
with some structured cryptography. Mesh DARE simply goes one stage further
and adds incremental encryption to incremental authentication.
The draft mentions an annotation service where people comment on docs but
collaborative editing of a doc is another obvious approach.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography