-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add explicit description on what should be done in incognito/private browsing mode #1174
Comments
Let's have each platform/implementer write what they're doing/planning to do. |
@akshayku Please fill in what Microsoft does |
Chrome on MacOS keeps authenticator state per Chrome profile. In Incognito mode, the Touch ID authenticator currently is available and uses the authenticator state of the parent non-Incognito profile, but informs the user that creating a new credential would persist state beyond the lifetime of the Incognito session. In Guest Mode, Touch ID is not available. |
Basic thought I had was, having different behavior in inprivate/incognito mode and regular mode gives away the knowledge of browser's operating mode to the RP. Which all browsers strive not to do that. Above comment was for MacOS. How about Windows/Android? I would prefer a warning to the user saying about the implications of creating a credential in incognito/inprivate mode and allowing the creation of the credential on each browser. |
On the call of 2019-07-17, Akshay asked what Chrome does differently for Incognito on Windows. Based on a quick search it looks like we disable platform authenticators in that case. There we link to this Chromium bug which basically says “we should figure this out”. |
We certainly don't want to create an isIncognito() call. Thus easily observable behaviour changes that result in a low-noise analog of isIncognito() are bad. I think registering / asserting a credential is abrupt enough that it doesn't count as “easily observable” (so long as there's no silent failures that are distinguishable), so it's isUVPAA that's the major worry. For Android and Windows, isUVPAA returns false in Incognito. This is a signal, but it's very noisy and thus hopefully useless for sites trying to figure out whether a Javascript context is in an incognito session. As Martin notes above, we do support platform authenticators on macOS with warnings. I think the reason that we don't do something similar for Windows and Android is a lack of ability to conveniently show such warnings. |
attempting to summarize the above such that we might address this issue by including said info in the spec in a Note (pls review the below): Chromium behavior in incognito mode:
|
From the call of 2019-07-31: We agree the putting some language in the spec about this, and aligning user agents' behaviour, makes sense. I think that language should be non-normative because I'm worried about introducing normative language around something that has hitherto been implementation defined. We lean towards a system of notice about the persistence of credential creation rather than one of forbidding creating credentials in private modes, or one of making credentials ephemeral. |
+1 |
I think this can be addressed in a milestone later than wd-03 |
Web users should probably have the consistent experiences around using incognito/private browsing mode on all browsers.
This is especially relevant to platform authenticators. As an example, Chrome on OS X integrates with Touch ID and stores state. That state will get cleared when the user clears browser data. This is not the case with platform authenticators provided by Windows.
Another interesting situation comes up around creating platfrom authenticator credentials in incognito. In some browsers it will persist, in others it wouldn't.
The text was updated successfully, but these errors were encountered: