3 ms·

This could be solved with cryptographic timestamps [1]. The current generation of tooling is a bit raw - cli utility and Python library - but fully usable on th

• gambler 8y ago
  I agree that we need cryptographic timestamps. Seems like this would be a good use for blockchain, but any implementation would be better than nothing, as long as it's not fully centralized. The proposed workflow seems overly complex, though. For authorship verification all you need is ability to submit a block of text and receive a signed timestamp. Input: text Output: timestamp + signature Verification input: text + timestamp + signature. The simpler it is, the more universally it will be used. It should not 20 minutes either. The crypto involved should be pretty trivial. Any metadata could be built into the text itself as comments or hidden fields. However, this will not verify the URL the data is coming from, which might be desirable. The second kind of service could be verifiable archival service. Input: URL. Output: page content after rendering + timestamp + signature. Verification input: text + timestamp + signature. The service stores: timestamp + signature. This could be used to verify that at time X URL Y contained text Z. It doesn't matter whether the text is dynamic and go change later, since you could keep original page content.
  • dexen 8y ago
    > It should not [take?] 20 minutes either. Fair enough; the tech I know and mentioned (OpenTimestamps) is tied indirectly to Bitcoin's blockchain confirmation speed, thus both slow-ish, and also probabilistic rather than guaranteed. On the other hand, it gives good assurance that the tool will be around for a long time, and able to survive any single service provider's failure. > The crypto involved should be pretty trivial. Depends on the requirements. The tech I know and use (OTS) is privacy-conscious and handles timestamping of documents without revealing their actual content. Instead you submit hash(hash(document) + random, private IV) [1], which provides for both anonymous use, and ability to keep the signed content private, as the signed hash cannot be directly tied to any plaintext. This isn't strictly necessary for publicly-posted web pages, but certainly is useful for private documents, security-sensitive documents, etc. All in all, it's a starting point. Another possible approach would be to standardize submission to, and verification through a service like https://archive.is/ https://archive.is/, but that puts all trust into one 3rd party. > Input: [plain]text Directly timestamping the plaintext fails badly if the timestamping service provider is dishonest and creates an earlier timestamp for the content in their name, only to turn around and accuse the author of stealing the content. Or - a slightly paranoid scenario, but probably warranted in the post-Snowden era - if a whistleblower tries to timestamp some materials before distribution, but the timestamping service provider's filters catch the document and instead alert the government. Ergo, I'd prefer a blind timestamp, with the ability to reveal at the discretion of the author or whistleblower, even at the cost of more complex workflow. [1] sadly this means the author needs to keep a file containing the IV and a bit of other metadata.
    • gambler 8y ago
      All good points, although there are some arguments that can be made in favor of more straightforward protocol even if it's less secure. I agree that submitting plain text could be problematic for some use cases. At the same time, there are some cool things you could do with plain text, like using the same mechanics for content-addressable content.
• thinkmassive 8y ago
  Another option could use TLSNotary to verify the content at time of publication, built into the CMS/publishing platform https://tlsnotary.org/ https://tlsnotary.org/