New issue
Advanced search Search tips

Issue 774643 link

Starred by 2 users

Issue metadata

Status: Fixed
Closed: Nov 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment

Clearing non-incognito data results in retainining history in incognito's TransportSecurityPersister

Project Member Reported by, Oct 13 2017

Issue description

If you open an incognito window, and then clear all non-incognito data (Including cache), then the incognito window will still retain transport security data from your non-incognito browsing history.  The data will be cleared on the last incognito windows is closed.

This is because incognito profiles load the main Profile's TransportSecurityState from disk, though they don't save anything to it.

This behavior seems weird and unexpected, though being able to actually exploit this in any privacy relevant manner seems unlikely.

Comment 1 by, Oct 16 2017

I believe this is working correctly. Cookies created during an incognito session are also not deleted if you delete cookies with Clear Browsing Data, so not resetting HSTS entries doesn't create a privacy problem.

I wonder if it is really necessary to inherited HSTS entries by incognito mode. It can be used to identify users as described in section "Privacy Considerations": and demonstrated here: There was a previous discussion here: 

Maybe we can apply HSTS entries from regular mode only for the first request of navigations from the omnibox and not for further requests from the content area?

This way you would request "" when visiting "" but a site would not be able to read its hsts cookie via javascript? facebook will then be able to set an hsts entry for incognito that is used for all further requests. I have no idea how to handle public key pinning though.

Status: Assigned (was: Untriaged)
Indeed - Clear Browsing Data dialog opens in the regular mode, same as most other settings pages, and thus deletions generally only affect the regular mode. We don't consider this to be a problem, as deleting Incognito data is trivial (by closing all windows).

I'll leave the rest of the discussion to dullweber@ and tnagel@, but the idea of respecting the HSTS cookie but pretending it's not there generally SGTM.

Comment 4 by, Oct 16 2017


From go/incognito-mode: "Don’t share sensitive / identifying information between the regular session and the incognito session without explicit user action and intent."

Imho it would be surprising for users to be identifiable to a website when browsing in incognito mode and we should avoid that. Conceptually, an incognito window should behave like a fresh browser profile. Sites that care about security need to handle this situation already (people are coming online with fresh profiles all the time) thus we're not creating any new situations or surprises there, and with HSTS preloading there's a readily available method to configure HSTS for fresh browser profiles.

Chris, what's your take? Do you think it's a reasonable request for sites to preload HSTS when they care about the fresh browser case?

Comment 5 by, Oct 16 2017

Note that this is history from the non-incognito browsing session that's retained.  (i.e., incognito transport security state is seeded with non-incognito transport security state).

Comment 6 by, Oct 16 2017

(Sorry, misread an earlier comment and thought that there was confusion over this)

Comment 7 by, Oct 16 2017

My view is the same as you can see in  Issue 104935 . (We, and I, went back and forth on it.) Until HSTS fingerprinting is a well-known thing in the wild, I'd rather have the marginally-better protection of inheriting HSTS state. That said, it's also true that sites have to plan for new client profiles with no state.

Another idea would be to make Incognito mode always try HTTPS first, only falling back to HTTP after the HTTPS request times out. Probably performance people wouldn't like that. :) It's probably best to get that functionality with an extension, which is thankfully trivial to write.

Comment 8 by, Oct 16 2017

Trying HTTPS first would also break sites that have an HTTPS version that isn't fully functional - I've seen multiple sites like this (Maybe they're in the process of setting up HTTPS, or maybe they're using a hosting service which set it up, but then didn't do all the configuration on their end.  Or maybe there's some other reason for it).  I've also seen sites that were only partially functional over HTTPS.

Comment 9 by, Oct 16 2017

Contrary to what I said in #7, it seems at least one entity (Criteo) is now doing HSTS supercookies. Maybe that's enough to tip the balance of policy interests the other way, and to stop inheriting HSTS/HPKP state.
Also see Issue 620500 (inheriting cert error overrides)

> Another idea would be to make Incognito mode always try HTTPS first, only falling back to HTTP after the HTTPS request times out. Probably performance people wouldn't like that. :)

Issue 451295 (Make it easier to input/default HTTPS using the keyboard) :-D

> Contrary to what I said in #7, it seems at least one entity (Criteo) is now doing HSTS supercookies.

That's a bit disoconcerting.

Since most high-profile domains with dynamic HSTS now also preload HSTS, I think the benefit of inheriting HSTS values is a little lower than it used to be. Users presumably also expect the incognito profile to have some separation.

I would suggest that we only apply inherited HSTS for top-level navigations, but that is probably far too messy to implement. Removing the inheritance sounds *okay* to me.
What's the process for making decisions like that? Can we go ahead and make the change or should we seek consensus in a broader forum?

FTR: Criteo HSTS supercookie reference [1].

(Please ignore my question in comment #11 -- Martin kindly has pointed me to the email thread.)
After some discussion, we decided to remove sharing HSTS with incognito (Though perhaps we should use HSTS for omnibox navigations in incognito, that would have to follow another path).
Project Member

Comment 14 by, Nov 8 2017

The following revision refers to this bug:

commit ffa8fc28a0b566571e597fafc354ca0764502c37
Author: Matt Menke <>
Date: Wed Nov 08 11:22:15 2017

Don't use on-disk HSTS information for incognito requests.

This information can be used to fingerprint the browser in a way that
lets sites correlate non-incognito sessions with incognito sessions.

Bug:  104935 ,  774643 
Change-Id: I6d8dc9447458aa5d6d628f3f7f34283209eb1a3d
Reviewed-by: Mark Cogan <>
Reviewed-by: Chris Palmer <>
Commit-Queue: Matt Menke <>
Cr-Commit-Position: refs/heads/master@{#514798}

Status: Fixed (was: Assigned)

Sign in to add a comment