Just because tests pass does not mean that they're testing the right thing to begin with. Reviewing tests is as important, if not even more important than reviewing code.
Is it not possible to create a non-repudiable archive of what a website served, when, entirely locally i.e. not relying on some third party site who might disappear or turn out to be unreliable?
Could you not in theory record the whole TLS transaction? Can it not be replayed later and re-verified?
Up until an old certificate leaks or is broken and you can fake anything "from back when it was valid", I guess.
I don't know, but archive sites could at least publish hashes of the content at archive time. This could be used to prove an archive wasn't tampered with later. I'm pretty underwhelmed by the Wayback Machine (archive.org), it's no better technically than archive.today.
How do you ensure the tampered content isn’t re-hashed? Usually if you’re saving the hash in advance, you can save the whole archived page. Otherwise, you can use a regular archive service then hash the archived page yourself.
The only way I know to ensure an archive isn’t tampered is to re-archive it. If you sent a site to archive.today, archive.org, megalodon.jp, and ghostarchive.org, it’s unlikely that all will be tampered in the same way.
A list of hashes (tuple of [hashed url+date metadata, hashed content]) takes much less disk space than the archive contents themselves. Archive websites could publish the list for all their content so it can be compared against in the future. People would save copies of the list. If you didn't store the list yourself ahead of time, and don't trust a third-party to be "the source of truth", the archive could've uploaded the hashes to the blockchain at archive time:
Unfortunately you can't usefully replay TLS and be able to validate it, so no that does not work. Best strategy would probably be a public transparency log, but websites are pretty variable and dynamic so this would be unlikely to work for many.
The 10k-foot view is that you pick the random numbers involved in the TLS handshake in a deterministic way, much like how zk proofs use the Fiat-Shamir transform. In other words, instead of using true randomness, you use some hash of the transcript of the handshake so far (sort of). Since TLS doesn't do client authentication the DH exchange involves randomness from the client.
For all the blockchain haters out there: cryptocurrency is the reason this technology exists. Be thankful.
> The accident occurred near Atocha station, on a curve where signage indicates a speed limit of 45 kilometers per hour. However, sources consulted by this newspaper assert that the train, out of control, easily approached speeds of 90 to 100 kilometers per hour, ultimately resulting in the derailment. [...] Two mechanics who were inside the wrecked train escaped injury.
Any indication they deliberately derailed the train?
No, I mean adding a "use your location" button yourself which the user has to click before it uses the geolocation API, rather than just blindly requesting it on page load.
The only reason people block it in settings is because they get sick of nagging prompts they never asked for.
Ah, gotcha. So this change is giving developers a more standardised way to follow that "add a button, pop up permission dialog" pattern that will hopefully drive more of them away from the bad pattern?
reply