New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: Fixed
Owner:
Closed: Nov 8
Cc:
Components:
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 mmenke@chromium.org, Oct 13 Back to list
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.
 
Cc: msramek@chromium.org dullweber@chromium.org
Cc: tnagel@chromium.org
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": https://tools.ietf.org/id/draft-ietf-websec-key-pinning-21.txt and demonstrated here: http://www.radicalresearch.co.uk/lab/hstssupercookies. There was a previous discussion here:  https://crbug.com/104935 

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 "https://facebook.com" when visiting "facebook.com" 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.


Owner: dullweber@chromium.org
Status: Assigned
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.
Cc: palmer@chromium.org
+palmer

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?
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).
(Sorry, misread an earlier comment and thought that there was confusion over this)
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.
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.
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].

[1] https://www.gothamcityresearch.com/single-post/2017/10/12/Criteo-SA-NASDAQ-CRTO-Why-We-Believe-Criteo%E2%80%99s-Undisclosed-Practices-are-Illegal-and-Harmful-to-Advertisers?utm_source=Direct
(Please ignore my question in comment #11 -- Martin kindly has pointed me to the email thread.)
Owner: mmenke@chromium.org
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 bugdroid1@chromium.org, Nov 8
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ffa8fc28a0b566571e597fafc354ca0764502c37

commit ffa8fc28a0b566571e597fafc354ca0764502c37
Author: Matt Menke <mmenke@chromium.org>
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 
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I6d8dc9447458aa5d6d628f3f7f34283209eb1a3d
Reviewed-on: https://chromium-review.googlesource.com/757181
Reviewed-by: Mark Cogan <marq@chromium.org>
Reviewed-by: Chris Palmer <palmer@chromium.org>
Commit-Queue: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514798}
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/chrome/browser/profiles/profile_io_data.cc
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/ios/chrome/browser/browser_state/chrome_browser_state_io_data.cc
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/ios/web/shell/shell_url_request_context_getter.mm
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/ios/web_view/internal/web_view_url_request_context_getter.mm
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/net/http/transport_security_persister.cc
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/net/http/transport_security_persister.h
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/net/http/transport_security_persister_unittest.cc
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/net/url_request/url_request_context_builder.cc
[modify] https://crrev.com/ffa8fc28a0b566571e597fafc354ca0764502c37/net/url_request/url_request_context_builder.h

Status: Fixed
Sign in to add a comment