Declarative File System Provider API. [Review request]

Tomasz Mikolajewski

unread,

Apr 16, 2015, 5:06:40 AM4/16/15

to apps-dev, security-enamel

Hi guys,

The title may sound big, but the proposed change is pretty small.
Basically I'd like to move some options set in runtime to the manifest
for an existing API.

https://docs.google.com/document/d/1iTo86QvCDE8CUAHz-fxojRDv2fZRvG_SUdqq5NDGpW0/edit?usp=sharing

Let me know if you're fine with this solution.

Thanks,
Tomasz.

Benjamin Kalman

unread,

Apr 22, 2015, 3:35:36 PM4/22/15

to Tomasz Mikolajewski, apps-dev, security-enamel

lgtm, I am fine with this.

Mustafa Emre Acer

unread,

Apr 27, 2015, 8:14:34 PM4/27/15

to Benjamin Kalman, Tomasz Mikolajewski, apps-dev, security-enamel

Security LGTM.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

Zelidrag Hornung

unread,

Apr 27, 2015, 8:42:35 PM4/27/15

to Mustafa Emre Acer, Benjamin Kalman, Tomasz Mikolajewski, apps-dev, security-enamel, Toni Barzic

When we are already at it, can we also add a declarative manifest flag that will let such "driver" apps hide themselves from the app list? I suspect that many of them won't have much to show outside of their usage context.

We have the same problem on chrome.printerProvider API, so such flag should not be FSP-specific. We will need to figure out if any extra UI is needed for letting users curate such apps.

Benjamin Kalman

unread,

Apr 28, 2015, 12:54:55 PM4/28/15

to Zelidrag Hornung, Mustafa Emre Acer, Tomasz Mikolajewski, apps-dev, security-enamel, Toni Barzic

That's a discussion worth having. I think from an API perspective it makes sense, but UI needs consideration, e.g. what surface are these drivers displayed in order to attribute actions to them, uninstall them, etc.

Antony Sargent

unread,

Apr 28, 2015, 12:58:36 PM4/28/15

to Benjamin Kalman, Zelidrag Hornung, Mustafa Emre Acer, Tomasz Mikolajewski, apps-dev, security-enamel, Toni Barzic

It would also be super important to consider abuse scenarios - unfortunately malicious developers are always looking for ways to keep their unwanted extensions hidden from users and/or hard to uninstall.

Toni Barzic

unread,

Apr 28, 2015, 2:36:14 PM4/28/15

to Antony Sargent, Benjamin Kalman, Zelidrag Hornung, Mustafa Emre Acer, Tomasz Mikolajewski, apps-dev, security-enamel

Note that there already is "display_in_launcher" manifest feature, but it's restricted to component apps and few whitelisted apps. Technically, I guess these restrictions could be loosen up for this for certain types of apps (e.g. if an app has printerProvider permission), but I agree that the main issue here is in which UI to surface these apps (and whether it would be OK to show them only in chrome://extensions, which would probably blur the distinction between apps and extensions even more).

(though, for printer provider apps, the actual issue is that chrome.usb and chrome.mdns APIs are apps-only)

Reply all

Reply to author

Forward