chrome.fileSystem.requestFileSystem - New API Proposal

[Tomasz Mikolajewski]

Hi guys,

I'd like to ask for review of the chrome.fileSystem.requestFileSystem
API, which is simply two new API methods and one new event added to
the existing chrome.fileSystem API.

The new feature will be enabled to Kiosk apps in Kiosk sessions
*only*, plus to the whitelisted Files app.

https://docs.google.com/document/d/16XOJ_qQxNtiCIdUkNJ5T4HSXo7OX7spBs8MGGrEcOr8/edit?usp=sharing

We're aiming to ship it in M42. It will be mostly moving the
methods/events from chrome.fileManagerPrivate to their new home.

Please let me know if you have any questions.

Thanks,
Tomasz.

[Reilly Grant]

Please fill in the "Overview" section of the proposal template.

[Ian Clelland]

I'm just curious, but why is this kiosk only? It seems like something that would be useful for Chrome apps generally, with the appropriate permissions model.

Why Chrome only? I understand that you've namespaced it under chrome.fileSystem, but the model could easily extend to the larger web, again, with the right permissions. It looks like it could fit well with the web FileSystem APIs. (We've done just that for Cordova, to access device removable storage from hybrid apps).

Is it just to be able to implement this quickly, in a small sandbox, or is the intention that this API is always and forever just for Chrome kiosk apps?

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

[Kyle Graehl]

Can't chrome.mediaGalleries be used to get access to all external
media automatically? Why does there need to be an additional API?

[Ben Wells]

On Thu Dec 11 2014 at 8:26:32 AM 'Ian Clelland' via apps-dev <apps...@chromium.org> wrote:

I'm just curious, but why is this kiosk only? It seems like something that would be useful for Chrome apps generally, with the appropriate permissions model.

It goes against the security model we have in place for chrome apps, which is that apps are sandboxed. The file system stuff as it is was pretty hard to get agreement on, as it breaks the sandbox model. The rationale for allowing file system as it is, is that the user is in control of exactly where the sandbox is broken. This API just gets rid of the sandbox as far as files are concerned.

 

Why Chrome only? I understand that you've namespaced it under chrome.fileSystem, but the model could easily extend to the larger web, again, with the right permissions. It looks like it could fit well with the web FileSystem APIs. (We've done just that for Cordova, to access device removable storage from hybrid apps).

Again it goes against the security model of the web. I would love to start talking about bringing something like the current chrome.fileSystem made available to the web at large, but I would be scared to have a permission available to web pages like "give this web site arbitrary access to my file system".

A first step for the web would be to give web pages some way to write to files that the user has opened.

 

Is it just to be able to implement this quickly, in a small sandbox, or is the intention that this API is always and forever just for Chrome kiosk apps?

I'd say the latter. Complete file system access will be forever just for Chrome kiosk apps.

[Ben Wells]

On Thu Dec 11 2014 at 9:10:03 AM Kyle Graehl <kgr...@gmail.com> wrote:

Can't chrome.mediaGalleries be used to get access to all external
media automatically? Why does there need to be an additional API?

This isn't necessarily for media.

 

>> email to apps-dev+unsubscribe@chromium.org.

>
> To unsubscribe from this group and stop receiving emails from it, send an

> email to apps-dev+unsubscribe@chromium.org.

[Tomasz Mikolajewski]

Hi guys. I updated the doc some time ago. Please take a look again. Let me know if you have any more questions. Thanks.

[Ben Wells]

lgtm

[Tomasz Mikolajewski]

@meacer, @jww: Ping for security review. Thanks.

[Joel Weinberger]

I'm taking a look.

[Joel Weinberger]

Tomasz, I'm unfortunately unable to access the doc. Can you verify that it is shared and viewable? Thanks!

[Tomasz Mikolajewski]

Hi Joel. The document is shared with everyone. What error message are you getting?

Please try:

