[whatwg] whatwg Digest, Vol 82, Issue 10

[Seth Brown]

I couldn't agree more that we should avoid turning this into vista's UAC.

Maybe developers could make changes infrequent enough that users
wouldn't be bothered very often? They could encapsulate the device
access logic into one .js file that shouldn't be regularly changed.

Another option is to set default security to list changes to scripts
with device access in the device access preferences pane. Allow a
higher security setting that would send alert popups to notify
changes.

You could also use a third party CA like entity to verify your scripts
(this option would naturally have to develop over time).

-Seth


On Tue, Jan 4, 2011 at 5:20 PM, Glenn Maynard <glenn at zewt.org> wrote:
> 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
>