Viewport Protection patches on Linux

[PF4Public]

Your patches depend heavily on each other and therefore I couldn't apply only Viewport Protection patches while building ungoogled-chromium on Linux.

I'm not expecting you to rethink how you create and apply patches, just an FYI for @uazo

Given the number of failures (except for java, which I could easily exclude), I guess there would be no easy solution to this.

 * Applying 00Viewport-Protection-Site-Setting.patch ...
patching file chrome/app/settings_strings.grdp
Hunk #1 succeeded at 4272 with fuzz 1 (offset -95 lines).
patching file chrome/browser/resources/settings/icons.html
Hunk #1 FAILED at 199.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/resources/settings/icons.html.rej
patching file chrome/browser/resources/settings/privacy_page/privacy_page.html
Hunk #1 succeeded at 1095 (offset -110 lines).
patching file chrome/browser/resources/settings/route.ts
Hunk #1 FAILED at 119.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/resources/settings/route.ts.rej
patching file chrome/browser/resources/settings/router.ts
Hunk #1 FAILED at 106.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/resources/settings/router.ts.rej
patching file chrome/browser/resources/settings/site_settings/category_default_setting.ts
Hunk #1 FAILED at 200.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/resources/settings/site_settings/category_default_setting.ts.rej
patching file chrome/browser/resources/settings/site_settings/constants.ts
Hunk #1 FAILED at 51.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/resources/settings/site_settings/constants.ts.rej
patching file chrome/browser/resources/settings/site_settings/settings_category_default_radio_group.ts
Hunk #1 FAILED at 144.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/resources/settings/site_settings/settings_category_default_radio_group.ts.rej
patching file chrome/browser/resources/settings/site_settings/site_details.html
Hunk #1 succeeded at 266 with fuzz 2 (offset -25 lines).
patching file chrome/browser/resources/settings/site_settings_page/site_settings_page.ts
Hunk #1 succeeded at 334 with fuzz 2 (offset -40 lines).
Hunk #2 FAILED at 480.
1 out of 2 hunks FAILED -- saving rejects to file chrome/browser/resources/settings/site_settings_page/site_settings_page.ts.rej
patching file chrome/browser/resources/settings/site_settings_page/site_settings_page_util.ts
Hunk #1 FAILED at 87.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/resources/settings/site_settings_page/site_settings_page_util.ts.rej
patching file chrome/browser/ui/views/page_info/page_info_view_factory.cc
Hunk #1 succeeded at 338 with fuzz 2 (offset -15 lines).
patching file chrome/browser/ui/webui/settings/settings_localized_strings_provider.cc
Hunk #1 FAILED at 2497.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/ui/webui/settings/settings_localized_strings_provider.cc.rej
patching file chrome/browser/ui/webui/settings/site_settings_helper.cc
Hunk #1 FAILED at 130.
1 out of 1 hunk FAILED -- saving rejects to file chrome/browser/ui/webui/settings/site_settings_helper.cc.rej
patching file components/browser_ui/site_settings/android/BUILD.gn
Hunk #1 succeeded at 101 with fuzz 2 (offset -11 lines).
can't find file to patch at input line 279
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/components/browser_ui/site_settings/android/java/src/org/chromium/components/browser_ui/site_settings/BromiteCustomContentSettingImpl.java b/components/browser_ui/site_settings/android/java/src/org/chromium/components/browser_ui/site_settings/BromiteCustomContentSettingImpl.java
|--- a/components/browser_ui/site_settings/android/java/src/org/chromium/components/browser_ui/site_settings/BromiteCustomContentSettingImpl.java
|+++ b/components/browser_ui/site_settings/android/java/src/org/chromium/components/browser_ui/site_settings/BromiteCustomContentSettingImpl.java
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
patching file components/browser_ui/site_settings/android/java/src/org/chromium/components/browser_ui/site_settings/BromiteViewportContentSetting.java
patching file components/browser_ui/site_settings/android/java/src/org/chromium/components/browser_ui/site_settings/SiteSettingsCategory.java
Hunk #1 FAILED at 48.
Hunk #2 FAILED at 88.
2 out of 2 hunks FAILED -- saving rejects to file components/browser_ui/site_settings/android/java/src/org/chromium/components/browser_ui/site_settings/SiteSettingsCategory.java.rej
patching file components/browser_ui/strings/android/browser_ui_strings.grd
Hunk #1 FAILED at 176.
1 out of 1 hunk FAILED -- saving rejects to file components/browser_ui/strings/android/browser_ui_strings.grd.rej
patching file components/browser_ui/strings/android/viewport.grdp
patching file components/components_strings.grd
Hunk #1 FAILED at 341.
1 out of 1 hunk FAILED -- saving rejects to file components/components_strings.grd.rej
patching file components/content_settings/core/browser/content_settings_registry.cc
Hunk #1 FAILED at 627.
1 out of 1 hunk FAILED -- saving rejects to file components/content_settings/core/browser/content_settings_registry.cc.rej
patching file components/content_settings/core/browser/content_settings_utils.cc
Hunk #1 FAILED at 162.
1 out of 1 hunk FAILED -- saving rejects to file components/content_settings/core/browser/content_settings_utils.cc.rej
patching file components/content_settings/core/common/content_settings.cc
Hunk #1 FAILED at 220.
Hunk #2 FAILED at 234.
2 out of 2 hunks FAILED -- saving rejects to file components/content_settings/core/common/content_settings.cc.rej
patching file components/content_settings/core/common/content_settings.h
Hunk #1 FAILED at 98.
1 out of 1 hunk FAILED -- saving rejects to file components/content_settings/core/common/content_settings.h.rej
patching file components/content_settings/core/common/content_settings.mojom
Hunk #1 FAILED at 83.
1 out of 1 hunk FAILED -- saving rejects to file components/content_settings/core/common/content_settings.mojom.rej
patching file components/content_settings/core/common/content_settings_mojom_traits.cc
Hunk #1 FAILED at 107.
1 out of 1 hunk FAILED -- saving rejects to file components/content_settings/core/common/content_settings_mojom_traits.cc.rej
patching file components/content_settings/core/common/content_settings_mojom_traits.h
Hunk #1 succeeded at 150 with fuzz 1 (offset -25 lines).
patching file components/content_settings/core/common/content_settings_types.h
Hunk #1 succeeded at 274 with fuzz 2 (offset -7 lines).
patching file components/content_settings/renderer/content_settings_agent_impl.cc
Hunk #1 succeeded at 424 with fuzz 1 (offset -35 lines).
patching file components/content_settings/renderer/content_settings_agent_impl.h
Hunk #1 FAILED at 101.
1 out of 1 hunk FAILED -- saving rejects to file components/content_settings/renderer/content_settings_agent_impl.h.rej
patching file third_party/blink/common/features.cc
Hunk #1 FAILED at 221.
1 out of 1 hunk FAILED -- saving rejects to file third_party/blink/common/features.cc.rej
patching file third_party/blink/public/platform/web_content_settings_client.h
Hunk #1 succeeded at 96 with fuzz 2 (offset -7 lines).
patching file third_party/blink/renderer/core/frame/local_dom_window.cc
Hunk #1 FAILED at 2306.
1 out of 1 hunk FAILED -- saving rejects to file third_party/blink/renderer/core/frame/local_dom_window.cc.rej
patching file third_party/blink/renderer/core/page/page.cc
Hunk #1 FAILED at 884.
1 out of 1 hunk FAILED -- saving rejects to file third_party/blink/renderer/core/page/page.cc.rej