https://docs.google.com/document/d/16XOJ_qQxNtiCIdUkNJ5T4HSXo7OX7spBs8MGGrEcOr8/edit?usp=sharing

Thanks,

Tomasz.

[Joel Weinberger]

Hm, perhaps it was a temporary Drive issue? Working now, though, so I'm taking a look.

[Joel Weinberger]

Offhand, this very much does NOT look good to me. A couple of points:

• We are pushing towards choosers rather than relying on install time permissions so that users have control and understanding of what apps have access to. I think that the mediaGalleries API is a great example of where we got this to work well.
• The file system in general is a place that users already have a good understanding and expectation of choosers, and this API would violate that expectation.
• Perhaps I'm missing something, but this API seems like it would be an excellent candidate for a chooser. Something like, if an app has the requestFileSystem permission, any time an external device is plugged in, a chooser would pop up to let the user grant access to the device or any set of folders on the device (or none at all).
• Whitelisting should not be used as a way to "secure" an API. Besides the fact that there are various work around the whitelist (such as sideloading apps), we want to make sure that the apps we build are also secure, and provide better guarantees even if they're compromised.

I suggest that we use mediaGalleries as a model and try to build a similar chooser for this API.

--Joel

[Zelidrag Hornung]

Really, chooser in kiosk? Do you have clear understanding of how kiosk mode is supposed to be working?

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

[Joel Weinberger]

"Clear" is a strong word :-) I have a high level understanding of how kiosk mode works, but if you can point me to a design doc or the like, I'd certainly appreciate it.

Let me try to put my concerns in more precise terms. Firstly, imagine a user downloads a Kiosk app to, say, test it out. They've used ChromeOS for a while, so they have the reasonable expectation that their USB stick that's plugged into the machine is under their control. They restart into kiosk mode and, oops, it's badware.

Unfortunately, there wasn't even an install warning (which are bad enough since they're ignored so often), so in this case there was literally no way for a user to know that this app was going to steal all the data off their USB stick. This breaks a guarantee that we currently have, and is definitely very surprising to a user, and, I'd argue, it's just a bad user experience as well. A chooser prevents all of these concerns and provides the user with control.

Secondly, we currently have a pretty cool guarantee in ChromeOS that, if you trust the physical device you're about to use is a legitimate Chromebook, you can use that plug in a USB to that device and have complete control over what files are transferred on and off. That's a pretty useful guarantee to have, and this mode would change that. For example, I might be much more hesitant to use a Chromebook in kiosk mode with Dropbox enabled if I thought it might upload all the contents of my USB without my consent.

--Joel

[Tomasz Mikolajewski]

We *will* have an install warning clearly saying that the kiosk app will have an unlimited access to all connected removable devices. It's mentioned in the doc.

If it's not enough, we could think about adding a light confirmation dialog. Kiosk apps would be able to list all removables without asking for user consent, but to access them, a dialog like "Do you want to grant access to Kingston USB 8 GB? Yes, No" would be shown. The choice would be remembered until the device is physically removed.

The second solution adds quite a lot of complexity to the API implementation, so if a simple install warning is fine, then I'd prefer to just go with it instead.

Joel, Zel: WDYT?

[Tomasz Mikolajewski]

On 10 January 2015 at 08:30, Chris Palmer <pal...@google.com> wrote:

On Thu, Jan 8, 2015 at 3:56 PM, 'Tomasz Mikolajewski' via Security
Enamel <securit...@chromium.org> wrote:

> We *will* have an install warning clearly saying that the kiosk app will
> have an unlimited access to all connected removable devices. It's mentioned
> in the doc.

You're asking users to make a critical decision at a time when they
have no context and no way to understand, viscerally, the value
proposition and risk.

Thinking that way inevitably leads to:

> If it's not enough, we could think about adding a light confirmation dialog.

No, usable security is not about carefully tuning annoyance factors.
It's about empowering people to make relevant and informed decisions
about who or what to trust, and how much, and when.

