- From: Chris Palmer <palmer@google.com>
- Date: Fri, 30 Jan 2015 11:26:22 -0800
- To: Yan Zhu <yzhu@yahoo-inc.com>
- Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Ilya Grigorik <igrigorik@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Jan 29, 2015 at 10:50 PM, Yan Zhu <yzhu@yahoo-inc.com> wrote:
> 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.
The application developer could cope with this in the top-layer code:
===
<script>
var passwordChecker = null;
...
</script>
<script src="password-checker.js"></script>
<script>
if (null == passwordChecker) {
// handle failure of security dependency
}
</script>
===
Just as a native application developer should do:
===
void* passwordChecker = dlopen("password-checker.so", ...);
if (NULL == passwordChecker) {
// handle failure of security dependency
}
===
But,
> 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.
You're probably right, about both web developers and native code developers.
But, if we provide a declarative interface for the package format that
allows developers to declare that a given dependency should be
pre-loaded when possible and mandatorily pre-loaded, they might be
more likely to use that than to write the tedious error-handling code
like that above. I.e. we can create good affordances, and thus get the
benefits of security and performance most of the time.
Received on Friday, 30 January 2015 19:26:50 UTC