Setting up a test battery

[uazo]

I decided to start making this browser into something more serious.
To date, there is no test in cromite that indicates what bug and regressions there are in each release, and more importantly, what the differences are compared to chromium, even from the point of view of security if not privacy.
That is why I have always thought that automatic tests should be introduced.

What I need is an automatic test platform.

this is the idea:

• find a way to drive cromite from the outside
• reactivate the build of chromium tests, to date broken by my patches
• find the official list of chromium/blink tests and check how cromite performs
• define a list of chromium tests to be maintained (e.g. sandbox tests)
• building specific tests for cromite

this is a project within a project, so it is hard to imagine that it will not last for years.

[uazo]

reserved

[uazo]

let's start with how to drive cromite from the outside.
first of all I start by saying that it is more complex than it looks (and excuse me if I write trivial things).

the choice is to use Appium + UiAutomator2 + chromedriver, driven by webdriver in nodejs, but I started out knowing nothing about all!

first of all, I discovered that there are 2 versions of appium, the one officially documented in browserstack (but old, the v1) and one undocumented (v2) which, without knowing it, I used. In fact, I found differences that I could not explain, but which I only realised later, since most of the things I tried still worked. this made it difficult for me to understand, also because the driver of the old version was called wd while that of the new webdriver and at first I thought it was just the initials :) so I developed a solution with wd only realising later that I was doing it wrong :(

Only after banging my head several times do I realise that:

• Appium is the box that enables communication between the client (webdriver) and the application through a driver
• WebdriverIO is the client library to use
• UiAutomator2 is the driver, to be installed in appium, to be used by the webdriver to communicate with an app in android as far as the native layer is concerned.
• chromedriver is another driver, the server for talking to chrome, activated by appium and proxied by UiAutomator2, which allows direct communication with the chromium developer tools

everything communicates via http, between the client and server part of the component, with the sole exception of UiAutomator2 which drives android via adb. chromedriver also talks to chromium via a http socket tunnelled by adb.

the various layers allow me different things

• UiAutomator2, together with the appium inspector, allows me to drive the elements of the application's native interface.
  I can also run adb commands, e.g. to grant permissions with pm, but it does not allow me to launch javascript code inside the browser.
  docs: https://github.com/appium/appium-uiautomator2-driver
• chromedriver allows me to work with the, shall we say, specific part of chromium, interacting with the dom, the page and, above all, the developer tools.

UiAutomator2 works flawlessly, chromedriver needs some hack, also because it is not officially supported by browserstack (and moreover not updated, being still at v123) and I need my solution to work on the emulator as on a real device.
hacks cannot stay in chromedriver (that it would have been easier to), because it is not replaceable in browserstack, but directly in cromite.

the problem is that to get chromedriver to work with chromium forks (all of them, the problem is not just cromite) you have to cheat some of its basic settings. an internet search did not directly bring a solution, because it seems that no one has ever succeeded (or maybe I haven't found it).
the problem is that appium + chromedriver are not made to talk with a fork but only with webviews or the content shell.
an easy problem to change, if you could insert a few lines of code here and there
but fortunately you just need to use in the capabilities this options, and it works:

         'appium:chromeOptions': {
             'androidDeviceSocket': 'chrome_devtools_remote',
             'androidExecName': 'unusedbutimportant',
         },

except in browserstack! that does not accept the passing of that information. i have asked their support, i have not currently received any technical response (if not look in the documentation :) (EDIT: 8/2/24 i finally received it a few weeks ago and they were very helpful. we agreed that since the request was specific to cromite and they had already fixed my side, no intervention from them was necessary)
so you need to modify chromium and enable the socket used by chromedriver as if it were a webview rather than a browser.
fortunately it is very simple, I will put the patch.

done that I haven't done anything yet :) but it's a first step and I got here.

[uazo]

result.xlsx

late by a few weeks, here you will find a summary of the results of creepjs acquired automatically via browserstack, I will put the code to do this file as soon as I clean it up.

in the excel there are:

• DeviceName: is the device name as expressed by browserstack
• Key: the fingerprint name of creepjs
• Value: the fingerprint value
• Test: the name of test
  • chromium, chromium2, chromium3 is the relative value for chromium, in the three rounds
  • cromite, cromite2, cromite3 is the relative value for cromite, in the three rounds
  • chrfont1, chrfont2, chrfont3 is the relative value for chromium, in the three rounds, with applied Embed System Fonts on Android #981 patch

I need someone to help me draw conclusions. @PF4Public :)
Now I try to write down my conclusions.

[uazo]

ah sorry, @abrahamjuliot I forgot about you!

I think you already have this data, but I'd like you to participate in the discussion, if you have the time and desire.

the topic is: what can i do with it and most importantly, how? I already have some ideas.

[uazo]

for an initial analysis of the data i used power bi desktop, which, i admit, i do not know how to use very well. i find qlikview simpler and more complete, but unfortunately, it is not free.
I set myself the first objective of analysing the data regarding the patch that flattens fonts in android devices.

The element I first checked is what creepjs calls emojiiSet, verifying that indeed the patch returns the same result for each device: it did.

the anomaly concerning line 4 and 2 emojiiSet for chrfont tests (section A in the image) is related to an error in the patch I produced, for now let's pretend those data do not exist. The totals at the bottom are also to be ignored, because it happened that some devices were not available during the test, while others crashed, allow me to be a little superficial at this stage.

It is clear from the figure that:

1. emojii in chromium can define a group of devices
2. cromite suffers from the same problem
3. the patch actually flattens that feature, the same set of fonts is detected in all devices

with regard to the difference between cromite and chromium (2), it is due to the fact that emojii in Chromium are derived from play services, which, of course, are disabled in cromite

..continue..

[uazo]

If we consider the emojiiset-0 group, these are the results for the devices for the chromium test:

(I'm sorry you can't see them all)

these the same for the chrfonts1 test:

it is immediately clear that the patch flattens all fonts, since the value for canvas2d.textMetricsSystemSum of creepjs becomes identical in all devices for the set chrfonts1

..continue..

[uazo]

I then looked for which value would be most representative for comparison and found that fonts.pixelSizeSystemSum is the one that most characterises the device:

• for chromium:

fonts.pixelSizeSystemSum	No	Devices
0.023174200000000002	1	Samsung_Galaxy_S21
0.0231745	2	Samsung_Galaxy_Note_20, Samsung_Galaxy_S21_Plus
0.023174840000000002	4	Samsung_Galaxy_A52, Samsung_Galaxy_M52, Samsung_Galaxy_Note_20_Ultra, Samsung_Galaxy_S21_Ultra
0.02318361	1	Samsung_Galaxy_Tab_S7
0.023192330000000004	1	Samsung_Galaxy_M32
0.02801936	1	Samsung_Galaxy_S20
0.028019890000000006	1	Samsung_Galaxy_S20_Plus
0.028020440000000004	3	Samsung_Galaxy_A51, Samsung_Galaxy_Note_10, Samsung_Galaxy_S20_Ultra
0.028021740000000003	1	Samsung_Galaxy_Tab_S6
0.03741566	1	Samsung_Galaxy_S10e
0.03741771000000001	2	Samsung_Galaxy_S10, Samsung_Galaxy_S10_Plus
0.03742029000000001	1	Samsung_Galaxy_Tab_S5e
0.03946717	1	Samsung_Galaxy_S23
0.039470330000000005	1	Samsung_Galaxy_S23_Ultra
0.28753472700000005	1	Google_Pixel_4_XL
0.28756284899999995	2	Oppo_A96, Oppo_Reno_6
0.287572932	2	Xiaomi_Redmi_Note_11, Xiaomi_Redmi_Note_9
0.287577785	1	OnePlus_9
0.2875896910000001	2	Motorola_Moto_G71_5G, OnePlus_8
0.2876261789999999	1	Huawei_P30
0.287638382	2	Google_Pixel_3, Xiaomi_Redmi_Note_8
0.2876544510000001	1	OnePlus_7
0.28770442100000015	1	Motorola_Moto_G9_Play
0.290478322	1	Google_Pixel_5
0.2904963010000001	1	Google_Pixel_6
0.29220284899999993	1	Oppo_Reno_3_Pro
0.292367857	1	OnePlus_11R
0.2927139389999999	1	Vivo_Y50
0.292724352	1	Vivo_V21
0.29285224300000007	1	Vivo_Y21
0.29527352700000004	1	Google_Pixel_6_Pro
0.29532940100000016	3	Google_Pixel_7, Google_Pixel_7_Pro, Google_Pixel_8
0.29536725100000005	1	Google_Pixel_8_Pro
0.29704596899999997	2	Samsung_Galaxy_S22, Samsung_Galaxy_S24
0.297063335	2	Samsung_Galaxy_S22_Plus, Samsung_Galaxy_S24_Ultra
0.2971337230000001	2	Samsung_Galaxy_Tab_S8, Samsung_Galaxy_Tab_S9
0.312090663	1	Google_Pixel_4

• for chrfonts1

fonts.pixelSizeSystemSum	No	Devices
0.2904694689999999	8	Huawei_P30, Oppo_A96, Oppo_Reno_3_Pro, Oppo_Reno_6, Samsung_Galaxy_S10e, Samsung_Galaxy_S20, Samsung_Galaxy_S21, Vivo_Y50
0.290478322	5	Google_Pixel_5, Vivo_V21, Xiaomi_Redmi_Note_11, Xiaomi_Redmi_Note_8, Xiaomi_Redmi_Note_9
0.29048616499999996	4	OnePlus_9, Samsung_Galaxy_Note_20, Samsung_Galaxy_S20_Plus, Samsung_Galaxy_S21_Plus
0.2904963010000001	13	Google_Pixel_6, Motorola_Moto_G71_5G, OnePlus_7, OnePlus_8, Samsung_Galaxy_A51, Samsung_Galaxy_A52, Samsung_Galaxy_M52, Samsung_Galaxy_Note_10, Samsung_Galaxy_Note_20_Ultra, Samsung_Galaxy_S10, Samsung_Galaxy_S10_Plus, Samsung_Galaxy_S20_Ultra, Samsung_Galaxy_S21_Ultra
0.29053475100000004	1	Google_Pixel_8_Pro
0.290605753	2	Samsung_Galaxy_M32, Vivo_Y21
0.29060719100000015	1	Motorola_Moto_G9_Play
0.29527352700000004	1	Google_Pixel_6_Pro
0.295303059	2	Samsung_Galaxy_S23, Samsung_Galaxy_S24
0.295319555	2	Samsung_Galaxy_S23_Ultra, Samsung_Galaxy_S24_Ultra
0.29532940100000016	3	Google_Pixel_7, Google_Pixel_7_Pro, Google_Pixel_8
0.3076188870000001	1	Google_Pixel_4_XL
0.307652182	1	Google_Pixel_4

..continue..

[uazo]

at this point I focused on why some results are different, and I found this:

• chfonts1:

fonts.pixelSizeSystemSum	clientRects.domrectSystemSum	No	Devices
0.2904694689999999	0.29075992462158207	8	Huawei_P30, Oppo_A96, Oppo_Reno_3_Pro, Oppo_Reno_6, Samsung_Galaxy_S10e, Samsung_Galaxy_S20, Samsung_Galaxy_S21, Vivo_Y50
0.290478322	0.29076796691894535	5	Google_Pixel_5, Vivo_V21, Xiaomi_Redmi_Note_11, Xiaomi_Redmi_Note_8, Xiaomi_Redmi_Note_9
0.29048616499999996	0.2907762644195557	4	OnePlus_9, Samsung_Galaxy_Note_20, Samsung_Galaxy_S20_Plus, Samsung_Galaxy_S21_Plus
0.2904963010000001	0.2907866214752198	13	Google_Pixel_6, Motorola_Moto_G71_5G, OnePlus_7, OnePlus_8, Samsung_Galaxy_A51, Samsung_Galaxy_A52, Samsung_Galaxy_M52, Samsung_Galaxy_Note_10, Samsung_Galaxy_Note_20_Ultra, Samsung_Galaxy_S10, Samsung_Galaxy_S10_Plus, Samsung_Galaxy_S20_Ultra, Samsung_Galaxy_S21_Ultra
0.29053475100000004	0.2908253465270996	1	Google_Pixel_8_Pro
0.290605753	0.2908962679290772	2	Samsung_Galaxy_M32, Vivo_Y21
0.29060719100000015	0.2908977310562134	1	Motorola_Moto_G9_Play
0.29527352700000004	0.29556825942993165	1	Google_Pixel_6_Pro
0.295303059	0.2955983517456055	2	Samsung_Galaxy_S23, Samsung_Galaxy_S24
0.295319555	0.2956144841766358	2	Samsung_Galaxy_S23_Ultra, Samsung_Galaxy_S24_Ultra
0.29532940100000016	0.2956245478057862	3	Google_Pixel_7, Google_Pixel_7_Pro, Google_Pixel_8
0.3076188870000001	0.3079259547424317	1	Google_Pixel_4_XL
0.307652182	0.307958984375	1	Google_Pixel_4

Basically, it appears that the value of fonts.pixelSizeSystemSum is tied 1-1 to clientRects.domrectSystemSum which is quite logical, since we are talking about coordinates anyway.

I do not put the data from the chromium test because there are many, but the conclusion is the same.
whoever wants to, can use https://gist.github.com/uazo/c969fcb65fbce278ef28d5ba09c9f4ee, which is a t-sql query for sqlserver that extracts that information.

..continue..

[uazo]

so I tried to make sense of the clientRects.domrectSystemSum value:

• chrfonts1:

fonts pixelSizeSystemSum	clientRects domrectSystemSum	cssMedia matchMediaCSS device-screen	No	Devices
0.2904694689999999	0.29075992462158207	"360 x 760"	1	Samsung_Galaxy_S10e
0.2904694689999999	0.29075992462158207	"360 x 780"	2	Huawei_P30, Vivo_Y50
0.2904694689999999	0.29075992462158207	"360 x 800"	4	Oppo_Reno_3_Pro, Oppo_Reno_6, Samsung_Galaxy_S20, Samsung_Galaxy_S21
0.2904694689999999	0.29075992462158207	"360 x 804"	1	Oppo_A96
0.290478322	0.29076796691894535	"393 x 851"	3	Google_Pixel_5, Xiaomi_Redmi_Note_8, Xiaomi_Redmi_Note_9
0.290478322	0.29076796691894535	"393 x 873"	1	Xiaomi_Redmi_Note_11
0.290478322	0.29076796691894535	"393 x 875"	1	Vivo_V21
0.29048616499999996	0.2907762644195557	"384 x 854"	4	OnePlus_9, Samsung_Galaxy_Note_20, Samsung_Galaxy_S20_Plus, Samsung_Galaxy_S21_Plus
0.2904963010000001	0.2907866214752198	"412 x 869"	3	Samsung_Galaxy_Note_10, Samsung_Galaxy_S10, Samsung_Galaxy_S10_Plus
0.2904963010000001	0.2907866214752198	"412 x 883"	1	Samsung_Galaxy_Note_20_Ultra
0.2904963010000001	0.2907866214752198	"412 x 892"	1	OnePlus_7
0.2904963010000001	0.2907866214752198	"412 x 915"	8	Google_Pixel_6, Motorola_Moto_G71_5G, OnePlus_8, Samsung_Galaxy_A51, Samsung_Galaxy_A52, Samsung_Galaxy_M52, Samsung_Galaxy_S20_Ultra, Samsung_Galaxy_S21_Ultra
0.29053475100000004	0.2908253465270996	"448 x 998"	1	Google_Pixel_8_Pro
0.290605753	0.2908962679290772	"385 x 854"	2	Samsung_Galaxy_M32, Vivo_Y21
0.29060719100000015	0.2908977310562134	"412 x 915"	1	Motorola_Moto_G9_Play
0.29527352700000004	0.29556825942993165	"412 x 892"	1	Google_Pixel_6_Pro
0.295303059	0.2955983517456055	"360 x 780"	2	Samsung_Galaxy_S23, Samsung_Galaxy_S24
0.295319555	0.2956144841766358	"384 x 824"	1	Samsung_Galaxy_S23_Ultra
0.295319555	0.2956144841766358	"384 x 832"	1	Samsung_Galaxy_S24_Ultra
0.29532940100000016	0.2956245478057862	"412 x 892"	1	Google_Pixel_7_Pro
0.29532940100000016	0.2956245478057862	"412 x 915"	2	Google_Pixel_7, Google_Pixel_8
0.3076188870000001	0.3079259547424317	"412 x 869"	1	Google_Pixel_4_XL
0.307652182	0.307958984375	"393 x 830"	1	Google_Pixel_4

I assume from that table that screen width is an important factor, more so than height.
so the next test I will do is to flatten all the devices to 412 pixels to see what happens.

..I'll stop for now.. ;)

[abrahamjuliot]

Nice findings. I'd guess device pixel ratio and maybe the screen width is giving the dimensions hardware entropy. It looks like the model, or brand, can be projected based on the screen and pixel ratio. Device scaling seems not to impact textMetricsSystemSum. Platform version, branding, and browser release range will have some impact on the emojis. Storage quota is quite distinct for the model too, but not relevant within incognito mode.

[uazo]

I'd guess device pixel ratio

the data do not say so: different ratios produce equal results.
It seems strange to me too, in fact I speculate that maybe there is some problem with the way you generate that information. is to be checked.

Device scaling seems not to impact textMetricsSystemSum.

and even this seems strange to me, since the patch modifying the viewport is based on just that.

Platform version, branding, and browser release range will have some impact on the emojis.

this is certain, I have already checked it. there are indications in another issue (which I can no longer find), where the history of git with regard to fonts was checked.

Storage quota is quite distinct for the model too, but not relevant within incognito mode.

yes, I am aware of that. chromium relies on available storage to determine quotas, but fortunately there is already an active patch for that (one less job :).
Instead, I was not aware of the differences in color-gamut and also other values, which I will fix in the near future.

it would be interesting to retrieve this data automatically in other chromium forks as well, I do not know whether @arthuredelstein (for brave) or @SkewedZeppelin (for mulch) are interested.

[PF4Public]

in the excel there are:

• DeviceName: is the device name as expressed by browserstack

• Key: the fingerprint name of creepjs

• Value: the fingerprint value

• Test: the name of test

  • chromium, chromium2, chromium3 is the relative value for chromium, in the three rounds
  • cromite, cromite2, cromite3 is the relative value for cromite, in the three rounds
  • chrfont1, chrfont2, chrfont3 is the relative value for chromium, in the three rounds, with applied Embed System Fonts on Android #981 patch

Please allow me to clarify your procedure and the results:

• Is everything you gathered actually in the file you attached? I am confused by this: "I do not put the data from the chromium test because there are many"
• Is the table "keygroup1" important? What is it for?
• Is the column "Caption" a concatenation of columns "DeviceName" and "Test"?
• Is there some data lost in "#0 hash" and "#0 data"?
• Do I understand the procedure correctly?
  • You open via automation creepjs and gather the results.
  • You use Cromite, Chromium and patched Chromium for that.
  • You run each test 3 times in each browser. Are browsers newly instantiated each time?
  • Which would results in each row with the same Caption belonging to the same test attempt, right?
  • Oh, and all the above was repeated over the devices available in BrowserStack?

it would be interesting to retrieve this data automatically in other chromium forks as well

I guess it would be interesting to include ungoogled-chromium into your test-pool :) Is it doable? Do you need help with that?