What's wrong with a confirmation dialog? It clearly asks the user whether he wants to grant access to the extension which is running once the extension requests it. Isn't it a well informed decision? Is your concern about persistency? We already allow that with chrome.filesystem.retainEntry, but only for entries, not file systems. Also, it's not really pesistent, as user can always unplug the usb drive to revoke the granted permission.

> The second solution adds quite a lot of complexity to the API
> implementation, so if a simple install warning is fine, then I'd prefer to
> just go with it instead.

Experience with Android shows that granting permanent ambient
authority at a time when the user doesn't understand the grant is a
non-starter, and a great way to damage a product's reputation.

So, what it is that makes kiosk mode incompatible with choosers?
Forgive my ignorance; I don't have much experience with kiosk mode.
(I.e. I tried it out for the first time for 1 minute just now. :) )

Some examples which do not work well with choosers:

1. Kiosk apps showing movies from the kiosk's usb hard disk.

2. Picture printing booths (famous in Japan). Inserting a device is already a user action. Asking user to additionally choose the device from a list is an overkill from the user perspective.

Asking a user to choose a device from a list may be very confusing for an average user, as USB drive names are confusing. For MTP it's easier as we can show the Device model name. Still my mom doesn't know what's her phone's model number, so she wouldn't know what to choose in the chooser dialog. That's why instead of a choose I'd rather go with a confirmation dialog.

One more important thing is that kiosks may not have any user input device. In such case both - choosers and confirmation dialogs will not work out.

[Joel Weinberger]

To my understanding (and I'm happy to be corrected here), kiosk mode is a part of the manifest that an app developer gets to write. Thus, we should assume that all malicious apps that are created will turn it on if it provides magical powers that they can't otherwise get.

Since filesystems and devices are otherwise extremely carefully guarded by our APIs, this is precisely the kind of additional power that a malicious app is likely to want to get access to. So not having a chooser for devices and/or filesystems is a non-starter.

On Fri Jan 09 2015 at 6:28:49 PM Tomasz Mikolajewski <mto...@chromium.org> wrote:

On 10 January 2015 at 08:30, Chris Palmer <pal...@google.com> wrote:

On Thu, Jan 8, 2015 at 3:56 PM, 'Tomasz Mikolajewski' via Security
Enamel <securit...@chromium.org> wrote:

> We *will* have an install warning clearly saying that the kiosk app will
> have an unlimited access to all connected removable devices. It's mentioned
> in the doc.

You're asking users to make a critical decision at a time when they
have no context and no way to understand, viscerally, the value
proposition and risk.

Thinking that way inevitably leads to:

> If it's not enough, we could think about adding a light confirmation dialog.

No, usable security is not about carefully tuning annoyance factors.
It's about empowering people to make relevant and informed decisions
about who or what to trust, and how much, and when.

What's wrong with a confirmation dialog? It clearly asks the user whether he wants to grant access to the extension which is running once the extension requests it. Isn't it a well informed decision? Is your concern about persistency? We already allow that with chrome.filesystem.retainEntry, but only for entries, not file systems. Also, it's not really pesistent, as user can always unplug the usb drive to revoke the granted permission.

I guess I don't really know what you mean by a confirmation dialog. Can you explain precisely what you mean, because you're initial description sounds a lot like an install prompt which, as palmer@ said, is no good. 

> The second solution adds quite a lot of complexity to the API
> implementation, so if a simple install warning is fine, then I'd prefer to
> just go with it instead.

Experience with Android shows that granting permanent ambient
authority at a time when the user doesn't understand the grant is a
non-starter, and a great way to damage a product's reputation.

So, what it is that makes kiosk mode incompatible with choosers?
Forgive my ignorance; I don't have much experience with kiosk mode.
(I.e. I tried it out for the first time for 1 minute just now. :) )

Some examples which do not work well with choosers:

1. Kiosk apps showing movies from the kiosk's usb hard disk.

I don't understand why this wouldn't work with a chooser. 

