Once JavaScript is running, it can perform complex fingerprinting operations that are difficult to circumvent effectively.

I have a little experience with Selenium headless on Facebook. Facebook tests fonts, SVG rendering, CSS support, screen resolution, clock and geographical settings, and hundreds of other things that give it a very good idea of whether it's a normal client or Selenium headless. Since it picks a certain number of checks more or less at random and they can modify the JS each time it loads, it is very, very complicated to simulate.

Facebook and Instagram know this and allow it below a certain limit because it is more about bot protection than content protection.

This is the case when you have a real web browser running in the background. Here we are talking about standalone software written in Python.

▲

cylemons 3 days ago | parent | next [-]

How does testing rendering work? Can javascript get pixel data from the DOM

▲

Beretta_Vexee 3 days ago | parent [-]

https://www.w3schools.com/tags/canvas_getimagedata.asp

	▲	cylemons 10 hours ago \| parent [-]
		So the way this works is to draw fonts/svgs inside the canvas and check the pixels, that makes sense

▲

dylan604 3 days ago | parent | prev [-]

why can a bot dev not just get all of these values from the laptop's settings and hardwire the headless version to have the same values?

	▲	Beretta_Vexee 3 days ago \| parent [-]
		Because the expected values are not fixed, it is possible to measure response times and errors to check whether something is in the cache or not, etc. There are a whole host of tricks relating to rendering and positioning at the edge of the display window and canvas rather than the window, which allow you to detect execution without rendering. To simulate all this correctly, you end up with a standard browser, standard execution times, full rendering in the background, etc. No one wants to download their YouTube video at 1x speed and wait for the adverts to finish.