I did analyze chrome/browser/resources/settings/icons.html failure and it turns out that one needs to apply autoplay, jit, timezone, webgl, webrtc patches first.

[uazo]

Your patches depend heavily on each other and therefore I couldn't apply only Viewport Protection patches while building ungoogled-chromium on Linux

eh, I am aware of that... especially those that work on settings pages and content settings.
but it's not the code that doesn't work on its own, it's git that obviously, in building the patch, takes code present from other patches (I hope I've explained myself).

I'm not expecting you to rethink how you create and apply patches

I've actually been thinking about this for some time already, but I tried inserting comments, as gn does, e.g:

  # Three lines of non-changing comments so that
  # the commit queue can handle CLs rolling ios_webkit
  # and whatever else without interference from each other.
code...
  # Three lines of non-changing comments so that
  # the commit queue can handle CLs rolling ios_webkit
  # and whatever else without interference from each other.

but I can't get it to work properly.
if anyone knows a method I will be happy to apply it.

it turns out that one needs to apply autoplay, jit, timezone, webgl, webrtc patches first.

no, it is not, it is just a problem as indicated above.

So how do you want to go on? can I give you some help in some way?

[uazo]

I'm not expecting you to rethink how you create and apply patches

I had also thought about the alternative of generating files via an action in the gns, exposing a specific folder and letting patches insert files with the necessary informations into it, so that the various patches can point to different files for the changes, but it is rather complex to do and not recommended by the chromium team and in fact there are no examples to copy from.

