- From: Yan Zhu <yzhu@yahoo-inc.com>
- Date: Fri, 30 Jan 2015 06:50:43 +0000 (UTC)
- To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 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>
On Thursday, January 29, 2015 6:25 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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. Say that resource Y is a javascript file that listens for users typing in password fields and shows them a warning if the password is weak. The user verifies and loads the HTML page that includes Y but an attacker then blocks the request to fetch Y, so the user picks a weak password. My intuition is that most developers think about the security of their app as a whole, not the security of their app minus any-given-subset-of-resources.
Received on Friday, 30 January 2015 06:51:34 UTC