This will let us answer the following questions (in a performant way):
1) What's the compartment's origin? Necessary to implement compartment-per-origin.
2) What's the origin's site? Necessary for the new Wrap() algorithm.
3) Has any realm in the compartment set document.domain? Necessary for the new Wrap() algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D5423
--HG--
extra : moz-landing-system : lando
nsIURIWithPrincipal is currently used to retrieve the nsIPrincipal from a
BlobURL object. BlobURLProtocolHandler has a hashtable containing, for each
blobURL, a BlobImpl and its nsIPrincipal. This patch introduces
BlobURLProtocolHandler::GetBlobURLPrincipal() that retrieves the nsIPrincipal
from this hashtable.
This patch fixes also a bug in how the revocation of blobURLs is broadcasted to
other processes. This should be done immediately because each process creates
its own timer to revoke them after 5 seconds.
An important change is related to NS_SecurityCompareURIs() where, if 1 (or
both) of the 2 URIs to compare, is a revoked BlobURL, we will QI its URL to
nsIStandardURL and fail out at that point.
We need to side-step existing cross-origin checks in Performance Timing code
when the caller is a web extension content script that otherwise has permission
to access the cross-origin resource.
MozReview-Commit-ID: 8IgtqZgPWgY
--HG--
extra : rebase_source : e8152c5d8ab32096d1ff7f97311c1b43b57c3694
The logic for choosing the principal here was originally written before
loadInfo had a separate principalToInherit field, and we needed to specify it
via the triggeringPrincipal instead. At that point, we had to choose a
component principal with permission to load the URI at the start of the
request.
However, now that we have a separate field for the principal to inherit, it's
only needed after access checks have passed and we know that we have a URI
which inherits a principal. In that case, the current logic causes us to
always inherit the first principal in the whitelist (which is the page
principal) for URIs (such as data: URIs) that always inherit, where we really
want to inherit the last (which is the extension principal).
MozReview-Commit-ID: EPoUNuOCwrH
--HG--
extra : rebase_source : 535083e3dd4598ac4e8ea187d27d61ac2ac48476
There are several ways that expanded principals can be used as triggering
principals for requests. While that works fine for security checks, it also
sometimes causes them to be inherited, and used as result principals in
contexts where expanded principals aren't allowed.
This patch changes our inheritance behavior so that expanded principals are
downgraded to the most appropriate constituent principal when they would
otherwise be inherited.
The logic for choosing the most appropriate principal is a bit suspect, and
may eventually need to be changed to always select the last whitelist
principal, but I chose it to preserve the current principal downgrade behavior
used by XMLHttpRequest for the time being.
MozReview-Commit-ID: 9fvAKr2e2fa
--HG--
extra : rebase_source : c30df1b3851c11fed5a1d6a7fb158cec14933182
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
The extension policy services uses atoms internally for permission names, so
using them directly rather than strings is considerably cheaper.
MozReview-Commit-ID: Io8EuOXHKVy
--HG--
extra : rebase_source : 577b4bdf7f899729e4cf92961a8e9e25bf886a72
Going through the extension policy service rather than using
WebExtensionPolicy objects directly adds a lot of unnecessary overhead to
common operations on extension principals, and also makes the code more
complicated than it needs to be.
We also use weak references to policy objects here, since principals should
ideally lose as much of their elevated privileges as possible once the
extension instance that created them has been destroyed (which is something we
couldn't handle easily when we simply tracked ID strings).
MozReview-Commit-ID: KDNvVdvLkIt
--HG--
extra : rebase_source : 1b567919d2461bd0315d1a7d89f330cbd585f579
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
When we load about:blank in a remote tab, it will have
LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL flag set, which will make
NullPrinicipal as its document principal. So we add
NULL_PRINCIPAL_FIRST_PARTY_DOMAIN as its firstPartyDomain.
So when we load data:, or javascript: URI in a remote tab, it will inherit the
principal from about:blank, hence also inherit the origin attributes.
There are also some about: pages will use codebase principal, so we also
set ABOUT_URI_FIRST_PARTY_DOMAIN as firstPartyDomain on their
principals.
This is meant as a temporary stopgap until we can stop using origin attributes
to store add-on IDs.
MozReview-Commit-ID: DHstOTyu7pR
--HG--
extra : rebase_source : adb8fbfaadf6e914b5aa15c2693a35056669506c
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).
caps/BasePrincipal.cpp:562:28 [-Wshadow] declaration shadows a local variable
caps/nsScriptSecurityManager.cpp:675:18 [-Wshadow] declaration shadows a local variable
caps/nsScriptSecurityManager.cpp:854:14 [-Wshadow] declaration shadows a local variable
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 bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h