After several discussions, it seems that the best way forward is to add the device requisition to the install time attributes in the device policy.

(For M-59, we're using a hack to determine if a device is a CfM - see issue 707892).

Toni, let's see if we can get this into M-60. I would like to get rid of our hack in session_manager as early as possible.

Toni is not going to be able to work on this for M-60 due to other deadlines.
If someone on the CfM or GVC teams can pick this up, please feel free to.

We can provide design reviews and code reviews. We should be able to pick this up again in M-62.

One more quick note - we do not want to increase dependence on the hack that we have. So until we have this landed, we cannot add any more code that needs to check if a device is a CfM. The current hack was meant as a temporary solution and will stay as such.

After taking a look at this bug, I feel that I'm still missing a bit of background.

From my understanding, the current "definition" of a CfM device is:
(1) USE flag is enabled: cfm_enabled_device
(2) An auto-launch kiosk app is enabled with a hash matching one of the values in kChromeboxForMeetingAppIdHashes

Currently, this functionality is built as a temporary "hack" in libpolicy with this CL:
https://chromium-review.googlesource.com/486081

Based on the few comments in this bug, it seems that the general consensus is that we should remove this hack, and "add device requisition to the install time attributes in the device policy" instead.

Looking around, I can find two pieces of Chrome OS code with install attributes:
http://cs/chromeos_public/src/platform2/cryptohome/install_attributes.h
http://cs/clankium/src/chrome/browser/chromeos/settings/install_attributes.h

I haven't done any research to understand what the difference is between these two, and I'm not sure which one we would like to use for the purpose of this bug.

Assuming we do know which one to use, the other question I have is:
* Based on my understanding, kiosk apps can be re-configured either on the device itself by the device administrator ("Consumer devices"), or through a web interface by the enterprise administrator ("Enterprise devices").
* In both cases, the CfM kiosk app could be removed, disabled, or re-configured without auto-launch enabled.
* If the state of a "CfM device" can be enabled/disabled, then will the "install time attribute" be accordingly turned on/off?  Or are we saying that, the first time a CfM device is enabled, this attribute will be permanently turned on?

Both those pieces of code do the same thing - access install time attributes. One is part of Chrome browser, the other is part of Chrome OS hence they have different sources and different utility functions.

Once we make device requisition part of install time attributes; that means as long as the device is enrolled in a CfM domain, it will be a CfM. If someone wants the device to no longer be a CfM, they'll need to powerwash it and not enroll it in a CfM domain.

I think we might want to address the blocking bug before M-63. Lowering audio latency significantly is a very good thing for our users.

If this is fairly trivial can you outline a solution to itspeter@/kitching@/both so that they can help get this out of the way? I also think we need to consider a migration path for existing CfMs so that existing CfM units are considered enrolled after this hack is gone. We're not interested in this hack either and would like to pitch in to remove it (if it doesn't come with too much overhead for us to do).

If this has a non-trivial learning curve and generates a lot of busy work, can we not make use of chrome_setup.cc::IsEnrolledChromeboxForMeetings (but keep the use of this hack limited to both this file and usage of this function) for bugs that are blocked on it (and need a quicker resolution)?

chrome_setup.cc::IsEnrolledChromeboxForMeetings doesn't even have a test. Unless we have product blocking reasons, I would rather we invest our energies in fixing this the correct way.

The last time we made an exception due to a blocking bug. If we keep making an exception for the same thing, it isn't really an 'exception' anymore :)

Sure, that's fair if we can commit to a timeline for this fix. New features requiring this feature will pop up from people who are not familiar enough with the code to fix it in a timely fashion (the blocked bug might be one, but it's not clear that they 100% need to check for CfM presence).

If the fix is non-trivial I think there's both risk and significant rampup overhead to consider for someone unfamiliar with the code to fix it. If it's fairly simple then can you or someone on your team outline steps to itspeter@/kitching@ who're willing to pitch in and help out?

The fix is not trivial but the only reason this code went in was as a one-off hack. A one off means just that, one time.

