Example workflow:
- write a blogpost
- build a canonical representation based on a simple HTML or XML template; including canonical URL, title, content, authorship (emails, social media URLs, etc.), optionally related multimedia in a Zip archive, perhaps inlined via data URL
- alternatively, re-purpose a common Web scrapping format, like the one used by Firefox, for canonical representation
- submit the canonical representation for timestamping [2]
- provide a <meta name="publication-timestamp" value="canonical representation url"> in the document as published, to facilitate automatic and manual verification
- upon dispute, provide the canonical representation and verify in the relevant timestamping services
[1] for example http://opentimestamps.org/
[2] from experience, the processing takes under 30 minutes with OpenTimeStamps
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.
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.
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/, 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.
EDIT: Or as to the example above: whatever application is responsible for picking the main article to show somewhere.
> Our crawl process is algorithmic: computer programs determine how often we should crawl each site. If you post new articles on your site throughout the day, you should be able to see them appear on Google News fairly quickly.
> [...]
> From the moment we discover a new article, we'll keep re-crawling it looking for changes. Since we noticed that most changes to articles occur just after they're published, we revisit articles most frequently in the first day after we've found them. After that, we visit them less often.
https://support.google.com/news/publisher-center/answer/4039...
I am not sure if Google uses this to prove which is the original copy. Most website owners don’t know this exists. So it’s hard to use it as proof of the original, because the original creator may not even use the tool.
However, if everyone started to submit key articles, then it theoretically could compare the two fetches and decide which is earlier. It could be automated too with sitemap uploads as you post content.
Moreover, you could then use this as evidence in a DMCA take down that your copy is the earliest. Anyways, there are ways to prove earliest content.
The problem is akin to standing in a crowd where some people hold a sign with their age on it and others do not hold a sign, then trying to verify the age of an arbitrary people.
edit: unless the content itself contains a proof like the latest block hash or something like that, but that could be edited
Every time I write a blog post, I submit manually via webmaster tools "Fetch as Google" so that it gets indexed immediately. That way, the date google shows matches the date I published the article.
Content creators signing their content with a private key would be a better idea.
How would that help? Wouldn't the copier simply sign with their own key?
Maybe Google should run a timestamping service. It could be stateless: send an hash of the content, get it back timestamped and signed, then include it in the page before publishing it.
- create signature
- post signature, possibly publicly, (wow, maybe an actual use for a blockchain)
- post content
Anybody copying it could be proven to be a copyist.
Actually secure timestamping is already used by Windows to verify software signatures, even when the signing key expires: https://security.stackexchange.com/questions/47289/how-is-an...
Heck, you can even use Roughtime [0] to achieve secure timestamping as it uses digital signatures and allows you to provide a nonce. Even the design doc [1] mentions this use case:
> This means that Roughtime replies can be used as a time-stamping service, and thus that Roughtime servers can be used to check each other.