And yet they are a long way off. Banks will reject them doing it.
“IE SWAT team invades troon’s office before the network is live.”, that is the issue I referred to. Try court action first up.
Also its not banning encryption that is being legislated, but that companies are to let the spooks have access to unencrypted data. (actually assist the spooks in reading the data stored/transmitted by the companies.) That is why the banks are not up in arms over this, because it means no change for them. The banks unbreakable encryption remains because the spooks can access unencrypted data at the servers.
The problem for the legislation for open source projects such as this is that they can only require that the company writes in a back door. Then its a simple matter for the open source company to either move or stop. There is no SWAT or other physical threat.
One big threat to the SAFE network is that few end users will pay to store data and few companies, who usually are used to pay for information technology, would pay for, or even use, new open source storage solutions. Sure, if the SAFE network becomes really big then companies may start to use it, but the question is if there will be enough network effect to make the network really big to begin with.
As a comparison: Try to launch a secure email service and see how many people would use it if they have to pay to use it. Even if you make the service free you will find it very hard to compete with Gmail etc. Changing people’s habits is tough especially if the existing services are superior in many ways which is often the case in comparison to new promising yet immature technologies.
The ability to delete data is difficult to support because of the way chunks are stored (for security and de-duplication) - there have been discussions of why this is the case, and whether or not this is a problem.
An alternative to deleting data is to expire it unless paid for. This suffers the same technical problems I think, but there is a theoretical post about it which you might be interested in just started here:
chunks/files are written once and updates write new chunks and update datamap. This means you can keep each version of your file. Public/private data cannot be changed, so if you have a datamap for a public file/program stored then you can be assured that it cannot be tampered with.
You PUT data to the SD, it costs the same as a PUT of a chunk.
I have yet to read up on the precise details on the security. I do not see any reason that the controls will not be reasonable considering the effort that has gone into the rest of the network design.
There is no security risk because the rewritten SD must be signed by the previous owner or the absolute majority of previous owners when there are several of them (>50% of previous owners).
Privacy and ownership are two independent functionalities of SDs:
As SD owner, you and only you can modify the SD
You generate a private SD by providing an encryption key to the SD. In this case only you and the people with which you shared the private part of the key will be able to decrypt the SD.
“Technically the “owner” does not own the chunks. Rather they had been given a datamap which is stored by their client. This removes the connection between client and chunks so no amount of tracking can identify the owner.”