Hey Drake, Thanks for bringing this up, it is definitely some key analysis on what makes systems open versus closed. It is exactly because of the problems of centralized identity that you outline that we advocate for using open, federated systems like XMPP and email. Those systems are built upon rules for exchange, and once a system is built upon those rules, it becomes quite difficult to lock people out from the system. Of course, that does then make spamming easier, but there are other ways to deal with that besides centralizing identity.
Since this topic started around TextSecure, there is some form of federation in TextSecure: the Whisper Systems TextSecure users can send/receive messages between the CyanogenMod users. But that system is not open, since the server is proprietary and private, and even if it was open, it is an eco-system of two, so almost entirely centralized. It is sad to see this silly repeat of the cycle we saw in email in the 1990s: open systems make the idea popular, then lots of excuses are made to silo users, then whole idea looses value because their communications are siloed. At least with email, it bounced back to a flourishing, open federated system (though things are getting scarily centralized in Google and a couple of other big providers). .hc On May 15, 2015, at 12:04 AM, Drake Wilson wrote: > 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 > > _______________________________________________ > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > To unsubscribe, email: [email protected] _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