2. Picture printing booths (famous in Japan). Inserting a device is already a user action. Asking user to additionally choose the device from a list is an overkill from the user perspective.

I disagree with your statement that it's overkill, especially if we grant the chooser the usual filesystem type of chooser where the user can grant permission to only a subset of the filesystem. 

Asking a user to choose a device from a list may be very confusing for an average user, as USB drive names are confusing. For MTP it's easier as we can show the Device model name. Still my mom doesn't know what's her phone's model number, so she wouldn't know what to choose in the chooser dialog. That's why instead of a choose I'd rather go with a confirmation dialog.

We can abstract that away in other ways by calling it things like "USB 1", "USB 2", etc. Admittedly, that's a terrible set of example names, but I haven't thought too hard about it :-) 

One more important thing is that kiosks may not have any user input device. In such case both - choosers and confirmation dialogs will not work out.

I agree that's problematic (although I've personally never seen a kiosk that has *no* user input, even a touch screen), but again, since kiosk mode is something apps can turn on at a whim, that's unfortunately going to have to be a the case.

Let me be very explicit here about what our (the security team's) conditions are:

• Having an install warning/prompt is not an acceptable solution. They are ineffective in general, and it will cause great user surprise to all of a sudden have a file system API that they don't give permission to (but is granted automatically). We should all act as if users never read the install prompts because all evidence points to that being the case.
• A run-time chooser solution is the only security team approved mechanism for files, folders, or filesystem access in Chrome.

[Tomasz Mikolajewski]

On 11 January 2015 at 14:28, Joel Weinberger <j...@chromium.org> wrote:

To my understanding (and I'm happy to be corrected here), kiosk mode is a part of the manifest that an app developer gets to write. Thus, we should assume that all malicious apps that are created will turn it on if it provides magical powers that they can't otherwise get.

Since filesystems and devices are otherwise extremely carefully guarded by our APIs, this is precisely the kind of additional power that a malicious app is likely to want to get access to. So not having a chooser for devices and/or filesystems is a non-starter.

I agree, however don't forget that this access would be given to kiosk apps which are executed in *kiosk session* only. Apps running normally from the launcher, wouldn't get that access even if they are marked as "kiosk_enabled" in the manifest. It is not easy to run apps in kiosk session, and actually I don't see much reason for normal users to use the kiosk session.

 

On Fri Jan 09 2015 at 6:28:49 PM Tomasz Mikolajewski <mto...@chromium.org> wrote:

On 10 January 2015 at 08:30, Chris Palmer <pal...@google.com> wrote:

On Thu, Jan 8, 2015 at 3:56 PM, 'Tomasz Mikolajewski' via Security
Enamel <securit...@chromium.org> wrote:

> We *will* have an install warning clearly saying that the kiosk app will
> have an unlimited access to all connected removable devices. It's mentioned
> in the doc.

You're asking users to make a critical decision at a time when they
have no context and no way to understand, viscerally, the value
proposition and risk.

Thinking that way inevitably leads to:

> If it's not enough, we could think about adding a light confirmation dialog.

No, usable security is not about carefully tuning annoyance factors.
It's about empowering people to make relevant and informed decisions
about who or what to trust, and how much, and when.

What's wrong with a confirmation dialog? It clearly asks the user whether he wants to grant access to the extension which is running once the extension requests it. Isn't it a well informed decision? Is your concern about persistency? We already allow that with chrome.filesystem.retainEntry, but only for entries, not file systems. Also, it's not really pesistent, as user can always unplug the usb drive to revoke the granted permission.

I guess I don't really know what you mean by a confirmation dialog. Can you explain precisely what you mean, because you're initial description sounds a lot like an install prompt which, as palmer@ said, is no good.

As I said before, it would be a confirmation dialog shown when access to a file system is requested, so it's a runtime confirmation dialog. Kiosk apps could enumerate file systems, but to acquire access to it, a confirmation dialog would be shown to a user. This looks better to me, as we wouldn't ask people to choose between "USB 1" vs"USB 2" or in the best case "Kingston 8GB" vs "Sandisk 4GB" but simply ask "Can this app access the inserted device Sandisk 4GB? Yes, No" or sth like that.

 

 

 

> The second solution adds quite a lot of complexity to the API
> implementation, so if a simple install warning is fine, then I'd prefer to
> just go with it instead.

Experience with Android shows that granting permanent ambient
authority at a time when the user doesn't understand the grant is a
non-starter, and a great way to damage a product's reputation.

So, what it is that makes kiosk mode incompatible with choosers?
Forgive my ignorance; I don't have much experience with kiosk mode.
(I.e. I tried it out for the first time for 1 minute just now. :) )

Some examples which do not work well with choosers:

1. Kiosk apps showing movies from the kiosk's usb hard disk.

I don't understand why this wouldn't work with a chooser.

It's a Kiosk usb hard disk hidden in the kiosk cover. Users who come to a kiosk device, will be asked to choose an internal HDD containing movies, while they didn't insert any device. Which one should they choose if there are multiple ones, and only one is correct?

 

2. Picture printing booths (famous in Japan). Inserting a device is already a user action. Asking user to additionally choose the device from a list is an overkill from the user perspective.

I disagree with your statement that it's overkill, especially if we grant the chooser the usual filesystem type of chooser where the user can grant permission to only a subset of the filesystem.

In kiosks, there is only one running app. I bet users expect that inserting a USB device to the kiosk device will grant the access to it. Let me ask the other way. Why would user do not want to grant the permission to an inserted device to a kiosk device? I can't think of any scenario. So we'd show a chooser for no reason, as all users will grant the permission to the inserted device. Otherwise, they wouldn't insert it. Hence, I think it's an overkill.

Asking a user to choose a device from a list may be very confusing for an average user, as USB drive names are confusing. For MTP it's easier as we can show the Device model name. Still my mom doesn't know what's her phone's model number, so she wouldn't know what to choose in the chooser dialog. That's why instead of a choose I'd rather go with a confirmation dialog.

We can abstract that away in other ways by calling it things like "USB 1", "USB 2", etc. Admittedly, that's a terrible set of example names, but I haven't thought too hard about it :-)

Really, I don't think this would work out. My mom will be asked to choose from "Sandisk 4GB", "Kingston 8GB" and "Kingston 4GB" or even more strange items. I'm sure she will be very troubled to guess which one is her device. This is indeed secure from the security point of view, but it's a bummer from user experience point of view. We need to find some solution satisfying both.

 

One more important thing is that kiosks may not have any user input device. In such case both - choosers and confirmation dialogs will not work out.

I agree that's problematic (although I've personally never seen a kiosk that has *no* user input, even a touch screen), but again, since kiosk mode is something apps can turn on at a whim, that's unfortunately going to have to be a the case.

I'm not sure if I understand here, but apps can't run themselves in kiosk session. Kiosk configuration is necessary. Adding "kiosk_enabled" in the manifest, doesn't mean that the app will get the extra permission to file systems when running from the launcher. They will not.

 

Let me be very explicit here about what our (the security team's) conditions are:

• Having an install warning/prompt is not an acceptable solution. They are ineffective in general, and it will cause great user surprise to all of a sudden have a file system API that they don't give permission to (but is granted automatically). We should all act as if users never read the install prompts because all evidence points to that being the case.

Fair enough. 

• A run-time chooser solution is the only security team approved mechanism for files, folders, or filesystem access in Chrome.

How about the runtime confirmation dialog?

Also, how about the usb hdd disk in the kiosk device (as mentioned above)? If a chooser is the only approved mechanism, then it's a bummer. How about certificates for kiosk internal USB HDDs? We could create a mechanism which would bypass the chooser/confirmation dialog for devices which have the certificate file on it. Kiosk manufacturers could generate and put such certificate on the internal USB HDD used by the kiosk app. 

Last idea I have is to use a chooser or a runtime confirmation dialog but allow to bypass it using the enterprise policy. Then the device owner could disable the chooser.

[Ben Wells]

I think this discussion is getting too detailed and we need to back up a bit and discuss a more general topic. I've started a new thread to discuss the security model of kiosk mode.

[Joel Weinberger]

On Sun Jan 11 2015 at 3:40:51 PM Ben Wells <benw...@chromium.org> wrote:

I think this discussion is getting too detailed and we need to back up a bit and discuss a more general topic. I've started a new thread to discuss the security model of kiosk mode.

I don't completely agree, so I'll respond to the details below :-) But I'll also, of course, respond to your other thread as well. 

