- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 4 Jan 2011 17:20:01 -0500
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
Received on Tuesday, 4 January 2011 14:20:01 UTC