If any engineers are available to pick this up, they are free to do so. My team can provide guidance for them to fix this but we can't commit to doing this ourselves till M-63.

Drew, this bug is now high priority since CfM will need to add more code to outside of Chrome which will need to know if the device is a CfM or not.

Since this is purely enterprise related, is this something in your team can look at?

In general, I don't think checking requisition codes is the right path for controlling behavior, we should control this stuff (like setting cmd line flags on renderer processes) via policy that we automatically set for CfM devices - that lets us potentially also use that policy elsewhere on other platforms when appropriate.

What's the actual blocking bug here?

In CFM, we intend to make sure of this to enable extra logging to make sure our products are as reliable as possible and remedy itself if something goes wrong. The ChromeOS team is not keen to enable those in all ChromeOS machines. This was captured in crbug.com/710249. Once this is in place, we would be able to do other things like optimizing audio latency in crbug.com/754198. 

For issue 707892, one this is in place, we will have to remove the one time hack to enable MediaStreamTrackContentHints.

@atwilson: Certain things the CfM folks want to be able to do is, conditionally apply certain flags at startup on only a given subset of boards, if they are requisitioned as GVCs.

A hypothetical example; if a Bluestreak device has a firmware issue with the camera, the team would like to be able to add a flag only to the Guado board if the device is a CfM, which would disable features in Chrome depending on this camera that they would like to remain enabled on other boards.

Additionally they would like the option to do things like start a certain system service, or send a USB command, etc, based on whether a device is a CfM or not.

Granted these cases don't exist yet, but if we don't implement the ability to know whether a device is a CfM or not, when the requirement comes, we'll be scrambling then to implement this. Or we'll just end up using the same hack that we have in place now, which I would really like to avoid.


This approach was suggested by Mattias as the cleanest and most secure way to determine whether a device is a CfM or not. The requirement to be able to do so is likely to come up in more cases than currently exist. I am open to any suggestions other than literally checking for the app ID of Hangouts in the device launch policy (including a policy based solution if it is feasible).

Understood, but I'd prefer to have that information controlled by policy, not controlled by install attributes (and specifically, controlled by policies like "EnableUSBLogging" and "EnableMediaStreamTrackContentHints" and not "DeviceIsCFM" - it prevents re-use of these features for other kiosk use cases if we're baking logic specifically around CfM devices).

Additionally, we can't add stuff to existing install attributes without having to powerwash and re-enroll those devices, so it seems like a bad path forward in general to rely on a CfM flag living in IA.

Happy to help add those new policies, which CPanel can enable/disable automatically based on the board info sent up during enrollment. Are there other blockers for the policy-based approach that I'm not aware of?

There will be features that trigger security and privacy requirements of "only for CfM". I don't think we can rely on policies to enforce this, since that outsources the decision to a server (and there already are 3rd-party integration points on the server side, so it's not unthinkable that we accidentally allow these policies to be enabled on non-CfM devices.

For example for EnableUSBLogging, I think there'd be privacy concerns if this was functional on non-CfM devices. There were also some use cases around native code to support CfM features that I have a strong interest to hard-disable on non-CfM devices. I don't remember all details though, perhaps rkc@ can comment to give us a full picture.

Regarding blockers for the policy approach, we'd have to go through launch reviews (security/privacy) for features that are gated to CfM-only to assess what is sufficient to switch via policy only.

I'm happy to engage with Security and Privacy teams around EnableUSBLogging, as I'm pretty confident that anything we'd enable for CfM we'd want to be able to enable for kiosks in general. We should do the hard work up front to make this secure enough for our other kiosk offerings instead of taking a shortcut and trying to bake it only for CfM.

My point is that I think we're making a mistake thinking of CfM as a unique platform with custom functionality, and we're already paying the price for that in other areas (for example, trying to share reporting infrastructure given that CfM has their own reporting infra). I'd like these asks from CfM to be treated as kiosk platform asks wherever possible and not as custom engineering work that our platform team is somehow absorbing.