On Sun Jan 11 2015 at 5:36:39 PM Tomasz Mikolajewski <mto...@chromium.org> wrote:

On 11 January 2015 at 14:28, Joel Weinberger <j...@chromium.org> wrote:

To my understanding (and I'm happy to be corrected here), kiosk mode is a part of the manifest that an app developer gets to write. Thus, we should assume that all malicious apps that are created will turn it on if it provides magical powers that they can't otherwise get.

Since filesystems and devices are otherwise extremely carefully guarded by our APIs, this is precisely the kind of additional power that a malicious app is likely to want to get access to. So not having a chooser for devices and/or filesystems is a non-starter.

I agree, however don't forget that this access would be given to kiosk apps which are executed in *kiosk session* only. Apps running normally from the launcher, wouldn't get that access even if they are marked as "kiosk_enabled" in the manifest. It is not easy to run apps in kiosk session, and actually I don't see much reason for normal users to use the kiosk session.

Like I said earlier, I only have a high level understanding about kiosk mode, so any docs that you can send the security team would be welcome. 

 

On Fri Jan 09 2015 at 6:28:49 PM Tomasz Mikolajewski <mto...@chromium.org> wrote:

On 10 January 2015 at 08:30, Chris Palmer <pal...@google.com> wrote:

On Thu, Jan 8, 2015 at 3:56 PM, 'Tomasz Mikolajewski' via Security
Enamel <securit...@chromium.org> wrote:

> We *will* have an install warning clearly saying that the kiosk app will
> have an unlimited access to all connected removable devices. It's mentioned
> in the doc.

You're asking users to make a critical decision at a time when they
have no context and no way to understand, viscerally, the value
proposition and risk.

Thinking that way inevitably leads to:

> If it's not enough, we could think about adding a light confirmation dialog.

No, usable security is not about carefully tuning annoyance factors.
It's about empowering people to make relevant and informed decisions
about who or what to trust, and how much, and when.

What's wrong with a confirmation dialog? It clearly asks the user whether he wants to grant access to the extension which is running once the extension requests it. Isn't it a well informed decision? Is your concern about persistency? We already allow that with chrome.filesystem.retainEntry, but only for entries, not file systems. Also, it's not really pesistent, as user can always unplug the usb drive to revoke the granted permission.

I guess I don't really know what you mean by a confirmation dialog. Can you explain precisely what you mean, because you're initial description sounds a lot like an install prompt which, as palmer@ said, is no good.

As I said before, it would be a confirmation dialog shown when access to a file system is requested, so it's a runtime confirmation dialog. Kiosk apps could enumerate file systems, but to acquire access to it, a confirmation dialog would be shown to a user. This looks better to me, as we wouldn't ask people to choose between "USB 1" vs"USB 2" or in the best case "Kingston 8GB" vs "Sandisk 4GB" but simply ask "Can this app access the inserted device Sandisk 4GB? Yes, No" or sth like that.

That's certainly better than an install prompt, but having users actively choose what they want is much more powerful than confirmation. Confirmations don't force users to think about context in their response. Additionally, I've seen very few (none?) filesystem-related prompts that were ever confirmations rather than choosers. 

 

 

 

> The second solution adds quite a lot of complexity to the API
> implementation, so if a simple install warning is fine, then I'd prefer to
> just go with it instead.

Experience with Android shows that granting permanent ambient
authority at a time when the user doesn't understand the grant is a
non-starter, and a great way to damage a product's reputation.

So, what it is that makes kiosk mode incompatible with choosers?
Forgive my ignorance; I don't have much experience with kiosk mode.
(I.e. I tried it out for the first time for 1 minute just now. :) )

