Opening up chrome.networkingPrivate in kiosk session

[Toni Barzic]

Hello apps-dev,

I would like to request a review of a proposal to open up chrome.networkingPrivate API to apps when they are running in Chrome OS kiosk session:

https://docs.google.com/document/d/1bqwLsTOA9jQaLth9AOoDxb_mq2tuloxXm5rpA0jnEtc/edit#

Thank you,

Toni

[Toni Barzic]

Any updates on this one?

Toni

[Steven Bennetts]

I do not have any huge concerns with making networkingPrivate available to kiosk apps.

I do not however think we should rename the API.

I would also like to request is that if a *user* installs a kiosk app that requests networkingPrivate permissions, we should clearly inform the user that the app will have the ability to add or modify network configurations.

[Devlin Cronin]

Steven knows this API better than I do, so I'll defer to him for API approval.

 

I do not however think we should rename the API.

If this (or a subset) will be opened up to kiosk apps, it really doesn't make sense to have it named networkingPrivate.  Similarly, restricted.networking doesn't really make sense.  We already have a number of APIs that are only available to a certain class of items (anything available only to enterprise-installed items, or APIs only available to [apps|extensions|hosted apps|etc]), so I'd be fine with a more generic name.

I would also like to request is that if a *user* installs a kiosk app that requests networkingPrivate permissions, we should clearly inform the user that the app will have the ability to add or modify network configurations.

+1. 

Another concern I have is that it looks like we have around a half-dozen methods here that are going to remain private.  Do you have an implementation plan that won't result in excessive bloat of APIs and feature files?

[Steven Bennetts]

Do we have a good idea of exactly which API methods would be needed for kiosk apps?

It might be worth creating a smaller subset of networkingPrivate in a different namespace (assuming we can decide on one). That would avoid having to do per method permission checks at the implementation level, and would address the "Private" namespace concerns, without having to update all of the existing whitelisted extensions (+Settings).

[Toni Barzic]

On Mon, Oct 17, 2016 at 10:11 AM, Devlin Cronin <rdevlin...@chromium.org> wrote:

Steven knows this API better than I do, so I'll defer to him for API approval.

 

I do not however think we should rename the API.

If this (or a subset) will be opened up to kiosk apps, it really doesn't make sense to have it named networkingPrivate.  Similarly, restricted.networking doesn't really make sense.  We already have a number of APIs that are only available to a certain class of items (anything available only to enterprise-installed items, or APIs only available to [apps|extensions|hosted apps|etc]), so I'd be fine with a more generic name.

Note that at the moment we cannot use chrome.network either - we already have networking.config API, and there is a bug in extension bindings registration that prevents us having nested APIs.

I would also like to request is that if a *user* installs a kiosk app that requests networkingPrivate permissions, we should clearly inform the user that the app will have the ability to add or modify network configurations.

+1. 

I think there already is an installation warning for this API (I'll double check - and maybe consider changing the warning string). I was also thinking about adding a warning when the user sets up an app as kiosk app.

Another concern I have is that it looks like we have around a half-dozen methods here that are going to remain private.  Do you have an implementation plan that won't result in excessive bloat of APIs and feature files?

As first iteration, I planned to restrict those at runtime (throw an error if those are called by a kiosk app). Most of those are methods that do not really make sense in kiosk, and later consider moving them to a separate, truly private API.

[Devlin Cronin]

there is a bug in extension bindings registration that prevents us having nested APIs.

This isn't a bug.  We don't want to have chrome.foo and chrome.foo.bar for a few reasons, an easy one being that there's no immediate way of telling if bar is an API or a method on chrome.foo.

[Rahul Chaturvedi]

​Re: naming. We really want some way to differentiate APIs that are restricted to running under any special sessions - like Kiosk, or Public Sessions, or anything else that we eventually add; from those that can run anywhere. We have restricted APIs but for an entire class of APIs that cannot be run in a general session, we usually have an easily distinguishable name (case in point, xxxxPrivate). We want users to know very clearly by looking at an API name that this is from a different 'class' of APIs. So having a distinguishable namespace for these APIs does seem very useful.

On the other hand, having an immediate way of telling if foo or bar (in chrome.foo.bar) are method names or APIs doesn't seem particularly useful. We can choose names that make it clear what is a method and what is not. For example. bluetooth.restricted.setAdapterState makes it pretty clear what is a method name and which is not. Let's discuss (preferably on another thread) the other reasons for not having the ability to have nested namespaces. I see this as a very useful feature to have.

​

[Steven Bennetts]

I agree with Devlin with this one. Having chrome.foo() and chrome.foo.bar() is pretty confusing. I also trust that team to have made the decision for good reasons.

Naming is hard. Finding a name that makes everybody happy is impossible. I try to avoid getting hung up on naming. Using chrome.restricted.bluetooth instead of chrome.bluetooth.restricted does not seem like the issue here. Whether to use 'private' or 'restricted' or 'kiosk', and whether or not to support multiple similar APIs (e.g. networkingPrivate + restricted.networkConfig) seems more relevant.

I see several options here:

A) Allow kisok apps to use chrome.networkingPrivate as-is (when in kiosk mode and with appropriate messaging when an app is user installed).

B) A + restrict which methods / events are supported in kiosk mode.

C) A + rename chrome.networkingPrivate (to chrome.restricted.networkConfig or whatever).

D) B + C

E) Create chrome.restricted.netwrokConfig (or whatever) and implement a subset of netwrokingPrivate. Leave networkingPrivate as-is.

My opinion on the above options:

A) This seems fine to me and is the easiest solution. I do not think that developers of kiosk apps using this complex and subtle API are going to be put off by the name "private", if anything it will serve as a red flag to caution developers to tread carefully.

B) I am not a fan, I don't think that the restrictions would add much benefit since we plan to expose the configuration API which has the largest security concerns.

C,D) Not a fan for reasons I have already discussed.

E) This also seems fine to me. It would allow us to potentially provide a less confusing API and it would (somewhat) mitigate the abuse (or more likely, accidental misuse) vector. There would be some extra maintenance overhead but it would be pretty low - the implementation already uses a platform specific delegate, so the new API could just use (a subset of) the same delegate: https://cs.chromium.org/chromium/src/extensions/browser/api/networking_private/networking_private_api.cc

[Albert Bodenhamer]

There's a lot of depth here. Does it make sense to move the discussion to a doc that we can iterate on?

--
You received this message because you are subscribed to the Google Groups "apps-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Rahul Chaturvedi]

Let me start another thread specifically about the naming issue - that's my main concern. I would like us to decide one way or the other; so we don't have to discuss it every time we have another API we are moving.

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

[Steven Bennetts]

There is a doc :)

https://docs.google.com/document/d/1bqwLsTOA9jQaLth9AOoDxb_mq2tuloxXm5rpA0jnEtc/edit#

There is some discussion in context there.

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

[Rahul Chaturvedi]

Moving the discussion back to the apps-dev thread.

To enumerate things I think we all agree on?

1. We'll name the API chrome.networkConfig
2. The API will be available as both chrome.networkConfig and chrome.networkingPrivate indefinitely. This is only for this API, because of certain devices that use it that may not be able to update their apps.

[Steven Bennetts]

sgtm, assuming we document the permissions clearly: Chrome OS only, component, kiosk (policy-installed?) , or whitelisted apps/extensions only.

[Toni Barzic]

Are there any objections to this proposal from security-enamel people?