Is it naive though? Naivety is a suggestion showing a lack of wisdom or experience. Stallman has this in spades. I'd peg this as 'idealist'.

To wit, imagine a world where:

* Everyone has a block of static, globally routable IPs (no NAT).

* Consumer broadband etc was less asymmetric, and not strangled my media conglomerates.

* Everybody ran a decent operating system with a package manager that handled updates for all their software.

* Server and P2P software was so easy to use that it became invisible

* The Internet hadn't become synonymous with 'the Web' for most people in the 90s/early 2000s. (Remember when we used to talk about 'the Web' just like how we talk about 'the Cloud' now? That's because, as far as most people are concerned, it's the same thing.)

... in such a world, suggesting everybody run their own server doesn't seem so crazy. In fact, there's still a lot of grass-roots belief in these ideals : http://redecentralize.org/

> The world doesn't have time for everyone to deploy their own server. I mean, honestly, ask yourself if you even have time to do this, or if it's just yet another project that's going to get piled on top of the Raspberry Pi and Beaglebone Black you have sitting in your projects box.

If there is something naive here, I would think it's this? What is so inherently difficult about deploying a server? If you want to find out what the right thing to aim for for the future is, it's not useful to base that decision on what is currently the case. By that measure, thirty years ago, you would have argued that computers for everyone was naive (honestly, ask yourself, who would have the time to learn how to jumper the IRQ and IO port assignments and all that?), and yet, somehow, we managed to end up with everyone carrying computers around all the time. Notice, though, how people don't actually manually assign IRQs on their iphones?

I mean, what is even the fundamental difference between a "server" and a "client" that makes one of them so incredibly difficult and dangerous, but not the other? It's both just software talking to other software over the network. Yes, if you have crappy software, you can end up with huge security problems. Ever heard of Windows 95?

>The world doesn't have time for everyone to deploy their own server.

I heard people say the same thing about smartphones before the iPhone - that they would always be the preserve of nerds with too much time on their hands.

>I mean, honestly, ask yourself if you even have time to do this

I'd actually like to once there's a sufficiently easy to use project to automagically set up and configure a raspberry pi.

Something like this but with fewer manual steps: https://github.com/sovereign/sovereign

It doesn't sound like he's advocating that everyone run their own server. He said that if you require your data be available all the time, then you should run your own server; otherwise, you should keep your data on your computer.

That being said, I don't see a problem storing data on someone else's computer as long as that data is encrypted and I alone have the ability to decrypt it. Trusting someone to encrypt your data for you when you give them your data is essentially the same thing as giving them access to the unencrypted data.

> Trusting someone to encrypt your data for you when you give them your data is essentially the same thing as giving them access to the unencrypted data.

Absolutely agreed, which is precisely why it's so important to be end-to-end, which implies client-side encryption. Unfortunately, this is a totally different environment than we're used to; it doesn't break the internet, but it definitely breaks the web. Part of the challenge of the work I've been doing on this problem has been to envision exactly how this new thing would work. It's really cool stuff, but it's a dramatic departure from what we're accustomed to.

> It doesn't sound like he's advocating that everyone run their own server. He said that if you require your data be available all the time, then you should run your own server

The problem is, total availability is exactly what we've come to expect from the vast majority of internet use. This is particularly true of the most popular websites. Facebook, google, etc wouldn't work with totally intermittent data availability, but for a growing number of people, they are the internet.

Yes, I wonder if RMS has any objection to clouds where the user data is encrypted end-to-end, like with Tahoe-LAFS. Does that count as running your own server if you have client-side encrypted data through Tahoe backed up on Amazon servers? Or is there too much info leaked, or some other way that Amazon could engage in hostile behavior with respect to data it cannot read?

If there is no risk of surveillance or lock-in, he'd probably be ok?

After all, "cloud" is a pretty ill-defined term. He certainly doesn't object to things because someone calls them "cloud-something", but because of the power structure they entail--which happens to include stuff such as surveillance and lock-in with a lot of the stuff that's currently being sold as "cloud services".

Cryptography gives you control, but not autonomy.

Open formats and standards that are fully usable on other platforms are also important. Many companies provide "export" functionality, but actually using your own data from some XML file often means a non-trivial programming project.

You need formats where you can make them usable easily, using free software (ideally several options), on multiple different kinds of platforms (cloud, local pc, mobile).

That gives real data autonomy.

I agree that preventing node-locking is a critical step in being able to make data decisions. I'm on a bit of a personal crusade against lock-in, actually, but I'd argue that's different from the kind of autonomy (probably better described as agency [1]) we're referring to in this context.

Having control over information creation, retention, and sharing is what I would describe as agency of data possession. Node-locking, open standards, etc, create what I would describe as agency of data use. They're both incredibly important, but you can't use data without possessing it.

