Would like to see this feature implemented so raising priority.

Please file test review ASAP, no need to wait for code complete.

To file test review:
1- File a test review request at: http://go/cros-launch-test
2- Set the test review request as blocking of this launch bug.
3- Add testreview-{bugNumber} label

Test review contact will be kmshelton@

Mattias, is this something that you think Allen can take a look at?

Current security perspective: The existing implementation we use for Google corp is not compatible with our Chrome OS user isolation story. More background here: https://docs.google.com/document/d/1CjnW8n4JfI4Ffi9xtV0RB-1tZQVVe8yedFUT2Yny76c/edit 

This needs to be figured out before launch, so flagging Launch-Security-No for now to raise awareness.

Given security-no and that implementation hasn't started, punting to M67.
We'll build the intended UI to work with the experimental Google corp version, but hold off on any public launch until security concerns are resolved.

> Launch-Security-No
> Current security perspective: The existing implementation we use 
> for Google corp is not compatible with our Chrome OS user isolation story.

Given this was the UI bug, I don't think the pointed limitation really affects it.

(and btw, the 'existing implementation' works *exactly* the same way as a Yubikey nano which is blessed, so 'not compatible' is a strong stance for the desired enhancements)

> Given security-no and that implementation hasn't started, punting to M67.
> We'll build the intended UI to work with the experimental Google corp version,

the PRD was stating that the corp version was P0.

> Given this was the UI bug, I don't think the pointed limitation really affects it.

Is there a separate launch bug for the systems part? I'm happy to follow up there if that is more appropriate.

> (and btw, the 'existing implementation' works *exactly* the same way as a Yubikey nano which is blessed, so 'not compatible' is a strong stance for the desired enhancements)

The difference is in built-in vs. external and the user expectations (as described in the doc)

> the PRD was stating that the corp version was P0.

Corp as in google corp? Or for enterprises? The security team is OK with the former (where the security model tolerates always-connected or built-in devices), but not with the latter (where security keys are generally seen as per-user 2FA).

cbrand@google.com for his perspective as well.

change launch-test to no due to lack of test review.  test review can be filed at http://go/cros-launch-test

Please see instruction else where in this bug. 

Hey folks, is this still scheduled for M68? Should we update launch-status? It's not asking for anyone to review this yet, and we've been slipping a couple of releases already? Anything I can do to help?

This has been on the back-burner until we can figure out how to address the concerns in comment #10. Even if we just shipped the UI, only Googlers would see it, so it's not a high priority IMO.
Hoping to dig into this deeper in the M70 timeframe. Any particular reason to try and get it done sooner?

FWIW, vpalatin@ and me have been iterating on a design that should cover the user binding aspect: https://docs.google.com/document/d/1oxyuzcJTn_E8njz4U0WgBs0YG3jMPhalqy7ZcPQPsUc/edit#

kerrnel@ was interested to chip in on the implementation work, but I'm not aware of ongoing implementation work yet. At this point, there's no launch timeline we can commit to.

Just getting this UX fix in for Googlers would already be a *huge* win IMHO, especially since I don't think the UX work here is any more than an hour or two. Implementation of this of course is a different story, but I don't believe we should block the UX design just because of this. Is this bug just about the UX updates to CrOS, or is this for the full feature?

It's also not quite true that only Googlers are seeing this flow: *many* of our strategic enterprise customers have turned this on using the debug flags (including Reed Hastings, CEO at NetFlix). They're aware of the caveats (don't share the device with others, etc).

This Launch bug covers the entire feature.

We've added two new bits to the Launch template - Launch-Exp-Leadership and Launch-Leadership - to capture leadership approval for new features.  The Launch-Exp-Leadership bit is meant to capture approval for Finch-based experimentation in the stable channel.  However, since Chrome OS tends not to use Finch to experiment in the stable channel, setting this bit to NA for all Chrome OS-only launches.

Ping amineer@ with any questions / concerns.

Per updates to go/newChromeFeature, setting new Launch-Leadership bit (meant to capture leadership approval) to NotReviewed.  Ping amineer@ for questions.

[Bulk edit]: converting my launch bugs without target milestones to Feature Requests for better organizational sanity. They will retain Restrict-View-Google. Please ping me with any issues.

[bulk edit] moving OOBE/Login Feature Requests to Jesse.