We change it from taking bool aIsCallerChrome to
Maybe<bool> aShouldResistFingerprinting. If there is
a value in there, it is used for determining RFP status.
If not, we call ShouldRFP with the provided Document.
This is needed because on a Worker, we wind up in UserAgent
with no Document, we need to pass the RFP decision in
from WorkerPrivate.
Differential Revision: https://phabricator.services.mozilla.com/D144581
Everywhere except one loadInfo is supplied to an HTTPChannel
right after it is Init()-ed. Inside of Init we would like to
use the loadInfo so we'll put it in there.
Differential Revision: https://phabricator.services.mozilla.com/D144580
Whereas previously we would pass in the principal of a document,
now we will pass in the document directly. This will work for most use
cases, but not all (like Workers.)
Additionally, for the User Agent, if we do not Resist Fingerprinting
(because there is an exemption), we will fall through to getting the
User-Agent header which uses the coarse RFP check, so we fix that in
a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D138778
Previously, this test would open a page and then enable/disable
RFP while the tab was open, writing and reading the canvas as
it went.
Now that CookieJarSettings gets initialized when a document loads
and stays constant for the lifetime of the document, we cannot enable
and disable the prefs and expect them to continue to behave correctly.
We do a 'pre-test' to populate a canvas and then get the true image
data for it. Then we set the preferences prior to loading future
documents and compare the extracted canvas data to the known-correct
data to see if we are correctly spoofing it or not.
Differential Revision: https://phabricator.services.mozilla.com/D150592
- Move ShouldRFP(char*), ShouldRFP(docshell), ShouldRFP(Document)
below some utility code.
- Now that we know we should check the CookieJarSettings, using
ShouldRFP(nsIPrincipal) is dangerous. We mark it as dangerous
and annotate the existing uses of it.
- At the same time, an nsILoadInfo has the CookieJarSettings we
want to check, so create a ShouldRFP(nsILoadInfo) that checks
it and cascades to the (marked-dangerous-but-not-dangerous-for-
this-call) principal function.
- We also correct a situation where WorkerLoadInfo does not
initialize the shouldRFP member.
Differential Revision: https://phabricator.services.mozilla.com/D150591
Previously, we initialized WorkerLoadInfo's shouldRFP member
using the Worker's principal at time of construction. It is
better to populate it from the RemoteWorkerData structure.
The RemoteWorkerData's shouldRFP member can be initialized
with the correct context.
In ServiceWorkerPrivateImpl.cpp it has the same effect, before
and after we use ServiceWorkerInfo.mPrincipal
But for SharedWorker.cpp we previously used
RemoteWorkerData.principalInfo (the second of three principal
members). This was initialized from the WorkerLoadInfo.mPrincipal
member, which in turn came from loadInfo.mChannel which in turn
came from loadInfo.mLoadingPrincipal.
Now we use the WorkerLoadInfo.mShouldResistFingerprinting member
which is initialized from
nsContentUtils::ShouldResistFingerprinting(document) in
WorkerPrivate::GetLoadInfo which can take into account greater
context which will be important in the next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D150590
Now that the ShouldRFP member is correctly populated (we hope)
in CookieJarSettings, we can use it in our ShouldRFP methods.
There are two general scenarios:
An exempted domain frames a non-exempted domain.
The inner frame should be non-exempted.
A non-exempted domain frames an exempted domain
The inner frame should be non-exempted.
In the first scenario, CookieJarSettings.shouldRFP member
will be false (exempted.) We clearly cannot blindly rely
on the member, it would be wrong here.
In the second scenario, CookieJarSettings.shouldRFP member
will be true (non-exempted). This is the scenario we really
need CookieJarSettings for.
----
We take the opportunity to add an additional check for the
'exempted domain framed by a non-exempted domain' scenario.
This additional check takes advantage of the first party
isolation key (for FPI) or partition key (for dFPI).
Differential Revision: https://phabricator.services.mozilla.com/D150589
CookieJarSettings frequently gets populated in a place
where we have ready access to the Document/Channel it
is being constructed for. This lets us populate the boolean
and pass it into CookieJarSetting's constructor easily.
When it is created for LoadInfo, we need to plumb the URI
through by adding it to LoadInfo::CreateForDocument.
Differential Revision: https://phabricator.services.mozilla.com/D150588
Before we took a very simplistic view to domain-based RFP
exemptions - if the loading principal said an exempted
domain, you were exempted.
This did not intelligently take into account iframes. In
particular, if a non-exempted domain framed an exempted
domain, the exempted domain's iframe would be exempted.
It probably should not. This is debatable, but at this
point in time after consultation with Tor we are going
to take the approach described in the comments in
CookieJarSettings.h
Notably this is creating a gap when it comes to nested
iframes. If an exempted domain iframes a non-exempted
domain, which in turn iframes an exempted domain - the
innermost iframe will be exempted even though its parent
is not. This is not ideal, once a document is non-
exempted, all children should be non-exempted. But this
is especially difficult to implement with the facilities
easily available to us, so we leave this corner case for
another day.
Differential Revision: https://phabricator.services.mozilla.com/D150587
Testing indicated that for a SubDocument, the loading principal
is that of the parent document, but the final channel uri is
the uri of the subdocument. In this situation, use the final
channel uri just as we do for a Document.
Differential Revision: https://phabricator.services.mozilla.com/D150586
In rare cases, we will need to see if we ShouldRFP using
only a URI and OA. (This is already the case for a
top-level load.)
Abstract this check into its own function, but at the
same time explicitly label it as dangerous and require
the developer to provide a justification why they need
to use it to hopefully prevent misuse.
Differential Revision: https://phabricator.services.mozilla.com/D150585
- Reorder ShouldRFP(char* justification) to put it first
- Add a log line about a null dochsell to be consistent
- Significantly alter the ShouldRFP(nsIPrincipal) check:
Before, it was a coarse function, if you weren't system
principal, it just checked the pref.
Now, it has been combined with the ShouldRFP(nsIPrincipal, OriginAttributes)
function, which was fine-grained. That function didn't
need to exist, because we can _get_ the OriginAttributes
_from_ the principal.
Because before we were retrieving the OA from the loadInfo
(and not the principal) we add an assert to ensure they're
the same.
We eliminate the ShouldRFP(nsIPrincipal, OriginAttributes)
function entirely and convert its one caller into just
passing the principal.
One result of all of this is that the ShouldRFP(nsIPrincipal)
check has been turned into a fine-grained check.
Differential Revision: https://phabricator.services.mozilla.com/D146945
Instead of trying to get the ScriptObjectPrincipal
of a window; use the window's Document, which will
take into account a lot more context.
Differential Revision: https://phabricator.services.mozilla.com/D150584
Cleanup our entitlement files by removing entitlements that use the default setting of false.
production.entitlements.xml and developer.entitlements.xml are used today.
The browser and plugin-container entitlement lists will be used when we enable using different entitlements for parent and child processes.
Differential Revision: https://phabricator.services.mozilla.com/D151943
The suggested solution for this bug is to disable browser.fixup.alternate.enabled
unless toggled by the user, and to add telemetry to the preference so that if we
find users rarely use the option, we can safely remove the feature in a future release.
Many tests rely on expecting URI's to be modified, so I modified them so that they
should not expect the prefix or suffix to be modified.
Differential Revision: https://phabricator.services.mozilla.com/D147795
This skips post barriers for MapObject tables when the JS Map object is in the
nursery. The change to the finalizer is required so that we don't try and
remove store buffer entries that were not created in the first place.
I don't like the way this works by casting the table pointer to a different type
with the same memory layout, but it's something we do already in that code and
it's the simplest solution to this problem.
Differential Revision: https://phabricator.services.mozilla.com/D151916
Test can be reenabled after the migration to Python 3.7+ (bug 1734402) because
the fixed Poetry version (1.2.0) has that as minimum requirement.
Differential Revision: https://phabricator.services.mozilla.com/D151913
At least in gecko, we are generating a pointermove event for each
pointer even when there was no actual change. This corresponds to the
behaviour of touch events, where the touchmove event includes all
active touch points.
Although this looks like it doesn't match the intent of the Pointer
Events spec, for an infrastructure test that's just checking if the
testdriver feature is supported, it seems better to allow the
discrepancy from the ideal behaviour rather than imply that the whole
feature is broken.
Differential Revision: https://phabricator.services.mozilla.com/D151276
For touch type pointers gecko doesn't support all the properties in pointer-events (and
it's not even very clear to me that they all make sense; how can one talk about the twist of
a finger, for example?). So split out a version of the tests that only test the properties
which are supported, so that we can regression-test the basics without failing due to missing
support at the engine layer for more complex properties.
Differential Revision: https://phabricator.services.mozilla.com/D139121
Touch is a bit different to mouse inputs because there are often
multiple pointers (i.e. fingers) acting at the same time. It turns out
that Gecko wants a single call containing all the positions etc. of
the touch pointers for each event, rather than having a single call
per pointer. So we have to group the pointer actions from one tick
together.
Differential Revision: https://phabricator.services.mozilla.com/D139120
