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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta: tor uplift: privacy.firstparty.isolate #8

Open
Thorin-Oakenpants opened this Issue Feb 18, 2017 · 17 comments

Comments

Projects
None yet
5 participants
@Thorin-Oakenpants
Member

Thorin-Oakenpants commented Feb 18, 2017

Use this ticket to discuss and track privacy.firstparty.isolate

Last updated: see changelog at foot

RESOLVED & ADDED TO USER.JS if applicable

馃敾 FF51

  • 1260931 enable First Party Isolation
    // user_pref("privacy.firstparty.isolate", true);
  • 1278037 isolate indexedDB

馃敾 FF52

馃敾 FF53

馃敾 FF54

  • 1323644 isolate HSTS and HPKP
  • 1334690 isolate HTTP Alternative Services
  • 1319773#c22 enforce FPI restriction for window.opener
    // user_pref("privacy.firstparty.isolate.restrict_opener_access", true);

馃敾 FF55

馃敾 FF58

  • 1376971 isolate Page Info media previews to content first party
  • 1376973 favicon of tabs dropdown list does not honor originAttributes
  • 1409045 extensions can control privacy.firstparty.isolate

馃敾 FF63

  • 1473247 make FPI honor IP addresses

馃敾 FF65

  • 1492607 Prevent postMessage communication across first-party when restrict_opener_access = true

NOTABLE ISSUES UNRESOLVED in STABLE

  • 1418931 - FPI & IDB clearing on close or manually via clear recent/all history
    • fixed in FF58+
  • 1381197 - FPI & cookies
    • fixed in FF59+

PENDING

INVALID / WONTFIX

  • 1312655 checkbox in about:preferences#privacy for privacy.firstparty.isolate

CHANGELOG

  • Mar 19: 1340949 (sync) 鈫 marked as closed (under list of login issues)
  • Mar 27: 1278037 (indexedDB) 鈫 added to FF51+
  • May 29: 1330467 (site permissions) 鈫 pending
  • July 4th America FukYeah鈩: 1473247 (IP addresses) 鈫 pending
  • July 16: 1475811 (entering urls in addressbar) 鈫 pending
  • July 17: 1473247 (IP addresses) 鈫 FF63+
  • July 31: 1384657 (Pocket) 鈫 pending
  • Oct 26: 1492607 (postMessage) 鈫 FF65+
  • Nov 27: 1506693 (PDFJS range-based requests) 鈫 pending
  • Dec 04: 1508355 (Save As) 鈫 pending

...

@Thorin-Oakenpants Thorin-Oakenpants changed the title from meta: privacy.firstparty.isolate to meta: tor uplift: privacy.firstparty.isolate Feb 19, 2017

Thorin-Oakenpants pushed a commit that referenced this issue Feb 19, 2017

Roman-Nopantski
removed tor uplift investigation section
I have created three issues for tracking items of interest from the tor uplift: #7 `resistFingerprinting`, #8 `FPI` and #15 `the rest`
@earthlng

This comment has been minimized.

Member

earthlng commented Mar 25, 2017

=> moved from Issue #15

@crssi commented on 21 Feb

Observation report:

  • privacy.firstparty.isolate
    Oh man, this one is a problem maker. I know, its still in development, but just FYI.
    It was somehow expected where I can find a problem.
    privacy.firstparty.isolate = true isolates session in a way that even some FF extensions stops working.
    For example "Self-Destructing Cookies" (SDC) does not destruct cookies after session, obviously SDC cannot access the session namespace.
    Haven't tested uBlocker, uMatrix, NoScript... etc.

@ghacksuserjs ghacksuserjs deleted a comment from earthlng Jun 11, 2017

@Atavic

This comment has been minimized.

Atavic commented Jun 16, 2017

SDC is unable to access private cookie jar: pyllyukko/user.js#245 (comment)

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Sep 15, 2017

I don't understand why they would want FPI enabled in PB windows but not in normal windows. (?)

because of breakage. It is better to test things in PB mode.

FPI will always have cross-domain login issues because some websites effectively use supercookies for their login flow.

Tor always uses PB mode, FPI was developed by Tor, they made it so it was used in all windows. If Mozilla were to uptake on it, they would want to trial it in PB mode

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Dec 13, 2017

Some more comments since your post 9hrs ago

FF57.0.1

test one (control)

  • new profile
  • go to https://static.raymondcamden.com/demos/2014/feb/7/index.html#/home. add some notes
  • check IDB data
    • yes, https+++static.raymondcamden.com folder exists
  • open console, clear it
  • clear via Clear Recent History>Offline Website Data (time range everything, checked item just OWD)
  • check IDB data
    • yes, https+++static.raymondcamden.com folder is gone
  • check console for error messages
    • nope, nothing

test two (FPI and Clear-All-History+OWD)

  • restart
  • set FPI true (and restarted for good measure)
  • go to https://static.raymondcamden.com/demos/2014/feb/7/index.html#/home. add some notes
  • check IDB data
    • yes, https+++static.raymondcamden.com^firstPartyDomain=raymondcamden.com exists
  • open console, clear it
  • clear via Clear Recent History>Offline Website Data (time range everything, checked item just OWD)
  • check IDB data
    • nope, https+++static.raymondcamden.com^firstPartyDomain=raymondcamden.com STILL exists
  • check console for error messages
    • hell yeah, see pic

sanitizeowdonly

UPDATE one: more testing on 57.0.1 re time ranges