and it is not applicable to typescript because the content is static :(

every idea is welcome

[PF4Public]

eh, I am aware of that... especially those that work on settings pages and content settings. but it's not the code that doesn't work on its own, it's git that obviously, in building the patch, takes code present from other patches (I hope I've explained myself).
no, it is not, it is just a problem as indicated above.

I know I didn't express it clearly.

So how do you want to go on? can I give you some help in some way?

I thought about applying patches manually, but given the number of changes I'd rather not, since that would be too tedious especially in the light of future updates. So, I honestly don't know how to proceed.

[uazo]

So, I honestly don't know how to proceed.

help me to find a way to use this way:

  # Three lines of non-changing comments so that
  # the commit queue can handle CLs rolling ios_webkit
  # and whatever else without interference from each other.
code...
  # Three lines of non-changing comments so that
  # the commit queue can handle CLs rolling ios_webkit
  # and whatever else without interference from each other.

is it clear what they do? i can't use it though.

EDIT: in any case I will try to apply only that patch to the chromium code base, so I can understand the reasons why it doesn't apply and maybe find a solution.

[uazo]

@PF4Public have patience, I am reviewing all the content settings patches to align them and if I can simplify them, it will take me a while.
about the viewport protection, I decided to put it at the top of the list so that it's not dirtied by the others and you can use it as is.

[PF4Public]

@uazo I'll investigate how they apply those patches and keep you informed if I find anything interesting.

about the viewport protection, I decided to put it at the top of the list so that it's not dirtied by the others and you can use it as is.

It is so nice of you! Thanks! But what if I want to take some of your other patches into my local build as well? :)

There might be alternative solution. Have you ever considered instead of making everything in a form of patches, split things in parts and apply some of more regular parts via sed or awk during the build process? For example this might allow you to easily update html/xml files in place and this results in less maintenance on your side.

PS: @uazo I'm sorry for such delayed reply, but I had to disconnect and take a break for some time.

[uazo]

But what if I want to take some of your other patches into my local build as well? :)

The idea is to develop a tool that allows me to track overlaps between patches.
When I have an idea of which and how many overlapping patches I have, I can give you an answer.
I think it will also help me decide how to simplify the various patches and in the creation of a patch 'logbook'.

Have you ever considered instead of making everything in a form of patches, split things in parts and apply some of more regular parts via sed or awk during the build process?

I don't really like this idea, I would prefer the code change to be static and not dynamic during compilation, also because it would complicate (I think) the extraction of the '.patch' file from git.
the alternative is to use the generated code and the #include but on the java side I don't have this possibility, except via a hack I found a few years ago, but now that I have a little more experience I am no longer convinced that introducing major changes in the build process is the way to go.

but I had to disconnect and take a break for some time

Of course, when you come back I may already have something to show you, I am already doing it :)

[uazo]

@PF4Public I haven't finished but I'm well on my way, and I'm asking if you can spare some time for a follow-up.
is really taking me a lot of time but I am satisfied because from now on I can add a site setting with three lines of code in both android and windows version.
it's a question of whether this will work with linux as well.

I try to explain, what is needed is (all names are temporary):

• 00bromite-build-utils.patch
  this patch allows me to include in gn the automatic inclusion of files in folders rather than the individual file, is necessary for me because the idea I brought up is the separation of code into multiple files so that the patch does not change the context of another patch.
  Basically it's like you have c++ side a

#include "directory content" 

which is obviously not a standard compiler feature.
I enabled the same thing in grit and java side, the latter is a bit more complex but the idea is the same.

• Content-settings-infrastructure.patch
  is the heart of it all, this patch changes the behavior of chromium by allowing me to put site settings in different files so that the patches don't overlap.
  this patch is extremely complex, if you have specific questions....

