Interesting that I've also seen complaints from users in this setup that they DON'T get 2FA prompt on every sign in.

zalcorn@ AFAIK this is controlled from the GAIA side. We should decide what we want the behavior to actually be and work with GAIA to make it happen.

Could you go into those complaints, and the perceived threat, in more detail? Do the users want their locally-synced data to be protected by 2FA? (If so, that doesn't really work, since taking the device offline prevents from being able to use 2FA, and I assume that we don't want to break offline signin...)

#CBC-RS/TC-watchlist This has been the 2FA behaviour since forever and has confused many users in the forum.

Let me chat with GAIA and security about what the desired behavior is.

@rkc, any thoughts about what we can do to bring consistency here? I think not requiring 2FA upon sign-in without pods unless GAIA asks for a re-auth is the right UX here.

zalcorn@, we basically can't disable 2FA, because after user turns off 'show user name and photos on the sign-in screen', each time at sign-in screen they need to go through the 'Add new user' flow, which is controlled by the GAIA side. Another side effect is, if the device goes offline, because GAIA page is unavailable, no one is able to sign in anymore until it gets online again. 

What is the rational of hiding user name and photos? If it's different from adding a new user from scratch then we need to change its implementation, but first we need to have a new UI to replace the GAIA page.

> Another side effect is, if the device goes offline,
> because GAIA page is unavailable, no one is able to
> sign in anymore until it gets online again.

IIRC, this isn't what I saw. When I was in offline mode, I was able to sign in using just my username and password.

> What is the rational of hiding user name and photos?

I think the main motivation is privacy, specifically not wanting to disclose your account name(s) to an attacker who gains access to your device while it's turned off.

derat@, I tried several times, but I only see the network selection page at the sign-in screen, after turning off 'show username and photos..' and going offline. I think that's because the current implementation of hiding username and photos is simply to call 'add new user'. I think we actually need a UI to hide username and photos but still use normal login user flow behind the scene.

Thanks for testing it! Do you know if the implementation changed recently? I haven't needed to enable this setting since M55.

If the implementation now prevents offline signin, that's unfortunate, because it seems like it makes the device unusable until there's an available network once the setting has been enabled. Do we still allow guest sessions?

derat@, you are right. The network selection page still provides offline sign-in and guest session links. Then do you think we can replace the HandleShowAddUser() call here:
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/chromeos/login/signin_screen_handler.cc?type=cs&l=1063

with HandleOfflineLogin() (or a new function with similar logic):
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/chromeos/login/signin_screen_handler.cc?type=cs&l=1224

AFAIK, offline GAIA works both offline and online and it only allows existing users to sign in without showing username and photo, which might be more appropriate here. What do you think? (One downside I can think is that, we need to show 'Add new user' button at the bottom, however users might ignore that and think they can add new user by using the offline GAIA because it appears to be the same with normal GAIA)

@zalcorn, after offline discussion we think showing offline GAIA and 'add new user' button together is confusing. If you think the above solution is fine though please reassign it back to me, otherwise we'll remain the current implementation for now.

Agree it's confusing. Let's look at a more comprehensive solution at a later date, we have many higher priorities at the moment.

 Issue 749726  has been merged into this issue.

 Issue 793597  has been merged into this issue.

Just a heads up that some users would like this method of forcing 2FA to remain.

This user visiting the Pixelbook forum just this week was looking for just this solution, for example:

https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/pixelbook/Bf8pEPcaBL0/wINcs7sXBAAJ

- Mike

If we want to provide a way for users to request that two-factor auth always be used when signing in (which will make it impossible to sign in while offline), there should be a separate setting for that. It shouldn't be tied to the unrelated concept of whether usernames are shown on the login screen or not. The fact that these are correlated right now sounds like it's just an artifact of the way that username-hiding was implemented.

Tangentially, I don't know what the implications of requiring 2FA are for on-disk user data. Won't it still only be protected by the user's password, limiting the utility of this? Would an "Always use ephemeral accounts" setting that discards the cryptohome on logout be a more effective way to force 2FA?

I would definitely prefer to have my Pixelbook prompt me for my second form of auth when I initially sign onto my Pixelbook. It is nice to have the extra layer of security at login in case my Pixelbook gets lost or stolen. It'll take more than just my password for a malicious user to get into my account.

I agree with Dan, these are two orthogonal concerns. Hiding or showing the pods should be independent of asking for 2SV for logging in.

This issue is concerned with the fact that hiding user pods changes the way we authenticate users, which sounds like a bug that should be fixed.

Independent of this, we should consider giving users the option to have the system always ask for 2SV when logging in. Dan is correct that this doesn't change the protection level of on-disk data -- the key for that does not take any input from the second factor.

It's weird that hiding user pods would put you in a situation where you would not be able to log in again until you're online. That is a bug. We should fix it.

So in fact you can log-in offline with hidden pods, and it skips 2SV - so all the current pods setting is currently providing is the illusion of 2SV on sign-in.

One way to fix this would be to always default to the offline sign-in when pods are hidden and only go through the full GAIA flow on password change or expired credentials.

Ah interesting thanks for the context. If we're not putting the user in an non-login-able situation, I think this is less urgent.

Ideally we'd still be able to completely detach 2SV from showing or hiding the pods. Is there a reason why we cannot do that?

(Bulk Edit) Adding the new conops Chrome OS hotlist to all open issues with the "#CBC-RS/TC-watchlist" tag, our former tracking tag.

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

Still an  issue 71 .0.3578.94
11151.59.0 (Official Build) beta-channel samus

Yep, this is still making 71.0.3578.94 (on the stable channel) harder to use for me too.