MichaelArnold
Banned - Spamming the forum + PBM
- Mar 23, 2022
- 11
- 3
1) Each antidetect browser is made on the basis of a regular browser engine. This is usually Chromium or Firefox. The fundamental differences in the internal structure of the engines are so great that with the help of javascript on the page, the site can always determine in which engine the page of the site that we are viewing is actually loaded. This means that the anti-fraud knows if your browser is based on IE, chrome, or ff.
Hence the first rule for working with an antidetect browser:
Use the UserAgent corresponding to your antidetect engine.
For example, if your antidetect is made on Chromium, and your axis is a Mac, then use the most common UserAgent of Chromium on a Mac, for example Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36
2) Iron does not have to be unique. It should be "the same as everyone else."
The hardware characteristics of your pc are reflected in the following prints:
Canvas simple (2d) - with assumptions, is not unique within each version of each OS. The differences in prints are due to the difference in font smoothing mechanisms in different operating systems.
WebGL (aka Canvas-3d) - in this case, the picture is drawn directly through the video card (if 3d acceleration support is enabled in the browser and in the os / virtual machine), and inside the browser by its built-in renderer (if 3d acceleration support in the os is not available, or disabled in the browser), is not unique for each combination "os + video card + video card driver" in case there is support for 3d acceleration, and is not unique for each combination of "browser + os" if support for 3d acceleration is absent/disabled. On a sample of 1kk US traffic at the time of this writing, 16% of users did not have support for 3d acceleration on their PCs.
Audio is not unique within each version of your device's audio chipset.
There are no other ways to identify your hardware through the browser on the desktop, for example, to find out the serial number of the hard drive or processor or the color profile of the monitor. On mobile phones, an accelerometer (and data on its calibration) is added to the list, but this is a topic for a separate article.
The more not unique each of these prints, the fewer questions to your device, tk. it is "the same as everyone else." None of these fingerprints uniquely identify your device, but it allows you to provisionally define its "class" (for example, "PC with discrete video", or "phone, probably an iPhone"). And the best way to keep these prints believable is to leave them alone. No kidding.
The second rule for working with an antidetect browser:
Don't touch your iron prints
3) When we use a proxy from another country, the question inevitably arises about changing the displayed language, time zone, and possibly a set of fonts corresponding to your locale (in the case of working with Asian markets).
There are three main ways to change the values of languages, time zone, screen resolution, etc., returned via javascript in the browser:
rewrite these functions in the source code of the browser, before compiling it. This is the most reliable and most difficult to define method.
inject into the working process of the tab and intercept calls to the desired functions in real-time. Technically difficult, because offsets and function addresses float with every browser update.
overwrite the values we need directly on the page via javascript, after initializing the page we are viewing. The easiest to implement, but the most disgusting way, because it is really difficult to do it unnoticed. Almost all antidetect browsers have chosen this path, by which they framed their users.
Do not touch or modify anything on the page/site via javascript
Let's go back to theory to understand how a site / antifraud can detect that browser setting have been tampered with via javascript.
Most often, we need to change the language of the os to match the user's location. In addition to being passed to the site in the header Accept-Language, it is available to js through a variable navigator.language.
Conclusion
Is everything really that bad on the antidetect market? Yes, at the moment, absolutely everything is lousy.
Such an irresponsible attitude of the majority of antidetect developers to their clients and their material is not what the industry needs. The market needs knowledge, transparency, and competition. In my heart I expect that there will be more players who are guided by the principle “do it right, it will be okay”, not “it will do just that”.
"So what kind of antidetect should I use?" My answer is "none", But ...
... the convenience brought by the management of dozens of profiles from one program is captivating, and if you still need an antidetect browser, at the moment take MarketerBrowser - with some assumptions you will not be ashamed of it.
Hence the first rule for working with an antidetect browser:
Use the UserAgent corresponding to your antidetect engine.
For example, if your antidetect is made on Chromium, and your axis is a Mac, then use the most common UserAgent of Chromium on a Mac, for example Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36
2) Iron does not have to be unique. It should be "the same as everyone else."
The hardware characteristics of your pc are reflected in the following prints:
Canvas simple (2d) - with assumptions, is not unique within each version of each OS. The differences in prints are due to the difference in font smoothing mechanisms in different operating systems.
WebGL (aka Canvas-3d) - in this case, the picture is drawn directly through the video card (if 3d acceleration support is enabled in the browser and in the os / virtual machine), and inside the browser by its built-in renderer (if 3d acceleration support in the os is not available, or disabled in the browser), is not unique for each combination "os + video card + video card driver" in case there is support for 3d acceleration, and is not unique for each combination of "browser + os" if support for 3d acceleration is absent/disabled. On a sample of 1kk US traffic at the time of this writing, 16% of users did not have support for 3d acceleration on their PCs.
Audio is not unique within each version of your device's audio chipset.
There are no other ways to identify your hardware through the browser on the desktop, for example, to find out the serial number of the hard drive or processor or the color profile of the monitor. On mobile phones, an accelerometer (and data on its calibration) is added to the list, but this is a topic for a separate article.
The more not unique each of these prints, the fewer questions to your device, tk. it is "the same as everyone else." None of these fingerprints uniquely identify your device, but it allows you to provisionally define its "class" (for example, "PC with discrete video", or "phone, probably an iPhone"). And the best way to keep these prints believable is to leave them alone. No kidding.
The second rule for working with an antidetect browser:
Don't touch your iron prints
3) When we use a proxy from another country, the question inevitably arises about changing the displayed language, time zone, and possibly a set of fonts corresponding to your locale (in the case of working with Asian markets).
There are three main ways to change the values of languages, time zone, screen resolution, etc., returned via javascript in the browser:
rewrite these functions in the source code of the browser, before compiling it. This is the most reliable and most difficult to define method.
inject into the working process of the tab and intercept calls to the desired functions in real-time. Technically difficult, because offsets and function addresses float with every browser update.
overwrite the values we need directly on the page via javascript, after initializing the page we are viewing. The easiest to implement, but the most disgusting way, because it is really difficult to do it unnoticed. Almost all antidetect browsers have chosen this path, by which they framed their users.
Do not touch or modify anything on the page/site via javascript
Let's go back to theory to understand how a site / antifraud can detect that browser setting have been tampered with via javascript.
Most often, we need to change the language of the os to match the user's location. In addition to being passed to the site in the header Accept-Language, it is available to js through a variable navigator.language.
Conclusion
Is everything really that bad on the antidetect market? Yes, at the moment, absolutely everything is lousy.
Such an irresponsible attitude of the majority of antidetect developers to their clients and their material is not what the industry needs. The market needs knowledge, transparency, and competition. In my heart I expect that there will be more players who are guided by the principle “do it right, it will be okay”, not “it will do just that”.
"So what kind of antidetect should I use?" My answer is "none", But ...
... the convenience brought by the management of dozens of profiles from one program is captivating, and if you still need an antidetect browser, at the moment take MarketerBrowser - with some assumptions you will not be ashamed of it.
