Ok, but is this in plans? It’s not only about me trying to cirmumvent the current design, but about having a platform where people can collaborate and limit the damage of the less skillfull collaborators (or clients of the team etc.) can do.
One more thing about hiding the public data, and then I’ll stop The reason why I’m arguing is that it is very different to have something that everybody knows being held in public or not. While in general it is good idea to make that kind of things public, that is not always the case. For example, as a young kid I sometimes participated in bullying. Once I invented a clever way to mock a boy. I invented a kind of “riddle” that was very catchy and allowed some creativity for anyone willing to bully this other kid. I regret it deeply now, and regretted it already back then soon after releasing it, as I saw what it did. I cannot take it back, but I have made a decision not to tell it anymore to anyone - in order to try to save him from having to face it ever again. For example, I’m not going to tell it here, even though the chances for the damage to spread from here to him are very slight. I see this comparable to the situation, where the way of bullying would have been publishing of a photo, for example. Everyone has seen it, but it is still different, if it can bee hidden from public. Even if everyone has copied it to themselves, it is still different from having it public.
But that isn’t going to happen with many forums and their replies and many blog entries.
The ID used to post will be taken as the ID.
Then I can fake that.
Yes you could take further steps to make the person sign each reply, but will the APPs do that step?
BUT the real issue is as David mentioned the web sites. There has been no mention or requirement that each web page is crypto signed and you have potentially 10s of millions of people creating their web pages and I bet bet you that only a few smart ones will do it, and maybe 20% will use helper Apps that do it for them.
So the ownership of the web pages will be taken as the owner of the ADs that point to the web pages.
Thus ownership is very important.
Now if we do as David suggested and somehow FORCE this ownership info to be stored with the web page itself then it could be done. But there are holes in that so again the history of the ownership of the AD will play a critical role in PROVING the authenticity of all those web pages and some/many blogs and forum replies using forum software that doesn’t FORCE crypto signatures on each reply.
Moving from MD to AD, rather than a change, seems to be the confirmation of the fact that never existed a real deletion option on MDs. The truth is that it doesn’t surprise me because everything indicated that the Devs tended inexorably towards the immutability of the data.
I wait for the RFC to see how the data is defined but it is also true that it opens very interesting options to advance towards a Strong Eventual Consistency model.
The discussion about AD has relegated other news, tremendously important, such as the change to BLS signatures, which can place the network at another level, and the solution to make Parsec truly asynchronous. I am very happy to see Andreas collaborate again, even temporarily, with Maidsafe. The truth is that I was following his work in POA, via Github, and I was always wondering if part of this work, in implementing Honey Badger, could not be used also in Parsec.
Just to expand a little on the Safecoin privacy/anonymity discussion, with the current proposal for the user experience.
In case it isn’t clear: all Safecoin transactions are private i.e. there is no public ledger, or list of entries. When I trade a Safecoin, I send it to a wallet address, and the receiver can see the address it came from—but no-one else.
As a SAFE Network user, I have a few options:
I can directly associate a wallet with my real identity via a (human readable) WebID.
I can associate a wallet with a pseudonym, via a WebID. Remember, I can have as many wallets and WebIDs as I like.
I generate a re-usable wallet address. This would be pseudonymous, but could become associated with my real identity depending on my pattern of use.
I can generate a single-use wallet address, which as the name suggests, could only be used once, for a single transaction. It cannot be associated with a WebID.
Option 1 is likely to be the predominant use-case (although not the default) as in most cases, financial transactions are far more useful is the send/receiver are easily identified to each other.
Option 3 is likely to be the default—liking a wallet address to one of your identities via a WebID would be an intentional opt-in function.
Option 4 would be the most anonymous option. I say “most anonymous” as anonymity, in reality, comes in degrees—It could be rightly argued that it is still pseudonymity. But the practical case for fully anonymous transactions (an Option 5), where the recipient is only aware that their balance has increased and the sender is unable to keep a record of where they sent funds, is limited, and difficult to achieve. We may get there (and I have argued the case) but in the first instance these four options will still be a huge benefit.
In practice unmasking could happen in Option 4 by having your account compromised (like a rubber hose attack shudders) or via some elaborate honey pot. And with the later, a fully anonymous Option 5 wouldn’t help, as the honey pot could be tailored to that scenario, or your device could be compromised with a key logger or some-such.
Perhaps this Safecoin related discussion could even do with its own thread. Might make things easier to follow, and contribute to without getting lost.
Once again it depends on if the owner ID of the AD is considered to be a part of history that needs to be kept. If history of the owner of the AD is kept then your above analysis has to be changed.
Granted an exception could be made for the safecoin tag type and probably would be, so then your analysis is correct and agrees with what we always believed.
Perpetual data requires the owner of the data is known for what I hope is obvious reasons.
Now the only solution given by others is to embed the ownership of the data within the data itself, but that is as bad as security by obscurity. And it won’t happen enough to consider it happening much at all.
So then we are left with the obvious and that is keep a history of owner of the AD along with the AD history.
Thus for the obvious correct operations of safecoin (as outlined by yourself) safecoin will need to have an exception of the history of ownership. Not a bad idea anyhow since safecoin will have to be treated differently in the processing anyhow.
I don’t think there is any intention of associating an owner with a Safecoin by default, it would only be via a user expressly and intentionally associating a wallet address with a WebID.
Missed what I was saying. I agree there is no intent.
BUT if the general case of ADs require a history of AD ownership to be kept in order not to break data perpetually then an exception for safecoin will have to be made.
And my years of data mining inform me that ownership of the the data object itself is essential for data perpetually. Especially in the context of the fundamentals of the SAFE network (you know truth which includes who originated what)
If you read above David said for that all data has to be considered public since it could be made public at any time and the data perpetually would have to apply to all data.
So all I am saying is that safecoin will have to be the exception if history of ownership is kept in general.
Not important, but why is this attack called ‘Rubber-hose’. ‘Torture’- or ‘coercion’-attack was probably too simple. Or is it because a rubber hose is a versatile tool for such things.
This well known picture also makes clear what is meant with the attack:
what are the requirements to run safe? like a few MB RAM/HDD?
for privacy: just do as encrypted swaps on linux (1. get the encryption key from an RNG 2. mount an encrypted filesystem as the swap partition 3. “forget” the encryption key on shutdown, or in this case whenever you want, eg logout)
So much of this debate revolves around “we can’t delete data because in order to do that, data must be linked to an owner”. That doesn’t need to be the case though does it? If data is marked as “deletable” we know we can’t “trust” it in perpetuity. However, with the deletable tag and a zero knowledge proof where only the owner has the proof answers, it could be deletable correct? The actual data, not just the map, then you can delete things even if shared with other users.
After writing this, now I’m wondering if this messes with deduplication. I guess that’s the next snag?
Yeah, if we use a “perfect” encryption that is absolutely bug-free and can’t be broken ever (quantum computing).
also how would “DNS” work with AD? With MD you we could hash the name, then use the hash as the network id for the MD.
Maybe it should be hidable at the app level then? Facebook is also not deleting anything you post, they just hide it from you. (at least that one copy, anyone else could just upload their copy of that image)
How is this possible, SD is content-addressable, so there’s no way to publish different content at the same ID?
I would just store the pointer to the newest version of the A(L)D at that time, so it would need to iterate just from that version to the current version, also it would be following the A(L)D links, so no real data would need to be processed.
It would even work with ID only for the data structure it self, by storing it as a DAG (git is doing that).
Yeah, if some one else would download “your” data and upload it as “his” data, then that date would get deduplicated (as in content-addressable data, the hash of the data is it’s id). So that person would be added as a new owner.
a) if we impl the network that way, that an owner could delete his “owned” data, everyone could delete anything he wants, by downloading and reuploading that data, thus gaining the “ownership” over it
b) or we impl it that way, that all owners would need to agree on a delete (making public data non-removable, as the owners on such data would pile up pretty fast)
The following is probably not that easy or even possible. And probably already discussed in the past on this forum.
But anyway: what if stored chunks on the network could have a ‘deletable’ flag/field.
For each data chunk that you store on the Safe Network:
if chunk doesn’t exist yet:
if chunk of type ‘private’: set ‘deletable’ flag
if chunk of type ‘public’: don’t set ‘deletable’ flag
if chunk already exists: unset ‘deletable’ flag
And if you want to delete a file: go through all data chunks and only delete the ones where the ‘deletable’ flag is set.
Or something along these lines.
Edit: an owner field is probably necessary to prevent others to delete your private chunks.
In that case the presence (or being not empty) of an owner field can be the ‘deletable’ flag.
just merge the private/public type into one field deletable, and set it on the first upload as you like. Public data would get non-deletable pretty fast anyway. there is no private/public type in the network, it’s transparent to the vaults.
Just looping back on this. If we assume AD is mutable, then it will be more difficult to cache. With this in mind, it would probably be optimal for apps with lots of mutable data to create their own, single, custom index, rather than rely on AD. The rational being that downloading just one slow mutable index, followed by lots of fast immutable loads would be preferable to downloading lots of slow mutable indexes along with the same immutable data.
Keeping the number of mutable downloads to a minimal will surely be faster and more scalable.
I don’t disagree with you that Facebook still maintains that picture of you that you deleted of you passed out drunk. I specifically said that in my post. That wasn’t my point. My point was that the picture will still be addressable. It will still be out there viewable by the public. Someone could easily make another app that simply archives all changes to the “SAFEbook” app and displays all content without any hidden elements. Archiving the addressing is a lot cheaper than archiving the entire site and having to re-upload deleted content.
By not allowing the user to delete the actual data, the SAFE Network will take a huge PR hit right off the bat. Not being able to control ones own data is antithetical to freedom of the individual. One takes a risk when publishing something to a publicly viewable space that that may be copied and forever in the archives of some lonely basement dweller, or government intelligence agency. However, to the user, the illusion of control is still a great pull. One needs to feel like they have recourse if they mistakenly hit a wrong button or stop paying attention and accidentally upload something they intended to remain private. To remove that ability is to doom the network before it even starts. I can already hear the pundits blasting SAFE as a place where control of your data is no longer an option, regardless of what the truth actually is.
The reason why I’m arguing is that it is very different to have something that everybody knows being held in public or not. While in general it is good idea to make that kind of things public, that is not always the case. For example, as a young kid I sometimes participated in bullying. Once I invented a clever way to mock a boy. I invented a kind of “riddle” that was very catchy and allowed some creativity for anyone willing to bully this other kid. I regret it deeply now, and regretted it already back then soon after releasing it, as I saw what it did. I cannot take it back, but I have made a decision not to tell it anymore to anyone - in order to try to save him from having to face it ever again. For example, I’m not going to tell it here, even though the chances for the damage to spread from here to him are very slight. I see this comparable to the situation, where the way of bullying would have been publishing of a photo, for example. Everyone has seen it, but it is still different, if it can bee hidden from public. Even if everyone has copied it to themselves, it is still different from having it public.