Add an origin attribute called 'firstPartyDomain'.
This value will be extracted from the URL bar.
And the purpose of this attribute is used to isolate the data-jars.
Please see the tor documentation.
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability
The idea is like a superset of 'reject third party cookies', but not
only apply for cookies, it also applies to all data-jars like localStorage,
indexedDB and so on.
So basically an iframe will have its own data-jar, and this data-jar is
isolated by the URL from URL bar, for instance, an iframe
https://facebook.com inside https://cnn.com won't share data-jar with
the iframe (https://facebook.com) in https://bbc.com
Add an origin attribute called 'firstPartyDomain'.
This value will be extracted from the URL bar.
And the purpose of this attribute is used to isolate the data-jars.
Please see the tor documentation.
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability
The idea is like a superset of 'reject third party cookies', but not
only apply for cookies, it also applies to all data-jars like localStorage,
indexedDB and so on.
So basically an iframe will have its own data-jar, and this data-jar is
isolated by the URL from URL bar, for instance, an iframe
https://facebook.com inside https://cnn.com won't share data-jar with
the iframe (https://facebook.com) in https://bbc.com
Add a ChromeOnly method called 'setOriginAttributes' on the XMLHttpRequest,
so that we can override the origin attributes for those XHRs running by XUL
(which will use System Principal).
This change renames OriginAttributes.mInBrowser to mInIsolatedMozBrowser and
nsIPrincipal::GetIsInBrowserElement to GetIsInIsolatedMozBrowserElement. Other
methods that pass these values around also have name changes.
Tokens such as "inBrowser" have previously been serialized into cache keys, used
as DB column names, stored in app registries, etc. No changes are made to any
serialization formats. Only runtime method and variable names are updated.
No behavior changes are made in this patch, so some renamed methods may have
nonsensical implementations. These are corrected in subsequent patches
focused on behavior.
MozReview-Commit-ID: 66HfMlsXFLs
The ServiceWorkerRegistrationInfo's principal is the principal of the document
that called register(). If we create WorkerPrivate instances based off of
this, they have a valid principal in terms of security and same-origin-ness,
but the URI path is wrong. When fetching the script from the network, the
channel's principal is used to update the worker principal. We need to do the
same when the script is loaded from Cache. This patch adds support to store the
channel principal in the cache.
--HG--
extra : rebase_source : e7d527335aa4f0d4ee52e58915c8b0ef4ad26983
We also provide an opt-out for the original behavior, and use it in various
consumers that look like they need fixing up. Most of the usage here is in
code with persistence considerations, where we may need some sort of migration
path.
Jonathan Hao
Yoshi Huang
Sebastian Hengst
Kan-Ru Chen
Rob Wu
James Andreou
Jan Varga
James Andreou
Kris Maglione
J. Ryan Stinnett
Christoph Kerschbaumer
Nigel Babu
Bobby Holley
Stephanie Ouillon
Wes Kocher
Henry Chang
Carsten "Tomcat" Book
Steven Englehardt
Nikhil Marathe
Andrea Marchesini