[abrahamjuliot]

different ratios produce equal results.

This might be due to the summing of the coordinates in the result. It's faster and makes integrity checks easier, but some entropy is lost.

[uazo]

Is everything you gathered actually in the file you attached? I am confused by this: "I do not put the data from the chromium test because there are many"

I was referring to the table for reporting data with markdown, it would have taken up too much space without giving any information

Is the table "keygroup1" important? What is it for?

no, so far no special meaning. I only needed it to display a subset of data.
creepjs.zip is the powerbi file, if you want to try it, but I can already tell you that it kind of sucks

Is the column "Caption" a concatenation of columns "DeviceName" and "Test"?

Yes

Is there some data lost in "#0 hash" and "#0 data"?

is just to make that set of values more readable (which would otherwise be in the format 1d6d1833fe9ba8c9efa48ee2544453e20932cb80c5cc3bf7d97932531bfe894f), same string, same value

You open via automation creepjs and gather the results.
You use Cromite, Chromium and patched Chromium for that.
Which would results in each row with the same Caption belonging to the same test attempt, right?

yes.

You run each test 3 times in each browser. Are browsers newly instantiated each time?

yes, but the device could be the same, I mean, just the same, whereas I would also be interested in checking different devices of the same model.
the choice of the physical device is made from the browserstack backend, but it is possible to check whether the device is the same since appium reports a specific code (androidId).

Oh, and all the above was repeated over the devices available in BrowserStack?

yes and no, some would crash, others need the 32-bit version, mine is a first step, to rough out the problem.

I guess it would be interesting to include ungoogled-chromium into your test-pool :) Is it doable?

if you mean the desktop version, no, it is not possible with browserstack since installation of new applications is not allowed for desktops.

Do you need help with that?

find a free service similar to browserstack but for desktops that exposes different physical machines, but I don't think it exists.

[uazo]

This might be due to the summing of the coordinates in the result

I don't think so, it would be too unlikely a coincidence, given the use of floating-point numbers.

However, I came up with a way to understand it.
I will do two more separate tests:

1. fixing the width at 412 without changing the ratio, a kind of letterboxing in tor slang
2. change the ratio proportionally so as to bring the width to 412

consider that my goal will be to define a screen size to be applied to all devices, for example a 412x1000, because obviously screen height is a fingerprint factor.
I would also have to see how tor does it in android.

[PF4Public]

creepjs.zip is the powerbi file, if you want to try it, but I can already tell you that it kind of sucks

I think, I'd convert your excel file into csv, prepare it and then send into Postgres for analysis via SQL.

Is there some data lost in "#0 hash" and "#0 data"?

is just to make that set of values more readable (which would otherwise be in the format 1d6d1833fe9ba8c9efa48ee2544453e20932cb80c5cc3bf7d97932531bfe894f), same string, same value

