LWN: Comments on "Google Summer of Code: Mozilla Projects"

Google Summer of Code: Mozilla Projects

swiftone — Fri, 28 Sep 2007 13:40:26 +0000

I doubt sending the md5 alongside the file will make it really secure in case of trojaned file.

Correct. This would be of value when the source of the link is not the same as the source of the file.

LWN, for example, could post links to packages on ibiblio. On download, the files from one source (ibiblio) would be checked to match the hash from another (LWN).

At that point the system is as trusted as the source of the link, which can have errors, but may be more secure than the current system (where the hash is rarely verified).

jpeg2000

roelofs — Thu, 30 Aug 2007 04:39:24 +0000

There are probably *already* other formats better than jpeg2000, not including any developments in the next 13 years...

Hell, in my experience, regular JPEG is better than JPEG-2000, both quality-wise and size-wise, and what I found online (real users, not researchers or graphics-tools vendors) completely agreed with that assessment.

Of course, it could be that the encoders for images in question just sucked massively, but it seems odd that all of them should be so bad--particularly when they're being held up as examples of JPEG-2000's quality. If you like grass that looks like split-pea soup, OK, maybe JP2K is just what you're looking for...but I prefer to see the blades.

I'd love to hear about exceptions, preferably involving publicly available images (the JPEG-2000 and lossless versions, at a minimum; I can create my own JPEG-1991 [or whatever] images at arbitrary quality settings).

Greg

Google Summer of Code: Mozilla Projects

Wummel — Tue, 28 Aug 2007 09:40:07 +0000

> Perhaps the checksum should be sent along as a HTTP Response Header,

There is the ETag HTTP header defined. Though it seems the Etag value only gets used for cache validation, and not for content verification.

Link Fingerprints

bronson — Sun, 26 Aug 2007 22:50:23 +0000

Because that's not backward compatible. A browser that doesn't know how to check the hash won't be able to open the link.

Link Fingerprints

JohnNilsson — Sun, 26 Aug 2007 18:43:51 +0000

Why not just add a new scheme type for hash based data identifires

hash:[<hashtype>:]<hashcode>[@<uri>]

where @<uri> identifies a way to fetch the resource. If it is omitted the client could instead query any DHT.

jpeg2000

riddochc — Sun, 26 Aug 2007 00:31:29 +0000

...Assuming someone won't come up with something better and patent-free in the meantime. There are probably *already* other formats better than jpeg2000, not including any developments in the next 13 years...

Link Fingerprints

rfunk — Fri, 24 Aug 2007 16:47:52 +0000

Hmm, I don't like putting it in the query string, since that's considered reserved
for processing by the server. The other two are explicitly for client-side
processing.

Link Fingerprints

bronson — Fri, 24 Aug 2007 16:33:56 +0000

I agree 100%. IMO, best would be, as you say, to pass the hash in a separate attribute. Second best would be to put it in the query (http://mirror.com/file?sha256=abc123). But, changing the meaning of the fragment? That's just silly!

Let's say I want to send someone to a specific section, sec2, in a page on a remote site. Let's say further that I need to verify that the page is *exactly* what I was expecting.

<a href="http://mirror.com/a.html#sec2" hash="sha256:abc123"> -- attribute works
<a href="http://mirror.com/a.html?hash=sha256:abc123#sec2"> -- query works
<a href="http://mirror.com/a.html#sec2hash=sha256:abc123"> -- fragment fails!

Let's hope they give this some more thought...

Link Fingerprints

rfunk — Fri, 24 Aug 2007 13:26:41 +0000

I wonder if the link fingerprints concept might get a better reception if the hash
information were moved to another attribute of the HTML <a> tag.
So instead of this:
<a href="http://mirror.com/file#hash(sha256:abc123)">
we'd write this:
<a href="http://mirror.com/file" hash="sha256:abc123">

It would lose some of the functionality (harder to pass around links with intrinsic
hash information, but would still be useful.

jpeg2000

eru — Fri, 24 Aug 2007 07:59:59 +0000

I think jpeg2000 is DOA forever.

Since the lifetime of patents is just 20 years, it might see some use after 2020...

Google Summer of Code: Mozilla Projects

bronson — Thu, 23 Aug 2007 21:59:58 +0000

Nobody's using jpeg2000 because it's full of patent landmines. Nobody wants to be the first to get sued. Since the quality isn't THAT much better anyway, there's really no good reason to change.

Standards writers, let jpeg2000 be a lesson! If you don't spend enough time worrying about patents, all your work might be for naught.

Personally, I think jpeg2000 is DOA forever. I look forward to when png2000 gets developed though!

Google Summer of Code: Mozilla Projects

zooko — Thu, 23 Aug 2007 15:28:30 +0000

The idea of a link fingerprint (this is the first that I've heard of it), is an example of a self-authenticating identifier. I wrote an essay which made a lot of people aware of this concept:

https://zooko.com/distnames.html

Other examples are Freenet's content-hash-keys (CHKs), which are equivalent to link fingerprints, and Freenet's sub-space keys (SSKs), which are more flexible in that they allow the file being identified to change without changing the identifier. David Maziere's research on "the self-certifying file system" contained an equivalent to SSKs. Mark S. Miller's research on Pet Names was what inspired my "distnames" essay in the first place, and it contains the most complete proposal for making identifiers both secure and user-friendly:

http://www.skyhunter.com/marcs/petnames/IntroPetNames.html

Phil Zimmermann's Zfone secure phone includes a similar technique (due to my suggestion), called "Sticky Note Security".

My current free-software project, http://allmydata.org, contains equivalents to both CHKs and SSKs.

I'm very glad to hear about this project in Mozilla. The idea of using CHKs to denote immutable contents is long overdue -- we should have done this at the beginning of the web. Furthermore, the idea of using SSKs to denote mutable contents may be coming due, too.

--Zooko

Google Summer of Code: Mozilla Projects

xav — Thu, 23 Aug 2007 15:12:04 +0000

I doubt sending the md5 alongside the file will make it really secure in
case of trojaned file. A non-stupid cracker would modify the md5 as well a
the file (or, this would be done automatically if computed on-the-fly by
apache).
The advantage of md5 embedded in the webpage is that modifying the ISO and
modifying the HTML accordingly is hard.

Google Summer of Code: Mozilla Projects

jengelh — Thu, 23 Aug 2007 14:46:08 +0000

>Edward Lee's "Link Fingerprints" (mentored by Gervase Markham)

Perhaps the checksum should be sent along as a HTTP Response Header, though of course sourced from a static file, so as to not make Apache recalculate it every time.