[liberationtech] secure download tool - doesn't exist?!?

[Owen Barton]

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 <uecker at eecs.berkeley.edu>wrote:

>
> Jacob Appelbaum <jacob at appelbaum.net> 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 companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>



-- 
Owen Barton, CivicActions, Inc.
cell: 805-699-6099, skype/irc: grugnog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130701/13766be5/attachment.html>