This is roughly what I was suggesting with the http header (fetching the hash with a TLS HEAD request even if the download itself is not TLS). I think this may be preferable to encoding the hash with the link, as it would work even with 3rd party links.
Getting support in the browser or OS is critical, I agree - apart from the convenience factor, installing a secondary "secure download" tool is a catch 22 for the user. - O On Mon, Jul 1, 2013 at 4:22 PM, Martin Uecker <[email protected]>wrote: > > Jacob Appelbaum <[email protected]> wrote: > > ... > > > We need a secure downloading tool, we need it to be built into every OS > > by default and until then, we'll have to rely on tricks to hack it - > > preloading certs in browsers, having a website to download it from and > > so on. > > > > What we need are backwards compatible self-certifying URLs or hyperlinks, > e.g. something like this: > > <a href="./mysoftware.tgz" > hmac="sha1:da19d18ef86f4fb8fe8b61323806ec1764f9bf00">My software</a> > <a > href="./mysoftware.tgz#sha1:da19d18ef86f4fb8fe8b61323806ec1764f9bf00">My > software</a> > > And something similar to specify a public key. > > This would need to be standardized and supported by all major browsers. > > Martin > > > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at [email protected] or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech > -- Owen Barton, CivicActions, Inc. cell: 805-699-6099, skype/irc: grugnog
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
