- From: Yan Zhu <yzhu@yahoo-inc.com>
- Date: Fri, 30 Jan 2015 01:14:59 +0000 (UTC)
- To: Ilya Grigorik <igrigorik@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: Chris Palmer <palmer@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
devdatta wrote: >> Maybe the code from the downloaded package has to be run from a local origin like chrome://*. > > Doesn't the same issue that Chris raised still exist? You need a unit > of isolation that says "only code signed with this public key runs in > this isolation compartment". Chrome extensions have that model. > Whether we achieve this via origins, COWLs, or origin+key as the > identifier, is a separate question, but Chris' high level bit remains true. thanks, I meant a unique local (pseudo-)origin assigned to the downloaded package. Chrome extensions derive it purely from the public signing key IIRC; seems like that would suffice here too. ilya wrote: > Would it be possible to meet the security goals without assuming that the response body is > part of the package? See [1] for background on why that's beneficial.. at least for performance > side of the story. I'm picturing a package description where each resource has a SRI token, > plus a signature to authenticate the tree of resources / package description itself? 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. :(
Received on Friday, 30 January 2015 01:16:07 UTC