Add explicit description on what should be done in incognito/private browsing mode

[leshi]

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.

[leshi]

Let's have each platform/implementer write what they're doing/planning to do.

[nadalin]

@akshayku Please fill in what Microsoft does

[kreichgauer]

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.

[akshayku]

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.

[agl]

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”.

[agl]

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.

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.

[equalsJeffH]

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:

Feature	Android	Windows	MacOS
register new credential	works only with roaming authnrs	works only with roaming authnrs	works with roaming authnrs; with platformTouchID-authnr shows warning
get assertion	works only with roaming authnrs	works only with roaming authnrs	works with roaming authnrs; with platformTouchID-authnr shows warning
isUVPAA() return value	always returns false	always returns false	returns accurate value (?)

[agl]

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.