[guardian-dev] Ciao TextSecure SMS

Drake Wilson drake at dasyatidae.net
Fri May 15 00:04:00 EDT 2015


So, in case it wasn't clear from my last message: all the parts I am
talking about where the PSTN has a "better" identity model are not mainly
reliable technical characteristics; they are mainly social characteristics
which are unreliable but have a fair amount of inertia behind them (as far
as I've been able to perceive).  They can be eroded by any kind of sweeping
control over the PSTN, and this can be quite relevant.  Similar arguments
tend to apply to the Internet/DNS, though the details are different.

The main reason I brought any of it up in the first place is that it's
very easy to wind up with implicit centralization using things like GCM
where the predominant (and possibly enforced?  I forget) model is "one app
implies one authoritative set of relay servers", and ignoring this while
casually talking about the merit of data transports could be dangerous.
(I'm also not saying that GCM etc. should never be used.)

Jacob Appelbaum wrote:
>> AFAIK, WhatsApp and
>> the new TextSecure (and iMessage, and Telegram, and so forth) are all
>> centralized-identity networks: if the master computer says you don't have
>> a name/number, you don't have one and you can't talk to anyone.
> 
> That just means you have to make a new account or get a new device -
> not that you can't talk, no?
[...]
> How is [sudden imposition of unfriendly requirements] different from my
> phone provider doing the same thing? Or charging me crazy expensive rates
> for unencrypted services?

Well, in the current case, both of those can happen simultaneously, to start
with!  (And given the current concerns regarding "zero rating" in some
markets, it seems more likely that you'd get the expensive rate for the
_encrypted_ service...)

"recognize 'banned' users to stop them from making new accounts" is easier
with a centralized service---and it's socially easier to justify.  "Well,
you know, it's their network, so if you don't like it, don't use it" is a
common refrain across the Internet for centralized social sites.  With
something like TextSecure, you can just as easily have "they're putting
in all the effort to operate the server for free, so what right do you
have to complain about how they operate it?".

Aside from that, some mitigations on the PSTN are that (a) you can often
switch providers if your current one goes crazy and (b) any single provider
will have trouble hitting most classes of users in a correlated way.
The stronger forms of (a) rely on regulation, and (b) is weak against
natural correlations and government intervention, but trying to fix that
by turning around and giving the master keys to a single someone else is
a strange move if done by itself.

>> Using SMS as a fallback "authoritative" channel to bootstrap
>> other channels can be a nice approach so long as the fallback stays in
>> place.
> 
> I'm confused - Redphone, Signal and Textsecure all use SMS for that
> exact reason, no? And as a result, it is actually not so fantastic,
> ironically enough...

Let me try that again.  Using SMS as a _fallback_ communication channel
can be nice in that the identity stays with the SMS channel (at least sort
of), but you don't have to be constantly dealing with its transport
characteristics.  Using SMS as an _initial_ registration channel means
that the identity stays with the "new" channel.  TextSecure used to provide
SMS-as-fallback, but now it only provides SMS-as-initial.

The main difference is there's more leeway for decentralized checking on
the "overlay" identity provider's behavior in the fallback case.  If the
TextSecure server silently cuts me off, but the clients on both ends still
support the SMS channel, there's a chance I can notice my messages are not
being received and switch back to SMS (with the same long-term keys) in
order to negotiate the use of another channel at the human level.  Now that
the client doesn't support the encrypted SMS channel, I can't do that
anymore (without dropping to cleartext).

That leeway is still pretty hazy, but it gives the users more power
to make the transition smoother if the identity provider goes crazy.

None of this is really fantastic regardless.  :-\

(This isn't to say that less transport-dependent identity models and
more flexible kinds of transparent multi-transport support might not
be even better!)

> All the best,
> Jacob

   ---> Drake Wilson



More information about the guardian-dev mailing list