• 00Viewport-Protection-flag.patch
  no change here, it is the patch that activates that behavior, while ...

• 00Viewport-Protection-Site-Setting.patch
  ... Is the patch that inserts the site settings in android and in windows

all the source are in uazo/cromite#59
if you want to try (grazie!), in the meantime I'll go ahead

[PF4Public]

if you want to try (grazie!)

Of-course I do!

Is the patch that inserts the site settings in android and in windows

Do I need to do anything special for Linux then?

[uazo]

Do I need to do anything special for Linux then?

Um, great question, I hope not, technically there is no reason why it shouldn't work....

[PF4Public]

@uazo Thanks for keeping me informed, I'll try rebuilding ungoogled-chromium with your patches and let you know how it goes and works.

By the way, how do I actually test if viewport protection actually works? Is "Cover Your Tracks - Electronic Frontier Foundation" a good tool for that?

[uazo]

you can use:

• https://canvasblocker.kkapsner.de/test/domRectTest.php
• https://abrahamjuliot.github.io/creepjs/tests/domrect.html
• https://abrahamjuliot.github.io/creepjs/tests/screen.html
• https://dev-pages.brave.software/fingerprinting/farbling.html (screen resolution tests)
• https://browserleaks.com/rects
• https://privacycheck.sec.lrz.de/active/fp_gcr/fp_getclientrects.html
• https://arkenfox.github.io/TZP/tests/domrectspoof.html

you have to disable Disable get*ClientRects() fingerprint deception flag (chrome://flags/#fingerprinting-client-rects-noise)

[PF4Public]

I have rebuilt ungoogled-chromium with your patches (on Linux) and did some testing. Hope the results are interesting for you.

This time patches applied without issues (I've applied only 4 mentioned above to begin with). Before running with your patches applied I glanced through the links you listed with my usual ungoogled-chromium browser and I have to admit that creepjs is very good at fingerprinting. It even assigns the same "lies" for all my ungoogled-chromium browsers (1xAndroid, 2xLinux). That's impressive!

Then I proceeded to starting the browser with your patches and disabling all deceiving settings that come with ungoogled-chromium as you suggested. Then I tested DOMRect and Screen from creepjs. This time creepjs cannot detect any lies. Reloading tabs shows the same fingerprint (I suppose this is how it is expected to be), but closing the tab, opening another one and navigating to the tests again shows another fingerprint. Similarly a test on eff org always shows different screen resolution.

That's a great job, @uazo!

With all that said, creepjs still assigns the same fingerprint overall. Probably other measures needed to deceive it completely. Also the test at eff assigns persistent webgl hash. creepjs probably too, but I haven't yet completely understood how it assigns lies and hashes.

I'll try some more of your patches and report back if you're interested. The next I think, I'd like to try hiding timezone :)

[uazo]

Hope the results are interesting for you.

absolutely!

I have to admit that creepjs is very good at fingerprinting.

yes, I agree, it is a really interesting project and also well written.
in addition, reading the code, there are some really interesting tidbits, but they are not public (I hope the author don't disable them!) which I am exploiting to test some of my patches.
it's a great job.

It even assigns the same "lies"

In fact, I am reflecting on this to modify the patch Canvas fingerprinting mitigations (tracked by #38).
That is, is it appropriate to minimise lies? from a technical point of view it is a fun challenge

Reloading tabs shows the same fingerprint (I suppose this is how it is expected to be)

Yes, correct

With all that said, creepjs still assigns the same fingerprint overall. Probably other measures needed to deceive it completely

yes, if you have windows and try this browser you will notice that it is always different.
but I still don't know if this is good...

and now my question: do you think you should show different screen sizes each time?
I mean, nothing easier to track...

@macchrome @romain-hunault @chirayudesai I make no secret of it, is an open secret, I hope that other browsers will also use my patches also to increase the number of devices that behave like this browser... and there are also other things that I only do at present... that is, I am afraid that this browser is easily traceable.

[PF4Public]

In fact, I am reflecting on this to modify the patch Canvas fingerprinting mitigations (tracked by #38).
That is, is it appropriate to minimise lies? from a technical point of view it is a fun challenge

Given that creepjs detects same lies for different ungoogled-chromium browsers, I would think that having persistent lies would be favouring the fingerprinting instead of hardening it.

I wonder how does canvas fingerprint protection relates to viewport protection? After applying your viewport protection patches I seem to also have canvas protection, do I?

yes, if you have windows and try this browser you will notice that it is always different.
but I still don't know if this is good...

I need to try applying other patches from your changes ;)

and now my question: do you think you should show different screen sizes each time?
I mean, nothing easier to track...

Sorry, but I don't understand what you mean. :(

I hope that other browsers will also use my patches

Would you mind if I make your patches available to Gentoo users of ungoogled-chromium as a build-time configurable opportunity (disabled by default)? I'm unsure if it would be OK to distribute the resulting binary from the licensing perspective (so, I won't do this just in case), but allowing end-user to conditionally apply your patches seems to be absolutely legal (in contrast to merging your patches to ungoogled-chromium project, which might give rise to licensing concerns and this is probably not going to happen in immediate future). I will of-course mention that this is solely your work and unrelated to ungoogled-chromium.

[uazo]

That is, is it appropriate to minimise lies?

Given that creepjs detects same lies for different ungoogled-chromium browsers, I would think that having persistent lies would be favouring the fingerprinting instead of hardening it.

I apologise for my poor English. I try to explain myself better.

according to what the author says, creepjs is not a tool for identifying fingerprinting methodologies but rather a 'library' for identifying bots.
from this point of view, lying for them is the method to identify those tools that are used by platforms such as Browser Automation Studio that try to modify fingerprinting hashes to simulate different users with the same hardware.
all lies increase the score that creepjs uses to identify bots, but decreases the scope used to generate a hash because the value is considered skewed.

now, this is (more or less) what he does, but it is not certain that it does not also really happen from other libraries.
so rather than not lying, it might be interesting to lie on purpose.

from a technical point of view it is a fun challenge

it's not easy to lie well, that's what I wanted to say.

I wonder how does canvas fingerprint protection relates to viewport protection?

nothing, but currently that patch is not able to lie correctly, that's what I meant.

I need to try applying other patches from your changes ;)

go ahead but be careful not to use Carl's without his consent

and now my question: do you think you should show different screen sizes each time?

Suppose we want to track a browser, how many in the crowd change screen size (EDIT: without lying)? None.

Would you mind if I make your patches available to Gentoo users of ungoogled-chromium as a build-time configurable opportunity (disabled by default)?

I tend not to have problems because I think the most complex part is maintaining a patch, not so much developing it.
I would also be happy if they did tests (or helped me do them).
is it also possible to obtain the drafting of the documentation in return? :) because it's one of the things I don't like doing :)