Do you have the full result? I admit, hash collisions are very unlikely, but still there could be useful patterns.

[uazo]

Do you have the full result?

https://www.cromite.org/tests/creepjs.zip is the result prior to aggregation in excel.

but still there could be useful patterns.

no, no advantage in using it.
Indeed, the hash most often is a value that is not useful for this test, since it aggregates information that should instead remain separate.

[uazo]

https://chromium-review.googlesource.com/c/chromium/src/+/5621488 (note for me)
https://issuetracker.google.com/issues/335680565

[uazo]

I have not forgotten this, on the contrary.
finished the development of the actions for the creation of the vanilla version of chromium, it works, for now tested offline. in the next version I think I will be able to release it.

next step, create an action for this blessed test!

[uazo]

For comparisons I also intend to attempt the build of brave with a modified version of chromium as a baseline (#772)

[uazo]

Surprised? Why?

[PF4Public]

Surprised? Why?

Me? It is more like intrigued :) I'm looking forward to what interesting you may find.

[uazo]

I have noticed that a lot, but really a lot, is done by adblock. i will also put adblock in vanilla chromium, to compare the differences between cromite and chromium.

[PF4Public]

I have noticed that a lot, but really a lot, is done by adblock.

In terms of fingerprinting protection?

[uazo]

In terms of fingerprinting protection?

well, if you want, you can consider it that way too.
try comparing chrome://process-internals/#web-contents with and without adblock active on a news site.
if we think that the goal of advertisers is to determine who the user/device is, adblock really does a lot, eliminating everything superfluous and leaving the page usable.
the tests I would also like to do is to determine how a chromium vanilla + adblock without fingerprinting protections behaves, on the assumption that they make it easier to determine the device, rather than hiding it.
but they are still vague thoughts...

[uazo]

fixing the width at 412 without changing the ratio, a kind of letterboxing in tor slang

I am getting closer to the goal:

as you can see, the rectangles are identical but the devices are different!
in the order:

• A14 - 560 DPI - 6.71" - 1440 x 3120 px
• A14 - 420 dpi - 7,59" - 1768x2208 px
• A11 - 420 dpi - 5.0" - 1080x1920 px
• A8 - 420 dpi - 5.0" - 1080x1920 px

with chrome

[PF4Public]

Would it be possible to detect your trick given the differing dpi?

[uazo]

Would it be possible to detect your trick given the differing dpi?

Well, the fact that the original values cannot be derived is part of the patch. Currently this is not the case.
Next step: running again the scripts I had prepared to check that indeed all devices report the same value.

[uazo]

Would it be possible to detect your trick given the differing dpi?

um... Actually, there is one thing I had not thought of, namely the elements docked at the bottom of the viewport.
Basically, I have to change the size of the viewport, enlarging it, otherwise the screen size is available.
By doing so, all fixed to bottom elements are not visible, because the viewport goes offscreen.
this will annoy some users...

[uazo]

implementing this feature does not seem simple at all.

I had to completely revise the first version I wrote: unfortunately it had problems during user pinch-to-zoom because setting a device-ratio to 1 grains the image during resize.
so I am now working on the another revision, directly on the "compositor" cc by presetting a fixed pixel ratio of 2.
by the way, I finally understood the difference between css, blink and device pixel space, the chromium team really made life difficult...
and I also understood why the current viewport protection patch grains the iframes: the fault of what they call css zoom, which in iframes is done after the compositor, on the gpu side, directly on the image produced in memory.

Would it be possible to detect your trick given the differing dpi?

there is also this to verify https://web.dev/articles/device-pixel-content-box

[uazo]

however, what seems strange to me, is that no one has ever investigated this and found a solution, but merely said that the differences in the production of the canvas used for fingerprinting are due to a different gpu, that's not true, that's not the case.

[uazo]

there are three different types of coordinates in chromium to which three different types of zoom are linked:

• the dpi space of the device
• the css space in blink
• the pixel space in cc

