Something screwy with window.open and canvas randomization
Categories
(Core :: Privacy: Anti-Tracking, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox127 | --- | fixed |
People
(Reporter: tjr, Assigned: tjr)
References
(Regressed 1 open bug)
Details
(Whiteboard: [fpp:m?])
Attachments
(18 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
If I open https://canvasblocker.kkapsner.de/test/test.html in two browsers, with FPP enabled in both - the window.open
values will be the same between browsers. Which shouldn't be happening because randomization.
A different issue is reported in https://github.com/arkenfox/user.js/issues/1716#issuecomment-1925180783 which shows that window.open is getting the same hash as a window without FPP enabled - however I could not reproduce that.
Maybe (hopefully?) these are symptoms of the same issue and fixing one will fix both...
Assignee | ||
Comment 1•10 months ago
|
||
So far I've traced this to the fact that GenerateCanvasKeyFromImageData
fails because aCookieJarSettings->GetFingerprintingRandomizationKey
fails. There's aCookieJarSettings (it's not null), but we never called SetFingerprintingRandomizationKey
on it, so it has no key.
Assignee | ||
Comment 2•10 months ago
|
||
We are taking this branch because we don't have an inprocessparent for this popup it seems.
Assignee | ||
Comment 3•10 months ago
|
||
Assignee | ||
Comment 4•10 months ago
|
||
I confirmed that the attached patch fixes it, but I'll need feedback from Tim next week. This is basically the same problem we had with null-principal documents, opened windows, the RFP overrides.... just now applied to the randomization key.
It seems like our two options are to either copy from the opener window into the opened window (but this would probably be inconsistent with a bunch of other stuff not-RFP related that we don't copy, like the rest of CJS) or we generate a new randomization key in the else
block, so the opened window has a different randomization key than the opener.
Assignee | ||
Comment 5•10 months ago
|
||
For the record, the opened window is in the same process.
Comment 6•9 months ago
|
||
It makes more sense if we copy the random key from the opener window. The random key is decided when we open the channel for the document in the parent process. However, a null principal document could have never gone through the parent process. So, we should copy the key from the opener window.
Updated•9 months ago
|
Updated•8 months ago
|
Assignee | ||
Comment 7•8 months ago
|
||
Coming back to this, my patch seems to been screwed up - I can't remember or tell if my new block was inside if (inProcessParent)
or after it. But it appears that it only works if it was after it, so I guess that's where it must have been.
It seems like we could copy a lot of the same properties we copy from inProcessParent from the opener. This patch only copies the CanvasRandomizationKey. But there's also CookieBehavior, PartitionKey, IsFirstPartyIsolated, IsOnContentBlockingAllowList, and ShouldResistFingerprinting. I think I'm going to need to look at this more because I have a feeling we're going to want to copy more of these...
Assignee | ||
Comment 8•8 months ago
|
||
Assignee | ||
Comment 9•8 months ago
|
||
It turns out that we had the override string wrong, but we
didn't notice because we happened to be only testing things
where it was supposed to be disabled anyway.
There was a test where this would have not been the case
(simplePBMFPPTest) - but this was only be tested when we were
exempting it with ETP.
I added this scenario to a place where it would be tested
positively, and confirmed that it failed, then when I fixed
the override, started working again.
Assignee | ||
Comment 10•8 months ago
|
||
Assignee | ||
Comment 11•8 months ago
|
||
This test ensures the expected number of pixels are randomized
in different scenarios of preferences
Assignee | ||
Comment 12•8 months ago
|
||
Assignee | ||
Comment 13•8 months ago
|
||
For the first test, the parent is a page and the child is an iframe, but
eventually we will have tests for lots of different children types.
We test that the number of pixels we expect to be randomized are, and
we also compare the differences between the parent and child.
This allows us to ensure that the FPP key is being propagated correctly.
Assignee | ||
Comment 14•8 months ago
|
||
Assignee | ||
Comment 15•8 months ago
|
||
Assignee | ||
Comment 16•8 months ago
|
||
Assignee | ||
Comment 17•8 months ago
|
||
This test is a little odd because (a) its name is super long and unhelpful
(b) it's testing a very important sitation we've regressed on before
(c) it disables the protections, so you actually don't expect anything
to be enabled.
We're going to need a very similar version of this test where the
protections are enabled, so let's pre-emptively rename this one to
prepare for that.
Assignee | ||
Comment 18•8 months ago
|
||
Updated•8 months ago
|
Assignee | ||
Comment 19•8 months ago
|
||
Assignee | ||
Comment 20•8 months ago
|
||
Assignee | ||
Comment 21•8 months ago
|
||
Assignee | ||
Comment 22•8 months ago
|
||
Assignee | ||
Comment 23•8 months ago
|
||
Assignee | ||
Comment 24•8 months ago
|
||
Updated•8 months ago
|
Assignee | ||
Comment 26•8 months ago
|
||
Uhg, got several test failures on try from the last test run i will need to dig into
Comment 27•7 months ago
|
||
Comment 28•7 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ed5d79d4629f
https://hg.mozilla.org/mozilla-central/rev/8c994e63a5df
https://hg.mozilla.org/mozilla-central/rev/734befa016cd
https://hg.mozilla.org/mozilla-central/rev/a236ed107799
https://hg.mozilla.org/mozilla-central/rev/7f4801b8afbd
https://hg.mozilla.org/mozilla-central/rev/f628d8a1eb58
https://hg.mozilla.org/mozilla-central/rev/5f0a42f88d73
https://hg.mozilla.org/mozilla-central/rev/c503aad0ca16
https://hg.mozilla.org/mozilla-central/rev/f87e9a61ca51
https://hg.mozilla.org/mozilla-central/rev/3978af2aa2fd
https://hg.mozilla.org/mozilla-central/rev/9b0ee8d0d4f6
https://hg.mozilla.org/mozilla-central/rev/6f3394ea8888
https://hg.mozilla.org/mozilla-central/rev/ac1a6456b77e
https://hg.mozilla.org/mozilla-central/rev/fceb109159c2
https://hg.mozilla.org/mozilla-central/rev/99bdce781621
https://hg.mozilla.org/mozilla-central/rev/cba20f6a8f60
https://hg.mozilla.org/mozilla-central/rev/cef71eec96a0
https://hg.mozilla.org/mozilla-central/rev/76724efd86c9
Description
•