[uazo]

please wait, I found an error with a full build
https://github.com/uazo/bromite-buildtools/actions/runs/5334888707/jobs/9667645727#step:4:2139

I probably forgot some deps

[uazo]

I probably forgot some deps

so it was, fixed in uazo/cromite@4c5f4ee

[uazo]

I am closing the issue as completed, feel free to continue writing.

[PF4Public]

it might be interesting to lie on purpose.
it's not easy to lie well, that's what I wanted to say.

Oh, now I see what you mean! But unfortunately I'm by far not an expert in this field, so cannot give a definite answer :)

I wonder how does canvas fingerprint protection relates to viewport protection?

nothing, but currently that patch is not able to lie correctly, that's what I meant.

But I got changing rects fingerprint, with only viewport protection. Am I misinterpreting something?

and now my question: do you think you should show different screen sizes each time?

Suppose we want to track a browser, how many in the crowd change screen size (EDIT: without lying)? None.

That's true, unless more people use browsers which do change screen sizes :)

I would also be happy if they did tests (or helped me do them).

I could encourage them doing so of-course, but I can speak only for myself.

is it also possible to obtain the drafting of the documentation in return?

Are you asking me or "them"? In case it is me myself — it goes without saying. But I think that one should start documenting only after all things are more-or-less in order and no renames/changes in view. But if you have something on your mind — I'm all ears.

because it's one of the things I don't like doing

Psst, me too! Me too! But I have to do it as part of my daytime job from time to time, so I have to live with it :)

I probably forgot some deps

Looks like it only affected Android. I've been building for Linux, so this didn't affect me fortunately.

[uazo]

I'm by far not an expert in this field

neither do I...

But I got changing rects fingerprint, with only viewport protection. Am I misinterpreting something?

