Most active commenters
  • nikisweeting(6)
  • petertodd(3)

←back to thread

663 points nikisweeting | 11 comments | | HN request time: 1.137s | source | bottom

We've been pushing really hard over the last 6mo to develop this release. I'd love to hear feedback from people who've worked on big plugin systems in the past, or anyone who's tried our betas!
1. petertodd ◴[] No.41863256[source]
You really should add timestamping to ArchiveBox. The easiest way to do that would be via my OpenTimestamps protocol, https://opentimestamps.org It's open source and free to use, and uses Bitcoin for the actual timestamps. Users of it do not need to make Bitcoin transactions themselves as a set of community calendar servers do that for you. You also don't need a Bitcoin node to create an OTS timestamp, and you can validate an OTS timestamp without a Bitcoin node as well by trusting someone else to do that for you.

The big thing that ArchiveBox can't do, and the Internet Archive can, is attest to the accuracy of the archive. Being at least able to prove that the archive was created in the past, prior to there being a reason to tamper it, is the best we can realistically do with current cryptography. So it'd be really good if support for timestamping was added.

IIUC ArchiveBox is written in Python; OTS has a Python library that should work fine for you: https://github.com/opentimestamps/python-opentimestamps

replies(2): >>41863331 #>>41863419 #
2. nikisweeting ◴[] No.41863331[source]
We're going to add TLSNotary support for real cryptographic signing, see my comments below :)

Timestamping is also on my roadmap, definitely as a plugin (and likely paid) as it's more corporate users that really need it. We need to keep some of the really advanced attestation features paid to be able to support the rest of the business.

replies(2): >>41863370 #>>41865422 #
3. mikae1 ◴[] No.41863370[source]
Thanks for the box!

Any examples of other possible really advanced features that might go for-pay?

Is there any chance you will make current free features for-pay? That'd be rather off-putting for me as a home user.

replies(1): >>41863539 #
4. jasonfarnon ◴[] No.41863419[source]
I always wonder about this when someone gets in hot water based on something on the wayback machine and the person says the archive was tampered with. Can you elaborate on "prove that the archive was created in the past, prior to there being a reason to tamper it"? What exactly does opentimestamps certify?
replies(1): >>41863576 #
5. nikisweeting ◴[] No.41863539{3}[source]
No, everything currently free will stay free.

The paid stuff currently is:

- per-user permissions & groups

- audit logging

- auto CAPTCHA solving

- burner credential management for FB/Insta/Twitter/etc. w/ auto phone based account verification ability

- custom JS scripts for expanding comments, hiding pop ups, etc.

- managed hosting + support

Some of this stuff ^ is going to become free in upcoming releases, some will stay paid. What I decide to make free is mostly based on abuse potential and legal ramifications, I'd rather have a say in how the risky stuff is used so that it doesn't become a tool weaponized for botting.

replies(1): >>41866687 #
6. nikisweeting ◴[] No.41863576[source]
OpenTimestamps alone can not currently prove anything because TLS session keys are symmetric. The client can forge anything and attest to it falsely. Unless you 100% trust the archiver (in which case you can trust their timestamps), you need TLSNotary or another reputable third party in the loop as a bare minimum.

But more critically: currently the legal standard for evidence is... screenshots. We have a lot of educating work to do before the public understands the value of attestation and signing.

replies(1): >>41865405 #
7. petertodd ◴[] No.41865405{3}[source]
> OpenTimestamps alone can not currently prove anything because TLS session keys are symmetric.

Timestamps can prove that the data existed prior to there being a known reason to modify it. While that's not as good as direct signing, that's often still enough to be very useful. The statement that OTS "can not currently prove anything" is incorrect.

A really good example of this is the Hunter Biden email verification. I used OpenTimestamps to prove that the DKIM key that signed the email was in fact used by Google at the time, by providing a Google-signed email that had been timestamped years ago: https://github.com/robertdavidgraham/hunter-dkim/tree/main/o...

That's convincing evidence, because it's highly implausible that I would have been working to fake Hunter's emails years before they even came up as an election issue.

replies(1): >>41867133 #
8. petertodd ◴[] No.41865422[source]
> We're going to add TLSNotary support for real cryptographic signing, see my comments below :)

Last I checked TLSNotary requires a trusted third party. I would strongly suggest timestamping TLSNotary evidence, to be able to prove that evidence was created prior to any of these trusted third parties being compromised.

replies(1): >>41867122 #
9. mikae1 ◴[] No.41866687{4}[source]
Thanks for the clarification and thanks again for the great work!
10. nikisweeting ◴[] No.41867122{3}[source]
Of course, TLSNotary stuff would necessarily come with a whole ecosystem, including some sort of transparency log like certificate transparency logs, DNS record keeping, timestamping, etc.

But we'll start with the basics and work our way up to completeness.

11. nikisweeting ◴[] No.41867133{4}[source]
Ok, fair point, they prove that content existed at some point in time, which is useful sometimes. But I don't want people to over-rely on that as "good enough", we can do much better, it's too low a bar for a whole ecosystem of archiving to rely on when we now have a viable solution to fix it (TLSNotary or others).