[whatwg] whatwg Digest, Vol 82, Issue 10

[Glenn Maynard]

On Tue, Jan 4, 2011 at 4:59 PM, Seth Brown <learc83 at gmail.com> wrote:
> When you download and run a program you are placing the same level of
> trust in a website (unless it the program is also distributed by an
> additional trusted site and you can verify the one you have is the
> same) as you would when allowing them to access one of your devices.
>
> Therefore, device element access should require the same level of
> confirmation as installing a downloaded program.
>
> That being said. Granting access to a particular script instead of an
> entire site sounds like a reasonable security requirement to me. As
> does using a hash to verify that the script you granted permission to
> hasn't changed.

The issue of handling elevated permissions for scripts is a difficult
one, and I don't have a complete answer either, but re-confirming
every time the slightest change is made server-side is no solution.
Users aren't diffing scripts and verifying changes to see whether they
want to continue to grant permission.  Users aren't developers, and
most developers won't waste their time doing that, either (never mind
the issue of obfuscated Javascript code).

This would have exactly the same result as Vista's horrible UAC
mechanism: not only asking the user to confirm something he can't be
expected to understand, but asking in a constant, never-ending stream,
to the point where users either click "yes" without reading, or figure
out how to disable the prompt entirely (the worst end result possible,
if it causes a permissive default).

At some point, I do strongly believe that web apps should be able to
request elevated permission.  Many tasks that are still the domain of
native applications are stuck that way only because of security issues
like this, not because of any technical limitations of HTML or
Javascript.  This won't change without a reasonable security
mechanism--but asking the user every time a script changes is not an
answer.

-- 
Glenn Maynard