1564457 - Cache persists to private session, which can leak personal data

Status: RESOLVED INVALID

(Core :: Networking: Cookies, defect)

Description

[Aaron Tagliaboschi]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

1. Go to http://lucb1e.com/rp/cookielesscookies/
2. (Optional) enter unique information to text field
3. Go to same url in private session

Actual results:

The unique information entered and number of visits consistent across regular and private sessions, linking them together.

Expected results:

They should be separate.

Comment 1

[Liviu Seplecan]

Hi @Aaron Tagliaboschi, I've checked the issue on two machines: Windows 10 and Mac OS X - using FF versions: nightly 70.0a1, beta 69.0b4 & release 68.0, additionally I use even the FF 67.0 release version.
=> here are the steps & results:
FF: 67.0; 68.0 release, 68.0b4 & nightly 70.0a1:

• I load the link(from step 1) in a normal window then in a private window => it shows the same number at the "Number of Visits" - see the screenshot attached.

• the Number of Visits increases only by typing each time the "Store" button.

• So, in conclusion describe please which in the correct - intended behavior.
  Mention that the same behavior occurs in Google Chrome.
  I will set a component to it, if isn't a proper one please fell free to change it.
  Thanks.

Comment 2

[Liviu Seplecan]

Attachment: cookies- normal & priovate window.png

Comment 3

[Honza Bambas (:mayhemer)]

Filed a separate bug 1574956 for the form filling data leaking between regular and private.

The tracking via HTTP cache etags is known. For actual third party tracking to track users cross-site this will be fixed fixed with first party isolation - bug 1536058. For first party tracking there is no defense except permanent private browsing.

Comment 4

[Honza Bambas (:mayhemer)]

Actually - this is not a duplicate, because cache is isolated properly between private and regular windows (the concern of this bug).

Comment 5

[(no longer active)]

(In reply to Honza Bambas (:mayhemer) from comment #4)

Actually - this is not a duplicate, because cache is isolated properly between private and regular windows (the concern of this bug).

FWIW this test case confused the heck out of me, until I realized that it is constructed in a way to make testing in a private and non-private window on the same machine completely useless, because of this code which computes and assigns the same ETag number (based on the UA string and IP address) every time when fetching http://lucb1e.com/rp/cookielesscookies/tracker.jpg. This test case must be ignored for the purposes of assessing whether a browser correctly partitions the private and non-private cache away from each other.

Comment 6

[Honza Bambas (:mayhemer)]

So, the cookie (etag) is actually UA+publicIP tracking/fingerprinting and its server full-state. Then yes, this is not a good test case for 1P content cache isolation as it doesn't actually distinguish browser sessions.