I repeated both tests (control & test) from above, but this time I used use clear recent history (I used "today" as the time range)

  • exact same results, so I think we can rule out anything to do with time ranges, which has been problematic in the past

UPDATE two: more testing on 57.0.1 this time containers only

I repeated the test using containers only

  • turn on containers UI & enable containers & long press behavior
    • privacy.userContext.ui.enabled->true
    • privacy.userContext.enabled-true
    • privacy.userContext.longPressBehavior->2
  • exact same results & error messages
  • container OA'd IDB failed to be removed https+++static.raymondcamden.com^userContextId=1

FF58.0b11

Tested FPI and containers individually, and can no longer reproduce - same tests as above. No console errors and IDB entries are removed

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Jan 6, 2018

a couple hours ago ...
1381197 - RESOLVED FIXED in Firefox 59

and 1418931 seems to be fixed in 58beta: https://bugzilla.mozilla.org/show_bug.cgi?id=1418931#c11

2a2b809 - but yeah, didn't update this issue

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Mar 27, 2018

@overdodactyl reddit .. IDB was isolated in the first bug in OP 1260931 .. also see 1405884 where even Arthur forgot it was covered already

Edit: actually, it looks like it was done in FF51+ with 1278037

@overdodactyl

This comment has been minimized.

Collaborator

overdodactyl commented Mar 27, 2018

Thanks! I'll update by comment to reflect that :)

@dartraiden

This comment has been minimized.

dartraiden commented Aug 1, 2018

First-Party Isolation also breaks Pocket functionality. You cannot add something to Pocket via location bar button.

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Aug 1, 2018

just added

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Oct 27, 2018

  • 1492607 Prevent postMessage communication across first-party when restrict_opener_access = true

@earthlng Do we need to add anything this (FF65+) to 4002 ?

@earthlng

This comment has been minimized.

Member

earthlng commented Oct 27, 2018

The patch only addresses postMessage's sent to targetOrigin *.

There's a new hidden pref privacy.firstparty.isolate.block_post_message but the patch also provides some additional protection without the new pref set.

The commit title is Make postMessage aware of OAs when the targetOrigin is "*".

This patch adds a MOZ_DIAGNOSTIC_ASSERT for assuring the OAs are matching when the targetOrigin is "*" for the postMessage(). But it ignores the FPD in OA since the FPDs are possible to be different.
We also add a new pref 'privacy.firstparty.isolate.block_post_message' for allowing blocking postMessage across different FPDs.

I think that means totally unrelated and potentially malicious 3rd-party sites, which you may have open in another tab, can no longer receive messages sent between 2 connected sites. (think cross-login fe)
And you don't need the pref for that part!

The pref (default-off and hidden because it can cause breakage!) will stop the communication if the 2 sites don't also share the same 1st-party domain.

Do we need to add anything ...?

we can add the new pref but I don't think it's necessary to enable it.

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Oct 27, 2018

I'd like to add something. Anything RFP+FPI related I like to get into their respective section headers so it paints a full picture. I thought just a note under 4002 would suffice eg [NOTE] FF65+ when true... . but now it seems complicated and might be better if you word it all. Just do it and commit it, if you want.

@earthlng

This comment has been minimized.

Member

earthlng commented Oct 27, 2018

 ** 1492607 - make postMessage with targetOrigin "*" aware of OAs when restrict_opener_access = true (FF65+)
/* 4002: enforce FPI restriction for window.opener (FF54+)
 * [NOTE] Setting this to false may reduce the breakage in 4001
 * [FF65+] assures the OAs are matching when the targetOrigin is "*" for postMessage() but
 *     it ignores the FPD in OA since the FPDs are possible to be different (see [2] + [3])
 *     The 2nd pref enables you to only allow communication if 1p-domain also matches
 * [1] https://bugzilla.mozilla.org/1319773#c22
 * [2] https://bugzilla.mozilla.org/1492607
 * [3] https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage ***/
user_pref("privacy.firstparty.isolate.restrict_opener_access", true); // default: true
   // user_pref("privacy.firstparty.isolate.block_post_message", true); // (hidden pref)

or maybe a bit easier to understand:

[FF65+] blocks postMessage with targetOrigin "*" if originAttributes don't match. But
to reduce breakage it ignores the 1st-party domain (FPD) originAttribute. (see [2],[3])
The 2nd pref removes that limitation and will only allow communication if FPDs also match.
@earthlng

This comment has been minimized.

Member

earthlng commented Oct 27, 2018

oh and btw default value for .restrict_opener_access is and always has been true...

user_pref("privacy.firstparty.isolate.restrict_opener_access", true); // default: true

馃槈

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Oct 27, 2018

  • hidden pref needs to be in ( brackets ) (see all other examples in use.js)
  • can we shorten the one liner? and does using "isolate" still make sense? Just asking. "make aware of OA" = "isolate" IMO. Just asking, don't shoot the messenger
** 1492607 - isolate postMessage with targetOrigin "*" (requires 4002) (FF65+)
  • either version seems fine: except 1st version could do with evening out the lines a little bit
  • yup, add in the // default: true

I edited your draft to add default:true, brackets on hidden pref, evened out two lines

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Oct 27, 2018

2nd version is actually [edit] MUCH [end-edit] better

@earthlng

This comment has been minimized.

Member

earthlng commented Oct 27, 2018

agreed 1st version is terrible

"make aware of OA" = "isolate" IMO

yeah we can go with that 馃憤

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment