zlacker

[parent] [thread] 7 comments
1. kordle+(OP)[view] [source] 2016-01-06 16:16:31
Every time one of millions of developers commits code to a centralized service, they have a hand in exposing individual's data to the surveillance society we live in today. Data exposure can come from being publicly available on the site itself, being obfuscated through aggregation in the service's APIs, leaked through security holes in implementation of said services, risk of theft by hackers looking for high value targets with private data, or misappropriated by the company itself or its upstream providers. The idea that customers can somehow understand the scope of their exposure to privacy violations is laughable.

One thing which became apparent to me when I began to focus on this issue was the fact there are countless other services which provide services to other services, all of which have some degree of access to upstream customer data. For example, if you log to a hosted logging service, some of your customer's data is sent to them. If that service use AWS, then data is sent to Amazon. And so on.

http://www.stackgeek.com/blog/kordless/post/a-code-of-trust

Arguing efforts to make things better is pointless is a very dangerous thing to do, assuming we actually want things to be better. Cognitive dissonance is a powerful force, especially when there are startups to be built!

replies(1): >>TheDon+L1
2. TheDon+L1[view] [source] 2016-01-06 16:32:08
>>kordle+(OP)
That is not what's typically meant by surveillance.

Sure, it turns out using centralized web services has helped the government with things such as PRISM, but that doesn't mean we should blame people for those development practices rather than the government.

Prior to PRISM, pretty much any reasonable person would assume that the blobs you store in S3 aren't going to be looked at anyone or, worst case, metadata will be seen by AWS employees for debugging stuff.

What we have done is make things a ton better for developers; we can make things quicker and more easily which empowers society/humanity. The fact that it's incidentally contributed to a surveillance society through no intent of the developers in a way you wouldn't reasonably expect does not make the developers culpable.

It is true that customer data is trusted with a lot of services-of-services nowadays, but do you want to go back to the stone age where the only people who can store anything must run their own hardware with their own databases and so on?

The right thing to do here is to call for better use of encryption where possible and, for surveillance issues, to reign in the unreasonable government programs that make this practice result in such problems.

replies(3): >>zAy0Lf+Zo >>dsp123+Is >>kordle+ia1
◧◩
3. zAy0Lf+Zo[view] [source] [discussion] 2016-01-06 19:16:49
>>TheDon+L1
> Prior to PRISM, pretty much any reasonable person would assume that the blobs you store in S3 aren't going to be looked at anyone or, worst case, metadata will be seen by AWS employees for debugging stuff.

I beg to differ. Where you concentrate power, you have to expect abuse.

> It is true that customer data is trusted with a lot of services-of-services nowadays, but do you want to go back to the stone age where the only people who can store anything must run their own hardware with their own databases and so on?

That's a false dichotomy. Yes, I want to go back to people running their own hardware with their own databases. And to have that work as easily as your favourite cloud service. There isn't anything inherent in running your own hardware that requires that to be a major burden.

replies(1): >>redbla+Pb1
◧◩
4. dsp123+Is[view] [source] [discussion] 2016-01-06 19:40:25
>>TheDon+L1
must run their own hardware with their own databases and so on

I have hardware in my pocket that is hundreds of times more powerful than the first web servers I every worked on. There is no technological reason why that same hardware couldn't be used. I'd love to have a PAN based around my phone (which is way more local to me that much of the "hardward with their own databases" that I've ever worked on. Federation to Facebook/Google/Instagram/whatever the next big thing is would be amazing. And the reason it hasn't happened even though powerful hardware is everywhere isn't due to lack of technology.

replies(1): >>kordle+T91
◧◩◪
5. kordle+T91[view] [source] [discussion] 2016-01-07 03:21:26
>>dsp123+Is
I'm working on product that federates software deployments to any target cloud using immutable data structures provided by the blockchain. It's called Wisdom.
◧◩
6. kordle+ia1[view] [source] [discussion] 2016-01-07 03:31:10
>>TheDon+L1
> It is true that customer data is trusted with a lot of services-of-services nowadays, but do you want to go back to the stone age where the only people who can store anything must run their own hardware with their own databases and so on?

This statement is in conflict with itself logically. It's arguing that diminished trust levels for data are rationalized to achieve a savings in time and cost to run the infrastructure for the application. The conflict comes about when you start assuming the data has acceptable levels of trust requirements for a given customer. The fact is, you can't speak for my trust levels, which is exactly what is being discussed in the link.

I get to say what trust levels I want for my software and data. Not being able to use the software because I can't trust it is an unacceptable proposition, so I challenge our abilities to build something better than what we have today, and do so without rationalizing why we aren't building it.

◧◩◪
7. redbla+Pb1[view] [source] [discussion] 2016-01-07 03:58:34
>>zAy0Lf+Zo
> There isn't anything inherent in running your own hardware that requires that to be a major burden.

Sure there is. Climate control, redundancy/backups, and power consumption/reliability, to name a few, are all concerns that we get to delegate to "the cloud," that are 100% "inherent in running your own hardware."

I applaud your usability argument, but there are most certainly inherent burdens to running your own hardware that don't exist for cloud services.

replies(1): >>zAy0Lf+kd1
◧◩◪◨
8. zAy0Lf+kd1[view] [source] [discussion] 2016-01-07 04:25:18
>>redbla+Pb1
> Climate control

A 10 watt server doesn't need climate control.

> redundancy

Is mostly a matter of software.

> backups

Is also mostly a matter of software. With some simple peering mechanism, you can store backups on your friends' servers (and they on yours). Though a standardized pure backup storage API for cloud storage of encrypted backups at one (or more) of a multitude of providers might be a useful option to have.

> power consumption

Is a matter of plugging a plug into a socket in the wall.

> reliability

Is also mostly a matter of software.

Now, I am not saying that running your own datacenter is no work, but running a server or two for your personal needs or for the needs of a small company should be possible to make almost a no-brainer.

There is no technical reason why you shouldn't be able to buy a bunch of off-the-shelf mini-servers for a hundred bucks or so a piece that you can peer by connecting them with an ethernet or USB cable or whatever might be appropriate and that you then connect to the internet wherever you like and that automatically replicate their data among each other and allow easy installation of additional services via a web interface, with automatic software upgrades, and allow you to rebuild the state of a broken server by connecting a new one and clicking on a few buttons in the web interface ... well, there are many ways to solve the details, but my point is: cloud providers also don't employ one admin per machine, but rather automate the management of their machines to make things efficient--there isn't really any reason why much of the same automation strategies (which are mostly software, after all) shouldn't be usable on decentralized servers in people's homes.

[go to top]