viewport protection, by changing the aspect ratio of the window, also changes all the co-ordinates of each individual element, thus including the canvas.
but the method used to fingerprint the canvas is different and is related to how the device's video card driver interprets the messages sent by chromium/skia and transforms them into images, which in turn are transformed into arrays of bits that produce a hash.
so viewport protection does not cover canvas protection.

canvas can be (definitively? :) protected by modifying the list of commands sent to skia by randomly inserting elements that dirty the image, which leads to the advantage that the same canvas will always produce the same hash each time it is read, because and identical commands will always produce different canvases.
theoretically... but reading the code it seems to be possible to do this. i'm not doing it because, as said before, i don't know if it's better to pretend well or to continue pretending badly.

That's true, unless more people use browsers which do change screen sizes :)

precisely

Are you asking me or "them"? In case it is me myself — it goes without saying. But I think that one should start documenting only after all things are more-or-less in order and no renames/changes in view. But if you have something on your mind — I'm all ears.

:) I will prepare a plan in which I will set out my ideas about this project.
the problem is that it takes me longer to translate it than to write it!

Looks like it only affected Android. I've been building for Linux, so this didn't affect me fortunately.

fixed: the bug was only for version is_official_build=1. but I also noticed that I broke the component build.

[PF4Public]

so viewport protection does not cover canvas protection.

Thanks for explaining! Then I have a question: why did you suggest to disable rects-fingerprinting deception? In order to obtain clean results or are they both incompatible to each other?

by randomly inserting elements that dirty the image

That would be an interesting approach :)

:) I will prepare a plan in which I will set out my ideas about this project.

I'm watching activity in your repositories, but feel free to mention me with a @ if you want to point my attention to something.

the problem is that it takes me longer to translate it than to write it!

Unfortunately I would be unable to help you with translation from your language because I do not speak your language at all. :(

[uazo]

Then I have a question: why did you suggest to disable rects-fingerprinting deception?

because if you leave that option active, creepjs identifies the change of co-ordinates as a lie.

if you want to point my attention to something.

Of course, I will.

[PF4Public]

I have applied timezone randomization, WebGL and font fingerprinting prevention patches. Now creepjs issues unique Id each test. Although I'm not sure whether font fingerprinting prevention works for me on Linux…

[uazo]

I'm not sure whether font fingerprinting prevention works for me on Linux…

no, linux code is not covered because they are not able to test it :( . for now only android and windows are supported, do you want to try to implement it?

[PF4Public]

do you want to try to implement it?

I did a quick glance through the sources and found no function in Linux part that was calling CreateTypeface, which you hijacked in Windows part, so I decided to put it off for now and maybe return to it later :)

[uazo]

so I decided to put it off for now and maybe return to it later :)

certainly.
in any case I think the linux code is CreateTypeface

[PF4Public]

@uazo Guess what? I had one instance of ungoogled-chromium without your patches and I decided to test font fingerprinting today. So, without your patches:

Report 173 fonts and 98 unique metrics found

After changing the binary to the one that has your patches applied:

Report 0 fonts and 2 unique metrics found

So it seems that there is nothing extra needed to make it work on Linux. Yay!

[PF4Public]

@uazo What is the difference between:

• chrome://flags/#viewport-protection → Default
• chrome://flags/#viewport-protection → Disabled
• chrome://flags/#viewport-protection → Enabled

?

[uazo]

carl asked me not to add the site settings but to leave just the flag, in fact there are two patches, one for the flag (theoretically to be merged with bromite, but then the process stopped) and another just for me.
without the site settings patch, it enables/disables that behavior, with the site settings patch, it does nothing.

[PF4Public]

But you didn't answer my question :( If it does nothing, why do I see different behaviour changing the flag value between options as I mentioned in another issue?

Do I need both patches or just one?

[uazo]

why do I see different behaviour changing the flag value between options as I mentioned in another issue?

maybe I'd better double-check, maybe I told you nonsense.
in any case, I think I will remove the flag from the list if the site setting patch is active

Do I need both patches or just one?

if you also want site setting, yes, both are required

[PF4Public]

Some interesting observations with viewport protection

Drop down menus sometimes behave very weird:
This one:

Details

Grows to upper left corner of a window 50% times:

PDF viewer is definitely blurry:

Details

Violentmonkey popup window is too small:

Details

Noscript popup window moves to the left similarly to dropdown menu pictured above, but only for a couple of pixels and continues to be usable compared to Violentmonkey.

I tested chrome://flags/#viewport-protection setting again, starting each time with --window-size=950,880. See screenshots below.

How could "available" dimension be bigger than the "screen" itself? I believe that this 1 extra pixel outside the screen size makes everything blurry.

Details

chrome://flags/#viewport-protection → Default
Per website setting → Disabled

chrome://flags/#viewport-protection → Default
Per website setting → Enabled

chrome://flags/#viewport-protection → Enabled
Per website setting → Enabled

chrome://flags/#viewport-protection → Enabled
Per website setting → Disabled

chrome://flags/#viewport-protection → Disabled
Per website setting → Disabled

chrome://flags/#viewport-protection → Disabled
Per website setting → Enabled

It is clear that Default/Disabled and Disabled/Disabled do not conceal the screen size overall (those are the only cases where screen is reported bigger than the browser window due to --window-size=950,880), but for some reason also add 1 px to it. This suggests that this could be happening to the UI and all internal pages, which renders them blurry in the end.

[uazo]

Noscript popup window moves to the left similarly to dropdown
Violentmonkey popup window is too small:

I do not detect any problems:

Details

But I will try to disable chrome-extension:// urls by default as well.

PDF viewer is definitely blurry:

I try to disable it automatically for pdf.

Drop down menus sometimes behave very weird:

let me better understand what you mean, from the image I do not understand

How could "available" dimension be bigger than the "screen" itself? I believe that this 1 extra pixel outside the screen size makes everything blurry.

is normal and is the fault of rounding. but I think I can fix it.

those are the only cases where screen is reported bigger than the browser window due to --window-size=950,880

I did not know that switch, I will try

[PF4Public]

Sorry, I should have hidden screenshots to shorten the message.

is normal and is the fault of rounding. but I think I can fix it.

But why there is no rounding in other cases?

I do not detect any problems:

Could be a Linux only issue?

let me better understand what you mean, from the image I do not understand

The dropdown and extensions popup could be in fact the same issue

Here are screen captures

simplescreenrecorder.mp4

simplescreenrecorder-.2.mp4

[uazo]

Could be a Linux only issue?

no, I think it's because of some of your other patches.
what I think is most possible is fingerprinting-flags-client-rects-and-measuretext.patch because make the patch of UpdateStyleAndLayoutTreeF is incorrect.
I suggest you try mine.

[PF4Public]

I've replaced both ungoogled fingerprinting patches with yours and it solved the checkbox issue, but noscript popup is still sliding and violentmonkey popup is still too small.

Disabling chrome://flags/#viewport-protection brings everything back to order. What else do I miss?

PS: ublock popup does not slide, but is oversize on right side and bottom :)

PPS: Now crepjs does not detect lies with domrects test and even assigns new FP ID each time, but Fuzzy and Diffs looks suspiciously similar each time, don't know what that should signify.

[uazo]

but noscript popup is still sliding and violentmonkey popup is still too small.

I think you have some other patch that is not completely correct... or maybe me having another one that fixes that problem, who knows!
try checking what's happening in the window with javascript development tools.

but Fuzzy and Diffs looks suspiciously similar each time, don't know what that should signify.

From https://github.com/abrahamjuliot/creepjs#fingerprint-hashing

Fuzzy: fuzzy hashing of first loose fingerprint
Diffs: fuzzy hashing of current loose fingerprint

in this browser, creepjs never detects a subsequent visit (for me visits is always 1, at each refresh).
in this browser, so, Fuzzy and Diffs hashes are identical:

and refreshing:

[PF4Public]

I got totally confused.

I disable all "Disable" fingerprinting settings like this

I see that all --fingerprinting-* switches are added to commandline.

I open https://browserleaks.com/canvas, notice "Signature" and "PNG Hash".
Reload the page, they are the same.
Kill the tab in Chromium's task manager, they are the same.

I open https://abrahamjuliot.github.io/creepjs/, notice "FP ID" and "Fuzzy".
Reload the page, "FP ID" changes completely, but "Fuzzy" is mostly the same.
Kill the tab in Chromium's task manager, "FP ID" changes completely, but "Fuzzy" is mostly the same.

I open https://privacycheck.sec.lrz.de/active/fp_gcr/fp_getclientrects.html#fpGetClientRects, notice "Fingerprint".
Reload the page, fingerprint stays the same.
Kill the tab in Chromium's task manager, fingerprint changes.

I open https://abrahamjuliot.github.io/creepjs/tests/domrect.html, notice "rect" and "lie pattern".
Reload the page, no lies and "rect" stays the same.
Kill the tab in Chromium's task manager no lies and "rect" changes.

I enable all "Disable" fingerprinting settings like this

I see that all --fingerprinting-* switches are absent from commandline.

I open https://browserleaks.com/canvas, notice "Signature" and "PNG Hash".
Reload the page, they are changed.
Kill the tab in Chromium's task manager, they are changed.

I open https://abrahamjuliot.github.io/creepjs/, notice "FP ID" and "Fuzzy".
Reload the page, "FP ID" and "Fuzzy" are changed.
Kill the tab in Chromium's task manager, "FP ID" and "Fuzzy" are changed.

I open https://privacycheck.sec.lrz.de/active/fp_gcr/fp_getclientrects.html#fpGetClientRects, notice "Fingerprint".
Reload the page, fingerprint changes.
Kill the tab in Chromium's task manager, fingerprint changes.

I open https://abrahamjuliot.github.io/creepjs/tests/domrect.html, notice "rect" and "lie pattern".
Reload the page, "rect" changes and "lie pattern" stays the same.
Kill the tab in Chromium's task manager, "rect" changes and "lie pattern" stays the same.

So should I enable all fingerprinting settings that read "Disable" for fingerprinting deception to work? I'm very confused.

but noscript popup is still sliding and violentmonkey popup is still too small.

I think you have some other patch that is not completely correct... or maybe me having another one that fixes that problem, who knows! try checking what's happening in the window with javascript development tools.

I managed to fix this issue by setting viewport protection flag to "Default". I remember I put it to "Enabled" because UI was blurry with "Default". But now it seems to be OK. Tried restarting several times. 🤷 Nope. Blurry again. With it set to "Default" extension popups work fine, but the UI is blurry. With it set to "Enabled" UI is not blurry, but extension popups are bugged.

[uazo]

I apologise if I have not answered you yet, but your question takes time and I have been busy with other things.
I swear I will try to take it up as soon as possible.

[uazo]

OK, sorry for the wait.

I think you are getting confused about the different features.

viewport protection patch changes the screen size and aspect ratio of the page, so when a site requires 100% of the available space, it is not really 100% of the screen but always something less (and different).
That value is recalculated with each domain (or tab) change, because it would not be fair to show different values for
same-domain navigation, technically it is contained in what chromium calls "Page".
when js scripts ask for the position (or size) of an object, those are always different (at each domain or tab change), although the user does not notice because they are so minimal that they do not change the appearance of the page but only the coordinates.

canvas protection, on the other hand, adds causal pixels each time javascript calls for image bytes to be read, note,
each time, so on the same page, different calls on the same canvas produce different bytes (and thus is a lie, for creepjs).

the get*ClientRect() and measureText() patches behave like canvas protection, and so they lie.

I hope I've been a little clearer.

So should I enable all fingerprinting settings that read "Disable" for fingerprinting deception to work? I'm very confused.

My advice is to disable only get*ClientRect(), because viewport protection has the same effect but does not lie.

but extension popups are bugged.

I am sorry, but you will have to fend for yourself here because I have no way to build and test a Linux platform

[PF4Public]

I am sorry, but you will have to fend for yourself here because I have no way to build and test a Linux platform

viewport protection patch changes the screen size and aspect ratio of the page

And with viewport protection enabled by default it changes the screen size and aspect ratio for the UI and extensions since those are effectively webpages! This is what I'm trying to convey. This is what makes UI and PDF reader blurry.

the user does not notice

That is not true. You can open several chrome://flags/ and switch between them. The difference would be obvious. Same with any GitHub page. I'm not telling that there should be no difference, on the contrary it is expected to work that way, but the difference is real. And it affects browser UI and PDF plugin.

BTW, do you have hidpi screen at your disposal? I suspect that you may not notice a difference if you use a usual screen, but the effect could be greatly amplified (for some reason) on a hidpi screen.