Quote from: mikewoods on January 14, 2014, 06:10:20 AM

Each website could have meta tag like this...

I'm a little confused on this... If I'm a hacker and I compromise a site, wouldn't I just remove the meta tag so that verification is skipped?

It seems to me that if a browser-plugin solution were in place, the plugin could just have knowledge of which sites can be verified, irregardless of whether or not the sites had any particular meta tags in place.

I have a feeling I'm missing something here so feel free to expand.

Meanwhile, here's an expanded bit on my "portal" idea:

Anyone who wants their website to be checksummable submits three things to the portal project:

1) Name / Description / Purpose of project
2) URL for github landing page, e.g. https://github.com/pointbiz/bitaddress.org/
3) URL for published project, e.g. https://bitaddress.org

Somewhere in the github READ ME, the author must include a line that's formatted for scraping, something like this:

PUBLIC WEBSITE SHA1-HASH: 364542f1ccc5777c79aebb1692a6265cf3e42e7e

And I think that's it. Anytime they update the public site, they just need to be sure to update the READ ME file on github.

Meanwhile, the portal site wouldn't need updating at all. When invoked, the "portal" website would use PHP to pull off the latest READ ME for each project and scrape the PUBLIC WEBSITE SHA1-HASH, store it in a javascript array.

Then, when someone clicks "LAUNCH/VERIFY" for any of the listed websites, 1) The website opens in a new window/tab, and a moment later, 2) javascript uses the visitor's IP connection to pull down a duplicate copy of the HTML, run a SHA1 in javascript, and then display the "VERIFIED!" or "Uh oh, SHA1-HASH in READ ME doesn't match hash I just retrieved."

There's one bit of cleverness in here (if I do say so myself) is that we circumvent a smart hacker from modifying bitaddress.org in such a way that it serves up unadulterated HTML to IP addresses belonging to any particular user agent or IP.

However there's one detail I haven't solved yet.

If I'm a *really* smart hacker, what I'll do is modify bitaddress.org so that when I receive a request from any brand new IP address, I always serve up the hacked version. When I receive subsequent requests from the same IP (presumably for checksumming purposes) I always serve up the unhacked version so that I pass the test.

Even if I we randomize whether we use the first request to display the tab and the second request to do the checksum, or visa-versa, a hacker will still like the 50% odds of escaping detection.

The only semi-solution I can think of so far is that when a "Uh oh, hash doesn't match" situation arises, a button is displayed (or automatic redirect is fired) that allows the user's session to invoke a shut down / warning for that particular site on the portal. This would add a notice (maybe notify the developer!) that a mismatch has occurred. This way each person who uses the portal is volunteering their own computer/IP as a sentry to safeguard to warn other users. Maybe a three strikes and you're out thing where three mismatches in a 24 hour period unlists the website until a developer intervenes.