I'm defending the idea that they are disinterested in change not because they are ignorant, but because they are fully aware and accepting of what they're giving up. I am not arguing that they don't care either way.
If they otherwise don't care, but they appreciate the usability and convenience features of these products, then that is an objection to change if they won't get the same features in more open, private alternatives.
My second point is this: if enough people can be described as both aware and accepting, then mainstream change will not occur because people like what they have more than they like their privacy, and they make that decision in an informed and responsible manner that does not provide a market opportunity.
You can make an alternative, and it can be great (e.g. DuckDuckGo), but it will not be mainstream.
At which point you're in the minority because the set of people who affirmatively want to give up their privacy is not larger than the set who either don't want to or don't care.
DuckDuckGo is not decentralized, it's just a worse Google with a better privacy policy. Actual decentralized search is hard. But this is not a one-time global binary decision. We can have decentralized YouTube and Facebook even if nobody has yet figured out how to have decentralized Google.
I would suggest that having Facebook's userbase is a core part of having Facebook. If you don't have Facebook's userbase on your "decentralized Facebook", you have a strictly inferior replacement to Facebook. The set of people who care enough about the benefits (which do exist!) of decentralization is not and never going to be enough to overcome the downside of having nobody there.
That's the problem you have to solve if this is something you really care about. Haranguing people because they're not using it isn't the way. The way to do it is to figure out how to make it attractive by the users' metrics rather than your own.
> That's the problem you have to solve if this is something you really care about.
We already know that. It's not trivial but there is a clear path.
You make something that will become popular for reasons unrelated to the thing it should replace, it just happens to also be able to replace it. Once you have something that everybody already uses for other reasons and can do everything Facebook does, anyone can start using it instead of Facebook without waiting for anybody else.
The interesting thing is this bootstraps across the whole space if you can do it once. Given a decentralized social graph you can take over for YouTube as soon as you have video support etc.
I would say it's not trivial and there isn't a clear path.
YouTube is not just a web server for videos. You can't set up a decentralized, P2P real-time streaming network (like webtorrent) to replace YouTube. Many of the features that make YouTube virally successful and a continuing platform are developed based on research produced by its analytics which sacrifice privacy to improve insights into what users care about.
YouTube also has a profitable business model, which provides a capitalist incentive to improve the product according to user demand. To make a comparison - which are you betting on in 2016 - IRC or Slack? Even if you set up a successful open source project to replicate YouTube, how will you develop it as well when your best employees are poached because they aren't paid as well as centralized companies?
How about the analytics features? How do you design an anonymous or decentralized recommendation engine with the same or similar utility? How do you power search relevance in a meaningfully private and decentralized way? How do you add the social networking features that people care about without a centralized social network?
The fact that you can technically make product clones with distributed graphs does not on its own constitute a feasible replacement. The basis of modern product research and improvement is data tracking and analysis. You can argue that it can be curtailed or scaled back to improve some privacy, but we haven't even started talking about the performance constraints of decentralized search, streaming, etc. Where will the primary files (e.g. videos) and supplementary files (e.g. recommender models, analysis features, graph, infrastructure, etc.) be hosted? How will you guarantee similar uptime and performance rates to AWS and GCP with a decentralized network of seeders?
You strictly cannot replace products like YouTube, Facebook, Netflix or Google with decentralized counterpoints. The demand and feasibility is not there.
> Many of the features that make YouTube virally successful and a continuing platform are developed based on research produced by its analytics which sacrifice privacy to improve insights into what users care about.
I think you're overselling it. YouTube is successful predominantly because they originally had first mover advantage and now have a direct link from google.com.
The problem decentralized services have is the same problem Google has had in taking over for Facebook. You need to provide something which is enough better than the incumbent that it can overcome the switching cost. The problem has nothing specifically to do with decentralization, and time has proven again and again that it can happen, every time one network replaces another. The next time it happens we just need the new network to be a decentralized one.
> To make a comparison - which are you betting on in 2016 - IRC or Slack?
Here's a different question -- which are you betting on still being used in two decades, IRC or Slack?
That's one of the huge advantages of decentralization. Things stick around because they don't die when one company goes out of business. Which means the process of incremental improvement can refine them into something that, once it has the incumbency, is almost impossible to displace. Examples: TCP, email, Unix/Linux, DNS. None of them are perfect but they'll be with us for the rest of our lives.
> Even if you set up a successful open source project to replicate YouTube, how will you develop it as well when your best employees are poached because they aren't paid as well as centralized companies?
The same way it works for Linux or BSD.
> How about the analytics features? How do you design an anonymous or decentralized recommendation engine with the same or similar utility? How do you power search relevance in a meaningfully private and decentralized way? How do you add the social networking features that people care about without a centralized social network?
Decentralized search and recommendations are hard. So do the easy part first.
Look at YouTube. It's really two independent pieces. One is a web host for videos, the other is a player app with search and recommendations. So you decentralize the hosting and then people make apps with central servers that do recommendations and search. Tomorrow somebody else will figure out how to decentralize the other part. You can make progress without having to solve every problem in the same place at the same time.
> The basis of modern product research and improvement is data tracking and analysis.
The underlying assumption is that you can't ever be finished with anything. But the more time passes the more refined the product becomes and the less you need to fiddle with it anymore.
>>At which point you're in the minority because the set of people who affirmatively want to give up their privacy is not larger than the set who either don't want to or don't care.
The set of people who affirmatively want to give up their privacy is in the majority if most people don't care about privacy but want privacy reducing features. Sure, in a perfect world they'd take both, but we're talking about which is more important to them when they have to make a decision. You're arguing my second point, about market viability of a privacy-enhancing product. My first point, which supports my second point, is that most people give up their privacy because they understand the compromise and don't value privacy more than convenience-enhancing, privacy-reducing features.
I'm not sure if I'm conveying my points well, let me try to rephrase. I don't think my postulated demographic is in the majority if they 1) desire competitive features which reduce privacy, 2) are willing to responsibly reduce their privacy for those features and if the market alternatives (decentralized or otherwise) increase their privacy without competitive feature parity.
Basically, if the majority of people are ambivalent about privacy, understand the privacy compromise and still desire privacy-reducing convenience in features, then the alternatives will never become mainstream. This is my hypothesis, and I am pushing this hypothesis by defending the idea that most people give up privacy because they understand but don't value it, not because they are naive or ignorant and value it. The reason I am putting this hypothesis forward is because I think it's important that the HN crowd consider this possibility.
It's easy to believe people give up their privacy because they don't have alternatives, or because they don't know any better, but that perspective comes across as condescending to people who fully understand the compromise they agree to, and there is a strong argument that this is the majority of the population. If that's true, you can't expect privacy-enhancing products to become mainstream if privacy is the only competitive feature, or if the privacy precludes competitive features offered by other companies.
The overall conclusion, based on these premises, is that many privacy-valuing technies misunderstand the privacy values of the majority of the population. They believe that the aforementioned privacy-enhancing products can be competitive and replace the incumbents if only they could get people to understand the privacy breaches they're suffering. My grand unifying theory here begins with the hypothesis that most users actually understand the privacy compromise, and it's really the vocal HN zeitgeist that misunderstands the awareness of most users in this arena. By extension, they also misunderstand the market oppurtunity, mainstream potential or even feasibility of open alternatives that can change or replace the incumbents.
At this juncture I'm not sure how else to convey my point. I feel as though we are probably talking past each other.
OK, so let's actually talk about those people then. The theory is that there is an unavoidable compromise between privacy and features and some people will legitimately choose features. That can be true, e.g. to do "people like you also viewed ..." you need the data on what people like you also viewed.
But those things are relatively rare and can be separated out. You can layer them on top of a decentralized system -- run this separate program that tells The Cloud everything you click on and in exchange you get the benefit of data from other people who make the same choice. That is still possible even if a video from your family gets downloaded P2P directly from your actual friends and no corporation automatically finds out about it and stores it in a database forever.
The problem currently is that the decision of whether to give up privacy is not tied only to the few features that legitimately require giving it up, it's also tied to participating in the same networks as the majority of people and many other features that don't inherently require privacy invasion.
Decentralization doesn't take away the choice whether to share data from the people who want to do that, it gives it back to the people who don't.
The data analysis required to improve search relevance, video recommendation, A/B testing, feature improvement - basically anything, relies on crunching data on as many users as possible. For example, you cannot get to Google or Facebook's level of artificial intelligence research and performance achievements without truly vast amounts of data.
This criticism of decentralization is in addition to my parallel comment in this thread about how you cannot realistically and significantly improve privacy with feature parity.
The performance and reliability would also be difficult to manage without centralized servers. You're not going to be maintaining the same uptime guarantees.
Finally, how are you going to motivate development in a decentralized manner? You're removing capitalist incentives to improve the product. This would have to be managed by a consortium of companies, which doesn't sound like a much better situation than we have now, or it would have to be an open protocol. If companies weren't earning a profit on developing features for further user demand, how would the products improve as well as they do now?
> For example, you cannot get to Google or Facebook's level of artificial intelligence research and performance achievements without truly vast amounts of data.
This argument is self-defeating. If any significant plurality (e.g. a third) of people opt into the "privacy for analysis" setting then you still have "truly vast amounts of data" and there is no trouble. Whereas if so few people want to make that exchange when the choice is made explicit that it can't even work properly then it doesn't matter how well it works because nearly everyone doesn't use it.
> The performance and reliability would also be difficult to manage without centralized servers. You're not going to be maintaining the same uptime guarantees.
Uptime is just math. You decide how much service uptime you need and based on the average device uptime that determines how much redundancy is necessary to achieve it. Consumer devices have lower uptime so you need somewhat more redundancy. And in practice not even much of that, because you want "close copies" (to improve latency/efficiency) anyway, so if you have enough copies for that then a failure doesn't reduce uptime, it just requires you to use a far copy that once.
Moreover, if you have something that really does need specific uptime guarantees or is unusually likely to incur a DDoS, nothing stops you from pinning it to a P2P node hosted on the likes of AWS or CloudFlare. Then to lose uptime you have to lose the entire P2P network and CloudFlare.
> Finally, how are you going to motivate development in a decentralized manner?
Much the same way as we motivate development of Windows, Linux and Wikipedia.
If you depend on P2P to avoid centralized servers, you're just moving the data security issues to devices that are much, much harder to lock down. That can make privacy much worse in a practical sense.
Not to mention the difficulties of reindexing and fast retrieval over P2P. If I need to add an additional index on my centralized servers, the development cycle is much shorter than forcing every peer to reindex itself.
> If you depend on P2P to avoid centralized servers, you're just moving the data security issues to devices that are much, much harder to lock down. That can make privacy much worse in a practical sense.
There is no magic security pixie dust inside a data center. If the server is vulnerable and your data is on the server then you're the same amount of screwed as if the P2P app is vulnerable and your data is on the client. Possibly more screwed because central servers have data for multiple users which give the attackers more incentive to break into them.
> If I need to add an additional index on my centralized servers, the development cycle is much shorter than forcing every peer to reindex itself.
I'm not saying it's magic, I'm saying that securing a P2P network is more difficult because the threat surface is much larger and because you have much less control over your stack. At the very least, I (should) have physical security over my own servers, and the intra-DC data links.
You can't say that at all about a distributed P2P network, so you'll need to put in more elbow grease to address those vectors. For example, if I find a severe vulnerability, I can immediately patch my own servers. If the vulnerability is in the P2P client, it may be impossible to guarantee that every last client gets patched.
> And why is that?
Because there's obviously an inverse tradeoff between control and development speed. Managing distributed state is hard enough when it's on your machines, it's exponentially harder when it's random devices somewhere on the Internet. Your guarantees are much looser.
For example:
1. Your data is less local so there is less effective latency.
2. You're spending computation and bandwidth that other people are paying for
If I need to get some big batch job done quickly and the data is on my servers, then I just up a bunch of instances and get it done. If the data is on a bunch of smartphones somewhere, I can't suddenly grab a bunch more of their computational capacity and bandwidth without pissing off a bunch of users, can I?
And what if I need to change the protocol? We're back to the problem of patching all the clients.
I'm not saying these technical hurdles are insoluble. I'm saying they are real and to date nobody has actually solved them.
> I'm not saying it's magic, I'm saying that securing a P2P network is more difficult because the threat surface is much larger and because you have much less control over your stack. At the very least, I (should) have physical security over my own servers, and the intra-DC data links.
With a centralized system you have this:
client1 <-> central server <-> client2
With a decentralized system you have this:
client1 <-> client 2
In the first case, if either client is compromised then the data is still compromised regardless of what happens at the server, because the data still traverses both clients.
And in the second case the "central server" is better than physically secure, it's non-existent. That method of compromise is removed entirely. There are no intra-DC data links to worry about.
> For example, if I find a severe vulnerability, I can immediately patch my own servers. If the vulnerability is in the P2P client, it may be impossible to guarantee that every last client gets patched.
For serious vulnerabilities the solution to this is to push the update with a date check in it that gives people a reasonable amount of time to update their clients, and after that date all of the updated clients refuse to talk to the unpatched ones.
> Because there's obviously an i, wait a reasonable amount of time for everyone to have instnverse tradeoff between control and development speed. Managing distributed state is hard enough when it's on your machines, it's exponentially harder when it's random devices somewhere on the Internet. Your guarantees are much looser.
Only if you're testing in production. If you're the actual developer then you have a test network which is completely under your control, or maybe an isolated group of beta testers who have chosen to allow you to force-update their machines.
> 1. Your data is less local so there is less effective latency.
With a central server the data is on the server and the client has to fetch it every time it wants to do anything. With decentralization you can keep the data closer to where it will be used, e.g. (a copy of) your photos are already on your device.
> 2. You're spending computation and bandwidth that other people are paying for
You're always spending computation and bandwidth that other people are paying for.
If a decentralized system uses 30 seconds of compute time every day from each of a billion devices, probably nobody even notices (especially if you select for idle devices), but do the same on AWS and your boss is going to want to know why the bill is so high.
They're all completely different. Most Wikipedia content is created by volunteers. Most Linux development is funded by corporations the likes of Red Hat and Intel. Most Windows development is done in house by Microsoft.
You obviously mean Windows as the outlier, but decentralized is orthogonal to proprietary. TCP/IP is decentralized but people still make money selling proprietary operating systems with TCP support and proprietary TCP libraries and proprietary routers and so on.
If they otherwise don't care, but they appreciate the usability and convenience features of these products, then that is an objection to change if they won't get the same features in more open, private alternatives.
My second point is this: if enough people can be described as both aware and accepting, then mainstream change will not occur because people like what they have more than they like their privacy, and they make that decision in an informed and responsible manner that does not provide a market opportunity.
You can make an alternative, and it can be great (e.g. DuckDuckGo), but it will not be mainstream.