RE: Standardizing Firefox's Implementation of Link Fingerprints

Interesting stuff, a few thoughts...

- RFC 2396 cited in the draft was obsoleted by RFC 3986.

- The definition of this behavior across "all" media types is a significant departure from the XPointer syntax registered for XML fragments, and does present some level of compatibility concern.

- The draft may benefit from a more explicit statement of the algorithm (for at least HTTP) that specifies the steps taken in the process of evaluation of the hash.  For HTTP, I'd imagine that this includes removing any HTTP Compression (gzip/deflate) and Transfer-Encoding, before hashing the resulting body?

- Does this mechanism permit use of the "hash fragment" alongside the Media-Type specific fragment (that is to say, can I have a hyperlink which contains both a Hash, and a HTML anchor ID)?

- What is the expected behavior of a user-agent when it follows a redirection that returns, for instance, a 404 page?  The hash will obviously not be valid at that point.

- In order for the hashing algorithm to be effective, the entire body must first be retrieved, correct?  This could significantly change the behavior of a user-agent rendering the response.

Thanks,

Eric Lawrence
Program Manager
Internet Explorer


-----Original Message-----
From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of Edward Lee
Sent: Monday, July 02, 2007 4:21 PM
To: ietf-http-wg@w3.org
Subject: Standardizing Firefox's Implementation of Link Fingerprints


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.

This is not the same as the Content-MD5 header because that hash is
generated by the server providing the file, while the Link Fingerprint
would be provided by the link provider. This is especially useful for
mirroring files, so that the centralized site providing links can be
kept more secure while less secure mirrors can host the file.

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

Received on Tuesday, 3 July 2007 00:53:47 UTC