Put Kiosk App parameters into device settings.

chrome/browser/policy/proto/chromeos/chrome_device_policy.proto

Index: chrome/browser/policy/proto/chromeos/chrome_device_policy.proto
diff --git a/chrome/browser/policy/proto/chromeos/chrome_device_policy.proto b/chrome/browser/policy/proto/chromeos/chrome_device_policy.proto
index ec401572adbd55474aa1ac2f12fd2f99899d6e75..6c95ebfa338ebc33b4947482299a90a15bd11b25 100644
--- a/chrome/browser/policy/proto/chromeos/chrome_device_policy.proto
+++ b/chrome/browser/policy/proto/chromeos/chrome_device_policy.proto
@@ -226,13 +226,39 @@ message SystemTimezoneProto {
 
 // Describes a single device-local account.
 message DeviceLocalAccountInfoProto {
-  // Identifier for the device-local account. Account identifiers loosely follow
-  // the conventions for email addresses as specified by RFC 5322, e.g. local
-  // (user name) and domain parts, separated by the '@' character.
-  // Policy-configured device-local accounts are on the same domain that the
-  // device is enrolled to. In contrast to RFC 5322 (which is more restrictive),
-  // the local part may contain any characters other than '@'.
-  optional string id = 1;
+  // Deprecated: Account identifier for a public session device-local account.
+  // Old code didn't have the |type| field, so it can't handle new types of
+  // device-local accounts gracefully (i.e. ignoring unsupported types). New
+  // code should instead set type to ACCOUNT_TYPE_PUBLIC_SESSION and write the
+  // identifier to the |account_id| field below. If the |type| field is present,
+  // |deprecated_public_session_id| will be ignored.
+  optional string deprecated_public_session_id = 1;

[binzhao, 2013/04/30 22:01:10]

My understanding is that the old client has no knowledge of account type, then
it only looks at the id field and it means a public session.

For new client, if account type is not set, then it assumes it is a public
session and read it from id field. If type is set, then it honors the type and
read id field.

Not sure why we need to deprecate this and have an new field then.

[Mattias Nissler (ping if slow), 2013/04/30 23:37:37]

The issue is forward-compatibility: IMHO, old clients should ignore new account
types instead of creating Public Sessions for accounts with types they can't
handle. If unknown types default to be Public Sessions on old clients, we run
into these problems:
- We'll add unintentional Public Sessions, which will confuse users. Most
likely, the policy configuration for these accounts will be missing/incomplete,
so the Public Sessions will have cryptic account names etc. which adds to the
confusion.
- Once an old client actually upgrades, it starts understanding the new account
type. But then it may already have accumulated state for an account that was
incorrectly defaulted to be a Public Session, so there now is inconsistent
state.
- If we default to Public Session, we'll also try to fetch Public Session
policy. Currently, there is no plan to support this for Kiosk Apps, so old
clients would make unnecessary requests to the server (they'd be otherwise
harmless).

The only option I see that avoids deprecating the existing field is to make a
rule that we can only switch on support for new account types once we're sure
all old clients have been updated to understand the new type. That's quite
inflexible however, as it wouldn't allow us to test/release new features before
the client-side implementation hits the stable channel, and even if that's the
case, there might be stray devices that may take longer to update and thus run
into the issues I mention above.

[binzhao, 2013/05/01 00:30:44]

OK, I agree when admin configures KIOSK, then pre-28 devices should behave like
nothing is configured rather than going into public session mode. It also means
the cloud-side need to set both for both new and old public session to work.

But please see my comments on the protobuf enum below.



On 2013/04/30 23:37:37, Mattias Nissler wrote:

[Mattias Nissler (ping if slow), 2013/05/01 10:10:55]

Yes that'd be helpful. It's probably not strictly necessary, because we'll have
to continue supporting the deprecated field due to the data that has it which is
present in the systems. Or would you be willing to run a migration job so we can
get rid of |deprecated_public_session_id| quicker?

[binzhao, 2013/05/01 16:56:49]

Is there a good way to tell most of the devices have upgraded so it is safe not
set this deprecated field any more? We can have an offline discussion how to
migrate cases like this.

On 2013/05/01 10:10:55, Mattias Nissler wrote:

+
+  // Identifier for the device-local account. This is an opaque identifier that
+  // is used to distinguish different device-local accounts configured. All
+  // configured accounts on a device must have unique identifiers.
+  optional string account_id = 2;
+
+  // Indicates the type of device-local account.
+  enum AccountType {
+    // A login-less, policy-configured browsing session.
+    ACCOUNT_TYPE_PUBLIC_SESSION = 0;
+    // An account that serves as a container for a single full-screen app.
+    ACCOUNT_TYPE_KIOSK_APP = 1;
+  };
+
+  // The account type.
+  optional AccountType type = 3;

[binzhao, 2013/04/30 22:01:10]

we can specify the default to be ACCOUNT_TYPE_PUBLIC_SESSION then we don't need
to add a new field.

[Mattias Nissler (ping if slow), 2013/04/30 23:37:37]

See my comment above.

[binzhao, 2013/05/01 00:30:44]

Is Chromium using proto1 or proto2?

I am not very familiar with Protobuf c++. There are some known issues with
Protobuf enum in Java. If we add another enum which the old client does not
recognize, when the old client call getType(), it gets the default value. If not
default value is specified, then the first value in the enum list is returned.

As far as I remember, a good practice is defining UNKNOWN to act as a default
value.

These two threads have some details

https://groups.google.com/a/google.com/forum/?fromgroups=#!msg/protobuf-team/...

https://groups.google.com/a/google.com/forum/?fromgroups=#!searchin/protobuf-...

On 2013/04/30 23:37:37, Mattias Nissler wrote:

[Mattias Nissler (ping if slow), 2013/05/01 10:10:55]

If read the code and tested it against a proto containing an enum value the
client doesn't know. It all works out because the enum parsing code in protobuf
checks whether the value it gets from the binary message is a valid enum
constant. If not, it just skips the field and has_type() returns false.
I actually had that in an earlier (unpublished) iteration and then removed it
because I didn't need it to get what I wanted :)
Judging from these threads, has_type() is actually a supported way of covering
this case for proto2. I don't see any reason why we'd need to care about proto1,
do you?

[binzhao, 2013/05/01 16:56:49]

Right, if you check hasXXX(), then it is fine. If we don't check hasXXX(), then
we can put a UNKNOWN.

On 2013/05/01 10:10:55, Mattias Nissler wrote:

+
+  // For ACCOUNT_TYPE_KIOSK_APP, indicates the app that should be run. The
+  // string value should be a valid 32-character Chrome App identifier and
+  // specifies the Kiosk App to download and run.
+  optional string kiosk_app_id = 4;

[binzhao, 2013/05/01 00:30:44]

Do we want to define a wrapper message type - KioskAppInfo to encapsulate all
Kiosk app info?

[Mattias Nissler (ping if slow), 2013/05/01 10:10:55]

Fair, I'll do that.

+
+  // Optional extension update URL to download the Kiosk App package from. If
+  // not specified, the app will be downloaded from the standard Chrome Web
+  // Store update URL.
+  optional string kiosk_app_update_url = 5;
 }
 
 message DeviceLocalAccountsProto {
@@ -248,6 +274,12 @@ message DeviceLocalAccountsProto {
   // The amount of time, in milliseconds, that should elapse at the signin
   // screen without user interaction before automatically logging in.
   optional int64 auto_login_delay = 3;
+
+  // Whether the keyboard shortcut to prevent zero-delay auto-login should be
+  // enabled or not. If this keyboard shortcut is engaged, the auto-login will
+  // be delayed by 3 minutes so administrators can log in or make configuration
+  // changes.
+  optional bool enable_auto_login_bailout = 4 [default = true];
 }
 
 message AllowRedeemChromeOsRegistrationOffersProto {