February 16, 2006

Force Feedback

Filed under: digital — mhoye @ 10:13 am

This is a copy of a proposal I sent to the Web Hypertext Application Technology working group mailing list, which elicited some both positive and negative discussion, but didn’t get, I think, a lot of traction. I am not sure how I can market my idea better, if it’s a good idea and without basically nagging people. If you have any suggestions, for the thing itself or how I could sell it better if that’s worth doing, I’d love to hear them.

My proposal is for the addition of a “validate” attribute to the the <a>
element that would let the client verify the content of a link as it
comes in. The client can then put up a warning, present the user with a choice or just silently deny the incoming data depending on a preset user preference.

The validate attribute would describe an algorithm to employ and a result
to compare it to; for example, somebody downloading the en-US version
of FF 1.5 from the homepage could click on a link like:

<a href=”” validate=”{md5}b63fcdf4863e59c93d2a29df853b6046″>

and the client could verify as mozilla-i686.tgz comes in that it does at least have
the md5sum, or whatever algorithm goes there, that’s advertised.

User notifications could include “no validation”, “successfully
validated” and “(algorithm) validation failed”, and act according to the user’s
wishes in each case.
The user can be notified when validation fails, and choose whether or not to discard the download or press on. The user shouldn’t be notified when there’s no validation, because this is usually going to be the case, or when it succeeds, because most users will assume “validation” to equal “safe”.

Your use case for this is when a website relies volunteers to mirroring its files to ease their server load; if one of those volunteers decides to screw you and replaces your file with something malicious, users coming from the home site find out that it’s a bad download immediately, and can delete it without running or installing it.

If, or wherever, validates their own malware you’re still not protected, but if you were downloading stuff from you weren’t protected anyway, so I think it’s a pretty clear win.

Please let me know what you think.


  1. Sounds like it might be useful provided you didn’t include the “successfully validated” part. If it validates, then there should not be any message and it should behave like any normal download because you still either trust the site or you don’t. This is really only useful if the site doesn’t trust the people hosting the download, in which case it should only tell you when that is a problem. Otherwise it provides one more way for malicious sites to make it look like the thing you are downloading is benign. Only a small percentage of users would understand that validated != safe.

    Comment by Amos — February 16, 2006 @ 1:03 pm

  2. Good idea, change made. Thanks, Amos.

    Comment by Mike Hoye — February 16, 2006 @ 1:36 pm

  3. I like the main idea behind this, but some closer scrutiny brings out a few potential problems.

    The proposal is based on a statement of the form “site A asserts that the file linked to over here has property P”, where P is, in the given example, the expected MD5 hash of the file. So now we’ve got two problems: how do we verify the identity of site A, the certifier, and how do we store (and verify) the properties P about the file? The latter is far easier, so let’s tackle the former first.

    The proposal has the implicit assumption that the originator of the link asserts the guarantee, when in fact this is not necessarily the case: the link could have been worked into the page by a third-party mirroring service (I’m thinking, Coral Cache or the Google cache, here); a cross-site scripting hole could have allowed malicious code to change the link properties; compromised server-side includes could have allowed tainted data to be sent to the client; and of course there’s the ever-popular man-in-the-middle attack.

    There’s a popular and powerful way to deal with all of the above problems, though: digital signatures. What’s wrong with a bit of browser work being done to maintain a list of public keys? If encoded carefully, the embedded signature information could be just as useful to humans wanting to perform validation manually as to browsers doing so automatically.

    As for asserting properties about the file which, if not met, indicate that it has been tampered with, wouldn’t a signature suffice for that too? It might be kind of nice to assert other properties – MD5 hash, SHA1 hash, filesize, MIME type, timestamp (though the latter two are of course just meta-information, rather than information useful to confirm the validity of a file) – but that’s just a matter of choosing one of the billion of ways of marking up a list of key/value pairs. Hey, look, here’s yet another (and yes, I know that inline CSS is bad):

    <a href="..." rev="signed">[text of link]</a>
    <dl class="signed-validity" style="display:none;">
    <dd>[URL to public key of certifier A]</dd>
    <dd>[URL of link guaranteed by certifier A, same as HREF attribute of link above]</dd>
    <dt>validating sig"</dt>
    <dt>validating md5</dt>
    <dd>[md5 hash]</dd>
    <dt>validating sha1</dt>
    <dd>[sha1 hash]</dd>
    <dt>validating size</dt>
    <dd>[byte count]</dd>
    <dd>[ISO8601 timestamp]</dd>

    Only the first three properties – pubkey-url, target-url and sig – are actually necessary, of course. Thoughts?

    It’s much uglier and more time-consuming to do it this way. Your proposal is clean and cool. I don’t think that it conclusively solves the problem, though. Can you think of a way that combines the best of both worlds?

    Comment by Gnomon — February 17, 2006 @ 12:41 am

  4. The fundamental issue with me on this one is trust. How do I trust the “validate” bit? If I am Wile E. Haxor, and I have my file that’s nasty malicious, and pop the validate in there, everything to the browser will appear peachy. It offers some peace of mind if a repository file is overwritten, but if they’ve got the repository, there’s a good chance they’ve got the site as well.

    I think you’d need a method of storing the validation sigs in a trusted server, which is where ideas similar to using public key repositories to store that sig make sense.

    Or something babbly like that, anyways.

    Comment by kev — February 21, 2006 @ 4:56 pm

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress