[whatwg] Proposal for a web application descriptor

Bjartur Thorlacius svartman95 at gmail.com
Wed May 4 15:12:06 PDT 2011


On 5/3/11, Cameron Heavon-Jones <cmhjones at gmail.com> wrote:
> I would agree a command-level authorization is a better default, if only
> because it is necessary to have this level of granularity available.
>
Agreed.

> The quantity of permission requests can be managed in an effective manner by
> the agent allowing the user to store their preferences for the next command
> or as a universal setting.
>
If you manage to inform users that they'd then be authorizing for
every purpose, usually without notice, not just for obeying the
previous command.

> This is similar to what firefox does for launching unknown file types,
> session restore, or lots of other functions, although it would be in the
> context of a web application itself.
>
How so?

> [snip stuff I completely agree with]

> For web applications to specify their required permissions would seem to
> introduce a duplication of specification. If a web application includes an
> image file upload which the user chooses to capture from webcam, first how
> is the application to know that the user would use a web cam? and second
It isn't to know, nor to care. It receives an image, not a camera.
> what additional information is being specified in the permissions descriptor
> which wasn't already deductible from the inclusion of a file upload? This
> would additionally impose the scenario where applications include the use of
> some restricted system resource but fail to document the use in their
> descriptor, not an insurmountable problem but it draws any usefulness into
> question.
>
Same problem as with Firefox on Android.

> There are a number of resources which are thought of having an 'application'
> scope which may make sense to be collated into a single manifest and with
> the ability for an agent to manage it as such.
>
Yeah, if a single entity edits and signs multiple resources, it's
unreasonable to trust one but not another.



More information about the whatwg mailing list