W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Security use cases for packaging

From: Michaela Merz <michaela.merz@hermetos.com>
Date: Fri, 30 Jan 2015 04:12:31 +0100
Message-ID: <54CAF69F.10306@hermetos.com>
To: public-webapps@w3.org

Pardon my french, but the whole idea is ridiculous. Web development is
fluid and flexible. While I most certainly understand the idea and the
need for secured loadable code (AFAIK I brought up this issue about 2
months ago), packaging and complicated signing is counter productive.
What about external scripts like jquery? Do I really need to download a
complete package because I fixed a stupid typo in one of the scripts?

Maybe I am completely on the wrong track here (please correct me if I
am) - but I think signed code should be handled completely different -
thus preserving the flexibility of the LAMP/Script environment as we
know it.

Michaela



On 01/30/2015 03:22 AM, Daniel Kahn Gillmor wrote:
> On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
>> A signed manifest-like package description that lists the hash and
>> location of every resource seems fine as long as all the resources are
>> downloaded and verified before running the app. Perhaps this kills
>> some of the performance benefits motivating packaging in the first
>> place. :(
> Why would you need to fetch all the pieces before running the app?
> Consider a manifest includes an integrity check covering resources X, Y,
> and Z, but X is the only bit of code that runs first, and Y and Z aren't
> loaded.
>
> If you can validate the manifest, then you know you only run X if you've
> verified the manifest and X's integrity.  If the user triggers an action
> that requires resource Y, then you fetch it but don't use it unless it
> matches the integrity check.
>
> (i haven't developed webapps myself for ages, and the idea of a signed
> webapp is relatively new to me, so feel free to explain any obvious part
> that i'm missing)
>
>         --dkg
Received on Friday, 30 January 2015 03:12:58 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC