Re: Standardizing Firefox's Implementation of Link Fingerprints

[Keith Moore <[e-mail]>]

great idea in principle, but somehow, using fragment identifiers for
this seems like it's incompatible with the normal use of fragment
identifiers.  I guess I see little danger that these will collide with
"real" fragment IDs, but somewhat more danger that a browser or other
parser will look at a document containing such URIs and do something
reasonable with it.

> For Firefox 3, there are patches [1] that implement Link Fingerprints,
> which provide automatic resource verification for URIs that look like
> http://site.com/file#hash(sha256:abc123) so that link providers can be
> sure that end users download the exact file that the provider intended
> (and not a trojaned download).
>
> The fragment identifier portion of the URI is used for backwards
> compatibility with existing clients while allowing for extended usage
> across protocols (e.g., http, ftp) and resource contexts (e.g., a
> href, img src). Additionally, fragment identifiers are not sent as
> part of a HTTP request, so the network and servers do not need to be
> changed. With the backwards compatibility, incremental deployment is
> feasible with some clients supporting Link Fingerprints, and end users
> don't need to do anything unless there's a fingerprint failure.
>
> An initial draft to standardize Link Fingerprints is available online..
>
> https://people.mozilla.com/~edilee/draft-lee-uri-linkfingerprints-00.txt
>
> Feedback is welcome about the design, syntax, supported hashes,
> failure cases, etc.
>
> Ed
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=377245
>
>