Can we combine this with issue 606417? There, it proposes to add a "session" : "kiosk" feature permission so that we can mark an API to be available to kiosk session. With that, we could then just update our features json to make any API available to kiosk mode.

Yes, I think that would make sense.

I think you meant this in the description, but to be clear, this should be for *certain private APIs* only.  We certainly don't want to expose a good number of private APIs to kiosk apps.

The only private APIs we wouldn't want to expose would be very app specific APIs like maybe EasyUnlock. If we can make a use case for there being more than one app that needs to use an API, it should use the kiosk permission.

Some (most?) private APIs are designed to be used only within chrome, and, if used improperly, could probably brick the machine or put it into quite a weird state.  Do we really want to expose that functionality?

If a private API can be misused to brick a machine, we might want to reconsidering having that API at all - and/or, not make it available.

Let's see the list that Toni proposes and then parse it with these constraints (is general enough, can brick a machine, etc) in mind.

@6 - that's my point.  We *don't* want to make it available. :)  These can be APIs that are *only* used within Chrome - such as for use by the chrome settings page - and thus don't heavily validate input, etc.  They aren't all just used by apps.

#7: don't use Settings as a scapegoat :-P If an extension API that was created for (or is used by) Settings doesn't properly validate input that could break something, I'd call that a bug. We specifically considered when making these APIs how they could be useful for other purposes. I don't think we acted like "private" meant "Chromium authors only" so much as "authorized agent only".

re #5-#7
If a device is being used in kiosk mode, running a particular app is the PURPOSE for which the machine exists. It's very different than a user installing something onto a general purpose machine.  We can and should allow such apps a bit more control than most apps would get.

We obviously need to vet things WRT to that threat model and not just throw the door wide open, but the point here is that the kiosk threat model IS different.

Examples:
1: An API to allow a kiosk app to turn ChromeVox on and off.  This is perfectly reasonable for a kiosk app. A kiosk app will want to integrate its own accessibility UI. We should enable that. We wouldn't expose such control to a normal app or extension though since the potential for bad behavior is too high.
2: An API to allow arbitrary access to all physical disks. No WAY should we allow such a thing.

Make sense?

@13, 14 My concern here largely boils down to the fact that many private APIs were originally written with the intention of internal use.  This means that we were probably a bit more lax with the implementation in many cases.  Additionally, and importantly, it means that the API review these went through, if any, was likely less stringent.  Previously, many private APIs didn't require documentation, scalable design, etc, because we didn't need external devs to understand them and if something needed to change, we could do so without risk of breaking backwards compatibility.  If we expose these, then we bind ourselves to whatever implementation exists.  As such, each deserves a close look to see if it meets the same requirements we would have of any new API we introduce to the platform.

You're assuming an intent to bulk move private APIs to public in some blind fashion. That's not what we want to do here.

For any API we want to make available in kiosk mode we should review it as though it were newly created.

Cool.  As long as we're on the same page that the APIs we expose are not going to be copies of the private APIs that exist now, that sgtm.