Some examples which do not work well with choosers:

1. Kiosk apps showing movies from the kiosk's usb hard disk.

I don't understand why this wouldn't work with a chooser.

It's a Kiosk usb hard disk hidden in the kiosk cover. Users who come to a kiosk device, will be asked to choose an internal HDD containing movies, while they didn't insert any device. Which one should they choose if there are multiple ones, and only one is correct?

If I was developing said kiosk app, I'd ask the user immediately when the app is started to ask for access to the hard drive, which makes sense since that's when it was "accessed" for the first time. So, correct, I think your description would be silly, but that sounds like an app bug, not an API problem. 

 

2. Picture printing booths (famous in Japan). Inserting a device is already a user action. Asking user to additionally choose the device from a list is an overkill from the user perspective.

I disagree with your statement that it's overkill, especially if we grant the chooser the usual filesystem type of chooser where the user can grant permission to only a subset of the filesystem.

In kiosks, there is only one running app. I bet users expect that inserting a USB device to the kiosk device will grant the access to it. Let me ask the other way. Why would user do not want to grant the permission to an inserted device to a kiosk device? I can't think of any scenario. So we'd show a chooser for no reason, as all users will grant the permission to the inserted device. Otherwise, they wouldn't insert it. Hence, I think it's an overkill.

That might be true for some apps, but not necessarily all. In any case, what I described was a chooser that let the user choose what subset of the file system they'd like to give access to.

Asking a user to choose a device from a list may be very confusing for an average user, as USB drive names are confusing. For MTP it's easier as we can show the Device model name. Still my mom doesn't know what's her phone's model number, so she wouldn't know what to choose in the chooser dialog. That's why instead of a choose I'd rather go with a confirmation dialog.

We can abstract that away in other ways by calling it things like "USB 1", "USB 2", etc. Admittedly, that's a terrible set of example names, but I haven't thought too hard about it :-)

Really, I don't think this would work out. My mom will be asked to choose from "Sandisk 4GB", "Kingston 8GB" and "Kingston 4GB" or even more strange items. I'm sure she will be very troubled to guess which one is her device. This is indeed secure from the security point of view, but it's a bummer from user experience point of view. We need to find some solution satisfying both.

 

One more important thing is that kiosks may not have any user input device. In such case both - choosers and confirmation dialogs will not work out.

I agree that's problematic (although I've personally never seen a kiosk that has *no* user input, even a touch screen), but again, since kiosk mode is something apps can turn on at a whim, that's unfortunately going to have to be a the case.

I'm not sure if I understand here, but apps can't run themselves in kiosk session. Kiosk configuration is necessary. Adding "kiosk_enabled" in the manifest, doesn't mean that the app will get the extra permission to file systems when running from the launcher. They will not.

Sure, apps can't "run themselves" in kiosk mode, but we should be concerned about apps saying "hey, to get special powers, run this app in this cool mode!" We already have this problem with Android ("put the phone in dev mode to make this app awesome; here's how!") and on the Web with the dev console ("hey, user, copy this JavaScript into the console!"). This are both very problematic, and we're having trouble containing these types of apps. I really don't want to add more "super power" modes that users might be tricked into using.

Even ignoring that, as I described before, a user might just want to try out a kiosk app, and we should make that as unsurprising and safe an experience as possible.

 

