Skip to content
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

Closed
leshi opened this issue Mar 8, 2019 · 11 comments
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. subtype:impl-cons type:editorial

Comments

@leshi
Copy link
Contributor

leshi commented Mar 8, 2019

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 leshi added this to the L2-WD-01 milestone Mar 8, 2019
@equalsJeffH equalsJeffH added type:editorial subtype:impl-cons privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. labels Mar 20, 2019
@equalsJeffH equalsJeffH modified the milestones: L2-WD-01, L2-WD-02 Apr 17, 2019
@leshi
Copy link
Contributor Author

leshi commented May 29, 2019

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

@nadalin
Copy link
Contributor

nadalin commented Jun 12, 2019

@akshayku Please fill in what Microsoft does

@kreichgauer
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

agl commented Jul 17, 2019

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
Copy link
Contributor

agl commented Jul 17, 2019

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
Copy link
Contributor

equalsJeffH commented Jul 31, 2019

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
Copy link
Contributor

agl commented Jul 31, 2019

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.

@nadalin nadalin added the stat:puntable Issue or PR that is candidate to move to a later milestone label Oct 30, 2019
@nadalin nadalin modified the milestones: L2-WD-02, L2-WD-03 Oct 30, 2019
@akshayku
Copy link
Contributor

akshayku commented Jan 8, 2020

+1

@equalsJeffH
Copy link
Contributor

I think this can be addressed in a milestone later than wd-03

@nadalin nadalin removed the stat:puntable Issue or PR that is candidate to move to a later milestone label Jul 21, 2020
@equalsJeffH
Copy link
Contributor

On 2020-09-30 call:
@agl notes that having normative recommendation here is probably not approp. haven't recently heard complaints regarding this. behavior in incognito mode is typically browser-specific. closing it is fine.
@akshayku does not think this belongs in webauthn spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. subtype:impl-cons type:editorial
Projects
None yet
Development

No branches or pull requests

6 participants