[1] Linked because it's an infrequently-seen term outside of philosophy and sociology: https://en.wikipedia.org/wiki/Agency_%28philosophy%29

Does end-to-end encryption answer the problem of vanishing servers?

It is naive, and it's poorly articulated, unfortunately nearly broaching the 'tin-foil hat FUD, disregard everything he says, that nutter' territory (see: his "cloud" analogy). I like to think of Stallman as Chomsky -- a little out there, really attached to their ideologies, but usually they bring up a conversation that's worth having.

The second I heard this, I as did you thought about the problem of hosting your data at a DC; likewise, I too saw the 'everyone hosting their own server' problem[2]. It's no coincidence that there are at least 3 of us (StravosK and the #letsauth HN crew, you, I) working on this. Many more[3] in fact that we might be reaching the "too many NoSQL solutions out there" problem.

I agree with you I haven't had time to go over your work but consensus algos for removal of data is an impossibility (the second someone has access to the decrypted data is the second it's fully compromised at the read level[1], and only later can one mark the data as unreliable. Consensus to determine what's unreliable is possible, though fraught with peril. There be dragons.) Secondly - and I say this as someone who's working on software similar to what you are writing - in order for crypto to be adopted there needs to be a lot of things. Primarily, there needs to be one, at worst two, solutions - or we'll suffer from complete and total 'choice overflow' (i.e. which NoSQL solution do I use? There are 50!). Secondarily, crypto should ideally be written around known algos, and more importantly, known algo implementations (e.g. libsodium) which are based around concepts and have been heavily audited. Finally, there should be interop between the systems. I.e., keybase.io has already solved the problem of getting techies to adopt asymmetric crypto/figure out how to exchange keys/etc by tying a users FB identity to it. Not the ideal solution, but the best trade off for user adoption. Awareness is hard, but if we all band together (#letsauth + keybase.io + Automattic is a realistic possibility), I don't see it being impossible.

Bottom-line: _Ensure interop with previous implementations so we don't overwhelm the internet with choice, effectively shooting ourselves in the foot_

[1] I can write an IO device driver in a weekend that'll clone bit-for-bit anything that hits a specific directory, segment of memory alloc'd by a process, etc. Once your information is out, it's out for good.

edit: [2] On second thought, not as far-fetched as it may seem. ARPAnet was designed around maintaining network communication in case of nuclear disaster, and if you read the spec sheets that came out during that time decentralization was their solution. Everything from routing (RIP, OSPF, BGP, take your pick) to SMTP (the RFC is rife with the capacity to handle server unreliability) was designed with the intention of dealing with this. Not only that but before NAT took over, effectively every machine was effectively capable of operating as a server. It wasn't until say the mid 90s that the distinction between workstation and server became clear. Effectively, you trusted your sysadmin to not read your mbox/maildir and he acted as your technical agent. When my friends and I were dicking around with BSD and Slackware in middle school and early high school (oh what rebels), we ran our own SMTP's acting as backup MX for each other when our Pentium 2's were rebooted by our parents. This is all a long way of saying, not everyone needs to run a comm-server, just one (or two if you need a 'backup MX') per social network in order to offer their services to people within their social "web of trust".

[3] http://pythonhackers.com/p/redecentralize/alternative-intern... - That's not even the start of it.

Edit2: Yeah, #letsauth on freenode is the defacto standard, thus far. And have an upvote, my good man, for caring enough about security to do something about it, and speak about it's subtleties on a Sunday afternoon.

This is maybe a discussion we should be having elsewhere, but for lack of a dedicated thread somewhere, and because I think it's interesting, I suppose we might as well keep going on the tangent. Moving forward though, is there anywhere dedicated to talking about this kind of stuff, or should we set somewhere up?

> consensus algos for removal of data is an impossibility

There may be a bit of a semantic barrier here. What I mean by consensus removal is "can we, as a society, decide that it's okay to delete this piece of data?" That can be done as a zero-knowledge algorithm. The approach I've taken with it is, loosely speaking,

1. Author Alice publishes (encrypted) data, tells server "don't delete this"

2. Alice shares with Bob; Bob also tells server "don't delete this"

3. Alice tells server "now it's okay to delete"

4. Alice can see that Bob is preventing deletion

5. Alice provides social/legal/political pressure to Bob to remove his hold

6. Object gets deleted

Technically it's implemented in a way very reminiscent to name binding and garbage collection in memory-managed languages. It's worth noting that no, this isn't something that's solvable strictly with in-protocol actions. The external pressure step is necessary to prevent deletion. But that's exactly my goal; we're never going to be able to solve profoundly complex social problems with algorithms.