Hacker News Reader

Comment by hobofan | Hacker News Reader

The points in that article are completely irrelevant and inconsequential.

You can "delete" things in an append-only ledger, in the sense that you can update the state with e.g. a tombstone marker.

On a higher level you can't delete things anyways, because as soon as you has shared them with a third party the control is out of your hands anyways. Just because current social networks try to hold up that facade doesn't make it a reality.

Sure you could make tombstoning past messages and making their contents inaccessible a more central feature, but there is nothing inherently wrong with append-only social networks.

View on HN

> because as soon as you has shared them with a third party the control is out of your hands anyways.

If I delete something from FaceBook, there's no way anyone (other than FB) can prove that I have said the things I deleted. With a signed append-only log, you'll have to disown your entire log and your keys. This is the problem.

Solution: sign every log entry with its own key. To repudiate an entry, publish the private key you used to sign it. But of course, it needs to be baked in the protocol from the start.

A: Why did you say X?

B: You can't prove that I said X! Here's where I published private key used to sign that message.

A: Do you normally publish the private keys of your messages?

B: No

A: Okay, while I agree I do not have cryptographic proof that you said X, I think it's extremely likely that you said X and then later attempted to retract it by publishing the private key. So I'm going to go ahead and act as if you said X.

Another problem with that; time. You publish the key after you sign and post the message in question. It's tough to prove 100% but you're only really invalidating posts from after the date you publish the private key.

It also doesn't solve another part of the problem with append-only, accidental oversharing. Even if we take this 'publish the keys' process as actually working the data is still out there so if you publish info you shouldn't like locations or PII it's always out there.

> the data is still out there so if you publish info you shouldn't like locations or PII it's always out there

That's true no matter what, purely by virtue of being shared with others.

Solution: publish every private key after, say, one week.

I believe there are point-to-point protocols that publish every private key after the recipient receives the message, but I don't see how it generalizes to publish-subscribe.

OK can you explain to me the interest of using private keys if you publish them afterwards??

I'm missing something..

They attest you are the author between the publication of the message (and of the public key) and the publication of the private key.

The recipient knows you sent the message, because they received it before you published the key. Nobody can prove you sent the message, because they received it after you published the key, and even if they did receive it earlier, they can't prove it in court.

That's why the key should be published as soon as possible. In a point-to-point protocol, it would be published as soon as the recipient confirms receipt of the message. That's why I'm not sure how it generalizes to group chat protocols.

Many well known archiving sites will attest that you made the post after it's deleted. If they don't, then random trustworthy individuals can do so instead.

> On a higher level you can't delete things anyways, because as soon as you has shared them with a third party the control is out of your hands anyways

Most things are readily forgotten once removed. No one cares enough about someone like me to keep a public archive of everything I've ever posted anywhere.

The archive exists, it's just not public.

That's of little consequence if what I'm worried about is prospective employers googling my party pictures.

Just because it's inconvenient enough for employers to check that they currently don't doesn't mean that it will stay that way. Digital archives generally get easier to access over time.

Why would you post your party pictures under the same name you apply for a job, and to everyone on the internet? Maybe those two should be separate?

Probably should but in practice won't be for most people. The people who have party pictures that are wild enough to be a problem are probably even less likely to evaluate the probable threat landscape for the next decade or two before posting. It's nice to be able to easily fix things like that after the fact, at least in most cases.

What I meant was that maybe we should discourage everyone to be “one person” online and rather encourage using multiple different identities and especially not posting party pics (or anything personal) under real names.

Maybe we shouldn’t use real names at all on the web.

Yes, and the same thing applies for tombstones implemented by revoked decryption keys on an append-only log.

>No one cares enough about someone like me to keep a public archive of everything I've ever posted anywhere.

Caches and archiving sites do exactly this.

> You can "delete" things in an append-only ledger, in the sense that you can update the state with e.g. a tombstone marker.

Since when is deleting the same as marking deleted?! I have a piece of rubbish on my desk, so I'll just mark it in my head to throw it in the bin, and done?!

A Tombstone in a signed log is not the same as "marking an entry as deleted", it's replacing an entry with something that contains enough data to maintain log integrity. E.g. "this tombstone replaces an object that had the hash XYZ".

The problem that remains is that for everyone who doesn't follow the tombstoning request and keeps the old value, they can still "prove" that what they claim was the original value is correct because its signed, unless you do more complex stuff with non-repudiation constructions etc.

> it's replacing an entry

That's the part that's not possible with an append-only ledger.

Reply on news.ycombinator.com