note that cc is not really THE compositor, but rather a middleware between blink and viz, where the latter communicates to the gpu, I don't know whether for historical reasons or to have an additional layer to separate the logic between different platforms.
speaking of android, DPI space is used in transformations between blink and native views, since coordinates in android are expressed in DPI rather than pixels.
Android (java side) controls the view size of blink by indicating the size in DPI and the pixel ratio to blink, although there is also a method that works the other way around, called ‘autosize’ but which is not active in android. The size is defined via the native view which is sized according to the space occupied by the java view, but it is possible to change it since there is a layer called webcontents (native side) in the middle.
Then blink and java work with different measures: for blink, the ratio of pixel ratio expressed by webcontents to the size of the view produces what is called pixel css.
Blink side the code gets a little dirty (and before I understood it, it took me a while): some values, such as the size of the browser controls, remain in DPI when the rest becomes CSS, perhaps the reason is historical.
At that point blink introduces the concept of a viewport, and the coordinates split between those referring to the page and those referring to the viewport.
The fortunate thing is that it seems that blink does not behave like other engines such as webkit, where the page coordinates follow the viewport coordinates, and that is fortunate because otherwise I could not have done anything.
Because, in chromium, viewport coordinates are handled by cc and are independent from css: I will act here.
Now, the complexity is that they are on different processes and interconnected through mojo, and so the changes become impactful, especially considering that I would like to tie this behavior to a content settings.
we'll see.

[uazo]

By doing so, all fixed to bottom elements are not visible, because the viewport goes offscreen.
this will annoy some users...

I may have found a way by reusing the code provided for handling the rootScroller particularly https://chromium-review.googlesource.com/c/chromium/src/+/578293

Now, the complexity is that they are on different processes and interconnected through mojo, and so the changes become impactful, especially considering that I would like to tie this behavior to a content settings.

Here again, I will try to reuse the code provided for disabling jit.

[uazo]

bad luck haunts me...
I have found a chromium bug with regard to viewport scrolling that I cannot identify and solve...

basically, with pinch-to-zoom active

• make the bottom bar visible
• go to the bottom of the page, any page
• make the navigation bar reappear
• try to scroll to the bottom

the bug is due to the clamp (of offsets) made by cc between the viewport and the content area, which is wrong and causes the page to ‘jump’ up and down to the end of the scroll.
behaviour is annoying, and certainly a source of notifications from users, and seems to have been introduced in one of the latest versions, because, for example, the v128 is immune to this problem, but it's like looking for a needle in a haystack...
very unlucky.. this is the first patch that is taking me almost two months to develop which will become even more (but I do not give up :)

[PF4Public]

but it's like looking for a needle in a haystack...

Is Chromium susceptible to this bug? You could try filing a bug against Chromium and see if they could figure it out ;)

[uazo]

Is Chromium susceptible to this bug?

yes, it is indeed a chromium behaviour, also visible in chrome.

You could try filing a bug against Chromium and see if they could figure it out ;)

I have opened other more serious bugs without getting an answer, so I am very sceptical, maybe I will try the mailing list of the blink team.
for now I decided to leave the bug, partly because I realised that it is also there in cromite and nobody noticed :).
I will continue with the tests, after rebasing at 132 (that if I don't do it these days, I won't have time to do it later)