>Probably what ends up happening is that shill combines both profiles
> and picks one network, ending up on WIFI_A by chance.
Note to self: If this is what really happens, the title of this bug is misleading - then the kiosk app profile would respect the changed network settings, but would merge those settings with original network settings at the time of kiosk app profile creation.

> I suspect that this is not a problem in real-world kiosk deployments because network settings tend to be set through policy(?).

That's a good point. In my particular case, I could set a Wifi SSID in the policy for my kiosk OU via the Admin console, but the network on which I'd like to run all of the production kiosks is not ideal for testing the development version of my app. Being able to switch between multiple networks would be a great help.

Two ideas: (a) the kiosk mode could honor the choices made at the login screen, or maybe even better, (b) the OS could reserve an improbable key combination like Ctrl+Alt+Shift+N that makes the network selection dialog appear.

I think this should not be treated as a bug but rather WAI. When someone presses Ctrl+Alt+S to skip the kiosk mode, they are configuring the network settings for sign-in screen and not for Kiosk mode.

Kiosk mode should honor the admin configured network. If a Kiosk app is unable to connect to the network and if offline mode is disabled for an app, then OS will show the network configuration screen. I am not sure if the network configured in the network-configuration screen will be persisted across the kiosk sessions (I would think so).

Starting M59 - we are enabling networking API for kiosk apps. This should allow the kiosk apps to show a UI to configure networks (or some logic to pick the available network)

I'm not sure I agree about this being WAI - it seems weird and counter-intuitive for a kiosk app with no policy-configured network to just slurp up the current network the first time it runs, then never allow it to change.

At least, I'd like to understand the genesis of this behavior - I'm guessing it's intentional and there's some rationale behind it that I'm not aware of.

Agree with Drew that we should think about the case that no policy mandates
network settings separately.

I think the behavior is that the kiosk session respects both
- the device-wide network config configured on sign-in screen
- the kiosk app profile-specific network config derived on first kiosk app
launch
So if the original network was not available anymore, the device would
connect to the network configured on sign-in screen later.

Ed's use case is kind of rare: the original network is still available but
he'd like the kiosk app to stop using it.

I agree that we should inherit network settings from the sign-in screen (that includes network configured on first ChromeOS device boot) when there are no admin configured network policies.

Allowing sign-in screen network settings to override admin configured network policy may lead to inconsistent behavior IMHO - e.g. Someone pressing Ctrl+Alt+S and configuring a network in the sign-in screen and hence overriding admin-configure network policy

Are we sure that sign-in screen network config will be applied when a device is unable to connect to admin-configured network policy (comment #5)? 

 

Admin-configured network policy should (and will) always win.

Sign-in screen settings should not (and will not) override admin-configured network policy.

The question is: What should happen if there is no such policy? I think this is uninteresting for production kiosk deployments (because they have policy), but interesting in Ed's developer case.

Also note that for prod kiosk deployments, the Ctrl+Alt+S/N keyboard shortcuts are probably disabled (by policy) anyway. But even if they were not, policy always wins.

So, for the case that there is no policy, there are two variables:
(1) Network settings manually set at the first time the kiosk app has been launched (usually in OOBE, but could also be done on sign-in screen before the policy with kiosk device-local account was pushed)
(2) Possibly also network settings manually changed on the sign-in profile through interruption of the kiosk app start up (Ctrl+Alt+S / Ctrl+Alt+N).

Especially: When (2) is present, should the kiosk app still continue also accepting networks from (1)?

Note that the summary of this bug is misleading, trying to come up with a better one.
Maybe "Don't cache network settings for device-local accounts without network policy" would be more precise, WDYT?

re: comment #7, what is our current behavior? Kiosk mode should be considered as user-mode for all practical purposes and hence the behavior should be consistent with user-mode.

The network setting configured during OOBE or sign-in screen should be considered as shared setting I believe. Hence, changes made to shared-setting will be reflected in user/kiosk mode?

Yes, those are shared and will be reflected, so e.g. adding new Wifi networks should not be a problem.

Ed's usecase, where it gets weird, is if you want the kiosk session to forget about a network (again, without policy):
There's no way to do that. You can edit the shared setting on the sign-in screen, but the kiosk session also remembers its own network settings and has no built-in UI to modify them. So, it looks as if you couldn't make the kiosk session connect to another network.

In other words:
Network settings in kiosk session = shared settings + kiosk session specific settings
where:
Shared settings can be modified
Kiosk-session specific settings were created at the first kiosk session start and are frozen in that state.

This usecase is probably really only relevant to people developing kiosk apps.

Just seeing this issue and figured I'd chime in with our use-case: 

We enroll our Chrome devices and load our kiosk app before sending them to our customers. For some of our customers, we don't have the WiFi info in our admin, so we ship the device to the customer and have them input it the first time the Kiosk App launches.

Pinging this bug to ask the state of networking for kiosk apps. I noticed that the network selection looked a little different on Chrome 57 recently. Is it possible somehow to change the network for a kiosk mode Chrome app?

As I mentioned in comment #2, my issue is that the network on which I would like to run my kiosks is not ideal for testing. This is because I've enabled the Inspector on test devices for debugging: I can't use that in kiosk mode, but can access it over the wireless network from another machine. However, the network on which I want to run kiosks doesn't allow peer to peer traffic, so I must change to an alternative network for testing. Under the network system that existed when we raised this bug, it's not possible to select a network in kiosk mode.