> On 3 Jun 2015, at 5:40 am, Jonas Sicking <[email protected]> wrote:
>
> On Wed, May 6, 2015 at 9:36 PM, Paul Theriault <[email protected]> wrote:
>> My main goals in this effort are mainly:
>>
>> * simplify the permission model for users and developers
>> * move the FxOS permission model more in line with desktop & mobile (i.e.
>> for regular web content)
>> * Provide a permission model that supports the new security model [1]
>
> These sound great!
>
>> == Web Content/Webapps - "Web Permissions" ==
>> * We should harmonise the permission granting behaviour on Firefox OS with
>> desktop and mobile.
>> * Example permissions: microphone, geolocation, camera, alarms, push,
>> storage, notifications (i.e. all the things you can already request from web
>> pages)
>
> Agreed! I think that we should use the same permissions for guarding
> getUserMedia as for guarding the camera and microphone API. To the
> user the two are equivalent anyway.
>
>> * Remove requirement for apps to declare these permissions, we don't use it
>> for anything meaningful and it means less in a linkable app world
>
> Agreed.
>
> The main thing that is unfortunate that we're losing is the ability to
> show a better "permissions UI" for the list of pinned websites.
>
> I.e. I think it would be cool if the user could pin a website, then go
> to a permissions UI (in the settings UI or elsewhere) and see a list
> of switches for permissions that the website might ask for at some
> point in the future.
>
> So for example after the user has pinned twitter, it would be cool if
> the user could bring up a UI where it sees that twitter somewhere use
> the geolocation and microphone APIs and enable the user to flip them
> on/off right away.
>
> But I don't think that's worth the current hassle and website
> incompatibility that we're currently having to deal with. So I'm in
> full agreement with you.
One of the benefits of a reduced permission list is that we CAN show this UI
(you just show all potential options, in the same way that View Page Info ->
Permissions does on desktop. Or about:permissions <about:permissions>.
Basically we will need a FxOS version of this interface. I was imagining this
UI would be available for both pinned and unpinned pages, but we could maybe
make it more accessible to pinned apps.
(CC’ing Tiffanie since she is helping with UX for new security model)
>
>> * Most permissions granted by prompt, except for those granted implicitly by
>> install/pinning (e.g. alarms, storage)
>
> Agreed.
>
> I think both alarm and storage are things that a unpinned/uninstalled
> website can ask for, at which point we would prompt the user.
>
> I.e. I think alarms and storage are also prompted permissions. But
> ones that are automatically granted when the user pins the website.
I agree, though I would also like to improve the UX around management of these.
(theres no alarm management and storage management is limited currently)
>
>> * Make the prompting UX closer to desktop & mobile (no more modal prompts
>> that force users into bad decisions)
>
> I don't have strong opinions here. It's cool if we can make it work,
> but it might be hard to do on a small screen.
>
>> * Implement an "about:permissions" equivalent for managing permissions that
>> works for websites, not just apps:
>
> Definitely!
>
>> ** we need a permission management interface that doesn't depend on app
>> permission declarations
>> ** we need to support managing permissions for websites as well as apps
>
> Agreed on both counts.
>
> I guess there's two sides to this.
>
> We an API to allow the settings UI to inspect any permissions that
> have been set, as well as modify those permission. I don't think we
> need anything fancy here. Mainly we need to get a list of all websites
> which we have saved permissions for, we need to be able to get/set a
> permission for a given website, and we need to be able to pick a
> specific cookiejar, which is something that we'll stop using once we
> get rid of apps.
>
> So something like
>
> dictionary PermissionOrigin {
> DOMString origin;
> DOMString manifestURI;
> boolean browserFlag;
> };
>
> dictionary StoredPermission {
> DOMString permission;
> DOMString value;
> PermissionOrigin origin;
> };
>
> interface PermissionSettings
> {
> Promise<DOMString> get(DOMString permission, PermissionOrigin origin);
> Promise<void> set(DOMString permission, DOMString value,
> PermissionOrigin origin);
> Promise<void> remove(DOMString permission, DOMString manifestURI,
> PermissionOrigin origin);
> Promise<sequence<StoredPermission>> enumerate();
>
> // I'm not sure if this one is still needed?
> boolean isExplicit(DOMString permission, PermissionOrigin origin);
> };
>
>
> But in addition, we need a way for webpage to check if they have a
> given permission. This is what they should check rather than checking
> "am I pinned or not". The two APIs that we should implement in order
> to support this are:
>
> https://w3c.github.io/permissions/
> https://wiki.whatwg.org/wiki/Storage
>
> The latter probably needs some polish to separate out the stable parts
> from the unstable parts (in particular storage boxes are unstable
> still).
Ok thanks, this is helpful.
>
>> == Signed & Pre-installed content - "Privileged Permissions" ==
>> * permissions will still be declared, and the content reviewed by
>> marketplace & signed
>
> Yup
>
>> * there's no install step though, so the apps just load except no longer
>> just granting implicit permissions
>
> Yup
>
>> * restrict the apps entry points by default (i.e. you can only link to
>> predeclared entry points) - perhaps something like the W3C Entry Points
>> Restriction spec [2]
>
> Yeah, I'd definitely like to do this. I haven't looked at [2] though
> so I have no idea if it's reusable here. I don't think we should worry
> too much about reusing anything since signed content is inherently
> FirefoxOS specific.
>
> We also need to figure out an implementation strategy for this. We
> should probably add the entry-points stuff to
> https://wiki.mozilla.org/FirefoxOS/New_security_model
> <https://wiki.mozilla.org/FirefoxOS/New_security_model>
Ok, will do.
>
>> * for explicit permissions (prompted ones), they are granted as normal,
>> however I think we need to to improve the prompting UX to differentiate
>> these more powerful APIs from regular web permissions. I'm imagine a
>> specific visual metaphors for "data" permissions (contacts, photos, videos,
>> music), and maybe something more like a "per-app" toggle for device
>> permissions like fmradio,nfc & bluetooth. (i.e. you "turn on" bluetooth on a
>> per-app basis, in addition to a system-wide). I'm interested to see what
>> people can come up with here.
>
> Happy to see better UX here for sure.
>
> Only minor nit I have is that it feels like we could expose fmradio to
> normal websites. It's pretty harmless after all. It's pretty
> comparable to geolocation.
Yep totally agree.
>
>> * for implicit permissions (hidden permissions, previously granted upon
>> install): we can't just grant these upon load (its too dangerous, at least
>> for most apps), so we will need some other mechanism. I imagine this will be
>> a combination of approaches:
>> ** follow a similar mechanism to what we do for alarms & notifications
>> (that is, grant permissions only after pinning the app)
>
> I *really* don't want to do this. I want to enable users to only pin
> things that the actively use. I also want pinning to not be a security
> decision.
I agree - i actually updated this on the wiki already.
>
>> ** having an extended verification review program for apps which request
>> certain more-sensitive permissions (especially those which were previously
>> certified permissions)
>
> I'd prefer this.
>
> I think that if we add the ability to define domains to be connected
> to for TCPSocket/UDPSocket/systemXHR, then I think we'll dramatically
> reduce the number of apps that need this extended verification.
>
>> * we will also need strong blocking/revocation mechanism to revoke apps
>> signed by marketplace that are subsequently found to be vulnerable/malicious
>
> This would be great if we have the resources.
>
> / Jonas
>
>> I'm writing up a more detailed proposal at the moment, but I wanted to
>> circulate a summary first just to garner initial feedback.
>>
>> Thanks,
>> Paul
>>
>>
>> [1] https://wiki.mozilla.org/FirefoxOS/New_security_model
>> [2] https://w3c.github.io/webappsec/specs/epr/
>>
>>
>> _______________________________________________
>> dev-b2g mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-b2g
>>
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