Let me be very explicit here about what our (the security team's) conditions are:

• Having an install warning/prompt is not an acceptable solution. They are ineffective in general, and it will cause great user surprise to all of a sudden have a file system API that they don't give permission to (but is granted automatically). We should all act as if users never read the install prompts because all evidence points to that being the case.

Fair enough. 

• A run-time chooser solution is the only security team approved mechanism for files, folders, or filesystem access in Chrome.

How about the runtime confirmation dialog?

Also, how about the usb hdd disk in the kiosk device (as mentioned above)? If a chooser is the only approved mechanism, then it's a bummer. How about certificates for kiosk internal USB HDDs? We could create a mechanism which would bypass the chooser/confirmation dialog for devices which have the certificate file on it. Kiosk manufacturers could generate and put such certificate on the internal USB HDD used by the kiosk app. 

Last idea I have is to use a chooser or a runtime confirmation dialog but allow to bypass it using the enterprise policy. Then the device owner could disable the chooser.

We allow a lot of extra power for enterprise policies, so that probably makes sense, although I'm unaware of any precedence of disabling security warnings and dialogs that way. Let's keep that in our back pocket if we can't design anything else that satisfies our needs more generally.

[Matt Giuca]

I have added a few comments on the actual API proposal itself.

I think this discussion has been quite focused on whether we want the user to explicitly choose a file system, or whether it should be automatically granted. We may have lost sight of the finer granularity which ChromeOS already provides: the ability for the user to choose specific files or directories.

Because I sort of agree with Tomasz that there's not much difference between a user inserting a USB stick into a kiosk versus inserting a USB stick into a kiosk and clicking "I grant access to this USB stick". What I'd really like as a user is a file chooser on my own USB stick.

I'm picturing all the times I've gone to a printer kiosk, stuck in my USB thumb drive, and got really scared that it was a) loading viruses onto my USB stick, and b) reading all of the many files I've got on there, rather than just the 2 or 3 files I want to print. With the existing fileSystem.chooseEntry API, I could be totally confident* that the kiosk is only going to print the files I choose. So while there may be some cases where it makes sense to grant full access (and/or have no user interface), I think for a simple scanning or printing kiosk, the existing APIs are perfect (and it is therefore a bit disingenuous to say "Printing kiosks. Impossible*" in the API proposal).

*Having said that, the kiosk owners could simply make a custom build of ChromiumOS, removing any confirmation dialogs, and put it on their own PCs, tricking me into a false sense of security. So perhaps this whole discussion is somewhat moot when we're talking about user security on machines they don't control.

[Tomasz Mikolajewski]

Thanks Matt for your input.

Chooser dialog is over complicated, and my users may not know what to
select when inserting a usb device, especially if the kiosk has some
USB hard disks plugged in. The chooser is also problematic for
permanently inserted USB hard disks hidden in the kiosk stand cover.
Lastly, the chooser won't work if there is no user input device.

We discussed this security concern in a separate thread and we got
into conclusion that we don't want user interaction for auto-launch
kiosk mode. We'll show the confirmation dialog for manual launch mode.
I'll cc you in the thread.

Having @benwell's earlier LGTM and resolving @jww concerns in a
separate e-mail thread I already started the implementation. We must
have it shipped in M43 as it's blocking partners, so I'd really
appreciate if we could resolve any concerns about this proposal ASAP.

Thanks,
Tomasz.

[Matt Giuca]

Hi Tomasz,

Sorry, I didn't check the dates when I originally replied to this. I thought it was an ongoing discussion and didn't realise it was settled months ago (with some additional context that I missed).

Feel free to ignore my comments in that case. But I would still be wary about allowing this API to escape from Kiosk mode, and I think it warrants further discussion if that's going to happen in the future.

Matt

[Gleb Dolzikov]

Sorry for some kind of off topic. but i have a problem related to behavior of file system in Kiosk mode,

And this topic is so close for my issue)

...my app loads video and placed it in folder which user pointed on the beginning.

Then i define src attr of video element as "media/name_of_file.mp4"

In plain mode is works well. but i don't know why. In Kiosk mode app can't find a files at all.

Do you have any ideas about it?