Enhanced Permissions for Web Apps
Michael
When a user chooses to install a web application, we will want to give
it different permissions than we would grant to general web content.
To kick the conversation off, I offer two posts as starting points:
Jonas Sicking writes:
--------
Just a very quick brainstorm of privileges that we could give to
installed apps. There are three categories of features that I think
would be ok:
1. Things that use resources on the users computer such as disk space
and CPU
2. Things that if abused can "annoy" the user, but otherwise not cause
harm
3. Things that are slightly privacy sensitive or would allow
fingerprinting the user
These categories are in the order of how comfortable I am with
allowing them
Some things we could automatically grant:
* Limited or unlimited storage using IndexedDB and the app cache (we
only allow this after prompting for webpages)
* Replace context menus
* Check if they are installed as a protocol/content-type handler
* Capture mouse events even after the user releases mouse button
* Go fullscreen with fewer restrictions
* Get device info such as battery level/bandwidth
* Ability to run persistent workers
Some things that we might want to let an installed app do after
prompting the user:
* Register as a protocol handler
* Register as a content-type handler (double-click a .doc document on
the desktop and google docs opens)
/ Jonas
-----
Roc posted a good discussion of the issues surrounding permissions,
and how we might think about managing them intelligently, here:
http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html
With those posts in mind, I would ask:
What other permissions might we want to modify, or grant
automatically?
How do we think differently in a mobile app context (where Firefox is
probably running chromeless)?
How should the permission UX change if the user has taken the step of
installing an application?
Are there permissions that we would never grant to web content that we
would grant to an application? (either because of sensitivity, or
because asking for them would be too confusing or annoying)
-mh
Jonas Sicking
Some of the things that has come up lately but has been problematic because
of fingerprinting:
* access to spellcheck API which uses users addition to dictionary
* ability to get list of device capabilities like joysticks, camera
metadata, usb/bluetooth/nfc availability etc
> How do we think differently in a mobile app context (where Firefox is
> probably running chromeless)?
I can't think of a reason to treat mobile differently from desktop. I would
hope we can avoid that.
> How should the permission UX change if the user has taken the step of
> installing an application?
Don't know :-)
> Are there permissions that we would never grant to web content that we
> would grant to an application? (either because of sensitivity, or
> because asking for them would be too confusing or annoying)
I think so yes. For example sending and receiving phone calls and text
messages is extremely sensitive since there is a lot of incentive to trick
used into allowing it since the is easy money to be made using 900 numbers
and the like.
So here I would like to see the user first game the step to install the app
and then authorize it very explicitly.
There is likely other APIs like that.
/ Jonas
Asa Dotzler
Tabs, somewhere between "the Web" and "a downloaded app"? I think that
when a user makes an App Tab, they are signaling that the site or
service is more than just a bookmarked page. They're asking it to
persist and to be always available from the same location -- similar to
IE9's Taskbar pinned tabs.
I don't think App Tabs are going to go away any time soon and I don't
think they ought to. It's a nice light-weight way for a user to app-ify
in some small way, a website that doesn't necessarily even consider
itself an App. If App Tabs live on as we incorporate Web Apps, and if
App Tabs occupy a space somewhere between "the Web" and "an App" then
I'd like to see if we can make some better defaults for site permissions.
- A
Benjamin Smedberg
> 1. Things that use resources on the users computer such as disk space
> and CPU
> 2. Things that if abused can "annoy" the user, but otherwise not cause
> harm
> 3. Things that are slightly privacy sensitive or would allow
> fingerprinting the user
ability to interact with the OS cut/copy/paste system? Working with the
OS clipboard is one of the most-requested webapp features, but would
allow web apps to steal clipboard contents.
> * Replace context menus
I personally wouldn't mind allowing a web app to *extend* the standard
context menu, but I'm not sure I'm comfortable letting it *replace* the
context menu. But I agree with most of your analysis.
> Some things that we might want to let an installed app do after
> prompting the user:
> * Register as a protocol handler
> * Register as a content-type handler (double-click a .doc document on
> the desktop and google docs opens)
Will there be a way to restrict a "web app" from phoning home at all?
For example, we've been discussing writing which can display PDFs, and
also a web app epub reader. But in neither case would I ever want the
web app phoning home to tell its original website what I'm reading. Is
there a way to "download" one of these apps and then run it in a
null-principal sandbox?
I think this is a pretty fundamental problem with web apps as we've been
discussing them.
I also want to make sure that users who want to continue running web
apps in their browser (in an app tab or whatever) still have the ability
to do so and get some of the advantages of the advanced permissions that
we're developing.
I presume that even if you have a web app running in a non-browser
window that there will still be a minimum of chrome somewhere that lets
the user change preferences and permissions, and move the app back into
the browser if necessary?
Has there been discussion about page navigation in web apps? How do we
distinguish a window.open or target="_blank" which intends to stay part
of the web app from a URL navigation which is intended to open in the
default browser? How do we handle middle-click link opening?
--BDS
Asa Dotzler
> On 8/2/2011 5:54 PM, Michael wrote:
>> * Replace context menus
> I personally wouldn't mind allowing a web app to *extend* the standard
> context menu, but I'm not sure I'm comfortable letting it *replace* the
> context menu. But I agree with most of your analysis.
I thought we already allowed this. Or have I flipped the pref allowing
it? It's been a feature of the Web forever and taking it away or
restricting it as part of a relaxing of controls seems backwards.
- A
Asa Dotzler
> On 8/2/2011 5:54 PM, Michael wrote:
>> * Replace context menus
> I personally wouldn't mind allowing a web app to *extend* the standard
> context menu, but I'm not sure I'm comfortable letting it *replace* the
> context menu. But I agree with most of your analysis.
I thought we already allowed this. Or have I flipped the pref allowing
Dao
We have a pref for it and it defaults to allowing pages to suppress our
context menu. I flipped it -- it's always annoying when a site tries to
prevent me from accessing the content the way I want.
HTML5 provides a way for pages to extend the context menu. A Gecko
implementation is under way:
https://bugzilla.mozilla.org/show_bug.cgi?id=617528
Jonas Sicking
>
> On 8/2/2011 5:54 PM, Michael wrote:
>>
>> and CPU
>> 2. Things that if abused can "annoy" the user, but otherwise not cause
>> harm
>> 3. Things that are slightly privacy sensitive or would allow
>> fingerprinting the user
>
ability to interact with the OS cut/copy/paste system? Working with the OS
clipboard is one of the most-requested webapp features, but would allow web
apps to steal clipboard contents.
The ability to write to the clipboard is something I'd put in the "annoy"
category. Being able to read isn't something that I'd want to grant
automatically though. But something that would be ok to permanently grant
with a "doorhanger" dialog maybe.
>>
>> * Replace context menus
>
> I personally wouldn't mind allowing a web app to *extend* the standard
context menu.
Patches for this is in the works. It'll be allowed for all web pages.
> but I'm not sure I'm comfortable letting it *replace* the context menu.
But I agree with most of your analysis.
Not even ones that you've installed as an app?
For what it's worth, this is one of few things that we have preferences for
in firefox,today. I forget what the default is.
>> Some things that we might want to let an installed app do after
>> prompting the user:
>> * Register as a protocol handler
>> * Register as a content-type handler (double-click a .doc document on
>> the desktop and google docs opens)
>
> Will there be a way to restrict a "web app" from phoning home at all? For
example, we've been discussing writing which can display PDFs, and also a
web app epub reader. But in neither case would I ever want the web app
phoning home to tell its original website what I'm reading. Is there a way
to "download" one of these apps and then run it in a null-principal sandbox?
That seems like an excellent idea. Especially for apps that install
themselves as a WebActivity handler.
> I think this is a pretty fundamental problem with web apps as we've been
discussing them.
>
> I also want to make sure that users who want to continue running web apps
in their browser (in an app tab or whatever) still have the ability to do so
and get some of the advantages of the advanced permissions that we're
developing.
>
> I presume that even if you have a web app running in a non-browser window
that there will still be a minimum of chrome somewhere that lets the user
change preferences and permissions, and move the app back into the browser
if necessary?
>
> Has there been discussion about page navigation in web apps? How do we
distinguish a window.open or target="_blank" which intends to stay part of
the web app from a URL navigation which is intended to open in the default
browser? How do we handle middle-click link opening?
I'll leave this to the apps folks to answer. I agree in general.
/ Jonas
Neil
>On Aug 3, 2011 6:57 AM, "Benjamin Smedberg" <benj...@smedbergs.us> wrote:
>
>
>>Into which category would you put unrestricted drag and drop, and the ability to interact with the OS cut/copy/paste system? Working with the OS clipboard is one of the most-requested webapp features, but would allow web apps to steal clipboard contents.
>>
>The ability to write to the clipboard is something I'd put in the "annoy" category. Being able to read isn't something that I'd want to grant automatically though. But something that would be ok to permanently grant with a "doorhanger" dialog maybe.
>
Being able to read suggests that the web page initiates clipboard
access. It might be better to turn the problem around and notify the web
page of clipboard requests (which could even come from the browser's own
menu). Otherwise you would probably want to block access to the
clipboard in the same way that we block popup abuse when there isn't a
suitable trusted event.
--
Warning: May contain traces of nuts.
Jonas Sicking
A very common use case for sites which contains some for of editable
content (such blogging or webmail site) is to have in-page buttons for
"mark as bold", "create a link" and also "cut", "copy" and "paste".
The last three are currently not possible to implement as in-page
button since you can't call some function to cut/copy/paste.
Sites have always been able to get clipboard functionality by asking
the user to press ctrl-c/ctrl-v/ctrl-x, ur by asking the user to use
the context menu. But this isn't terribly good UI.
/ Jonas
Henri Sivonen
> Sites have always been able to get clipboard functionality by asking
> the user to press ctrl-c/ctrl-v/ctrl-x, ur by asking the user to use
> the context menu. But this isn't terribly good UI.
I'd expect the good UI to be that the user uses what always works: The
edit menu (or equivalent stuff under the Firefox button), ctrl-c/v/x or
the context menu.
Why isn't using the native invocations for clipboard operations good UI?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Gijs Kruitbosch
> On Thu, 2011-08-04 at 14:47 -0700, Jonas Sicking wrote:
>> Sites have always been able to get clipboard functionality by asking
>> the user to press ctrl-c/ctrl-v/ctrl-x, ur by asking the user to use
>> the context menu. But this isn't terribly good UI.
>
> I'd expect the good UI to be that the user uses what always works: The
> edit menu (or equivalent stuff under the Firefox button), ctrl-c/v/x or
> the context menu.
>
> Why isn't using the native invocations for clipboard operations good UI?
>
Because my fictitious grandmother doesn't know those shortcuts, which make no
sense in non-English anyway (at least in Dutch they are never localized, not
sure about other languages), doesn't use the context menu, and there is no more
edit menu like in other applications (everything now being under the Firefox
button). Nor are there toolbar buttons, like in native editors.
Most web apps that have copy/paste support currently use Flash or other plugins
to workaround. If we restrict copy/paste to being called from user-initiated
events (mouse down / click / keyboard handlers, or part of enhanced
permissions), I don't see why there should be any problems with providing
web-accessible APIs for them.
Cheers,
Gijs
Gijs Kruitbosch
>> Sites have always been able to get clipboard functionality by asking
>> the user to press ctrl-c/ctrl-v/ctrl-x, ur by asking the user to use
>> the context menu. But this isn't terribly good UI.
>
> I'd expect the good UI to be that the user uses what always works: The
> edit menu (or equivalent stuff under the Firefox button), ctrl-c/v/x or
> the context menu.
>
> Why isn't using the native invocations for clipboard operations good UI?
Also, these only work when there is actual natively-selected content. Doing
'fake' selections on canvas or SVG and copying that data, for instance, would
need the functionality to be provided by the web app.
Gijs
ya knygar
> Also, these only work when there is actual natively-selected content. Doing 'fake' selections on canvas or SVG and copying that data, for instance, would need the functionality to be provided by the web app.
> Most web apps that have copy/paste support currently use Flash or other plugins to workaround. If we restrict copy/paste to being called from user-initiated events (mouse down / click / keyboard handlers, or part of enhanced permissions), I don't see why there should be any problems with providing web-accessible APIs for them.
as a web UX designer - just thought on this case, recently,
seems like a timely idea.
Mike Hanson
> Will there be a way to restrict a "web app" from phoning home at all? For example, we've been discussing writing which can display PDFs, and also a web app epub reader. But in neither case would I ever want the web app phoning home to tell its original website what I'm reading. Is there a way to "download" one of these apps and then run it in a null-principal sandbox?
Good question - and I'll note, in passing, that most native OSes have only recently reached the point where installed applications can be sandboxed off from system calls in this way. Every native app has the ability to phone home, and many use it for updates - but your point is valid, and would be a step forward. Let's turn it around and talk about use cases.
The set of interesting apps resource accesses includes:
1. Apps which can be entirely downloaded and run completely locally, with no "phone home" capabilities. The challenge here is making sure we have all the resources the app needs, and then denying it access to anything that would constitute a remote access, while opening pipes for interesting local resources like files.
2. Apps which are mostly downloaded, but need to phone home for updates. The update activity could be managed by the browser, or unlocked for a limited time, or restricted to replacing resources which were specified as part of the application.
3. Apps which require a service component from "home". These might have the ability to make Ajax calls back home, but anything that would exit their domain is captured and returned to the user's preferred browser.
4. Apps which require a service component from some place other than home, as well as home. This would be the case where the app wants to talk to a federated login provider, for example. We could either use the Web Activities approach to sandbox this off - i.e. require the app to ask for access to other apps through a user-agent-mediated sandbox - or we could adopt a whitelisting approach.
So, how are we doing in terms of platform capabilities? #3 and #4 are pretty easy. #2 is easy once we have #1.
Would constructing a null-principal sandbox, and wiring up a resource archive to resource:// URLs, be sufficient for #1? What else would be required?
m
Jonas Sicking
FWIW I'm not sure it's useful to distinguish #3 from #4 given that the
website can just route requests to the 3rd party server through the
home server.
> Would constructing a null-principal sandbox, and wiring up a resource archive to resource:// URLs, be sufficient for #1? What else would be required?
I think the technical aspects here are much less interesting and
should be resolvable once we have a "real" story for offline
resources.
The tricky part to me is how to expose this to the user. I.e. how does
the installation UI for a #1 app look different from the UI for a #4
app? Is this something we can really successfully convey to users or
will this only be understood by a few expert geeks? If the latter,
then app developers have very little incentive to spend the time to
create a #1 app I think.
/ Jonas
Mike Shaver
> 2. Apps which are mostly downloaded, but need to phone home for updates. The update activity could be managed by the browser, or unlocked for a limited time, or restricted to replacing resources which were specified as part of the application.
If people are worried about the app changing underneath them, then in
fact they want that to be the set of things that are *excluded* from
mutation, where other bits can be cached and so forth.
But the phone-home worry is usually about information going *out*, not
*in*, in which case the only solution is to prevent all requests.
(Probably including indirect ones, such as triggering DNS lookups, if
we want to get really tinfoil-hatty.)
Mike