On 04/05/2011, at 11:12 PM, Bjartur Thorlacius wrote: >> 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.
I meant that the authorization preferences would need to be stored on an application-by-application basis for it to make any sense. If a user authorizes an app to use a restricted resource, they could be prompted as to whether that resource should have access granted for future actions. There could also be the possibility of allowing - or at least being able to specify - authorization at a global level. Something like - grant all applications access to the webcam. Or in other words to remove any restrictions from a resource. >> 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? I see this behaviour in lots of desktop applications, not only for authorization requests but any kind of repeated confirmation dialog. In firefox the first time you close the browser it asks if you would like it to store the current session for restoration at next startup, this is always shown for a fresh install but the dialog has a checkbox for whether the user would like firefox to remember their preference and apply that preference without confirmation next time firefox shuts down. I also see this behaviour in Eclipse, which was one of the first desktop applications i was aware of to use this UI pattern. It is valuable as it maintains that the initial default should be to inform and ask the user what to do, but also makes it easy for the user to specify that they never want to be asked again. >> 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. Yes, i thought about this some more and i'm less certain of a direct need for a system-level (OS) resource authorization mechanism. Why would a user need to be asked if they want to use their own camera? If they have clicked on a file upload, the OS has displayed a file dialog box, then they have chosen to capture from webcam - why would they need to be asked if that was authorized? Since the command is from direct user action, and the dialog box is an OS user interface, where is the need for a user to confirm that what they're doing should be allowed? Web sites\Web applications are already isolated from the underlying OS and protected from directly accessing system resources. They operate under direct user action and not as demon processes so the user is always both the source of command and, of course, the authority for granting permission. So, without consideration for future APIs, what system-resource authorization is actually required by a web application? The main driver for this would seem to be access to a user's geo location. This is more a request for information, not really for resource access. It might be better to think about the problem specifically within this use-case and how it should be applied as i am unsure of any need for additional authorization mechanisms at present. >> 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. My personal opinion is that what this proposal really highlights the need for is a method of packaging or defining the scope and context of what a "Web Application" is and its boundaries within a URI space. Without this user agents will not have the context necessary to provide configuration and management of applications other than over an entire domain xor a single page. Thanks, Cameron Jones
