Leaderboard

Additionally, and predictably, if you set Supermium to use New Moon's default User Agent, then Supermium is sent the tracking link version of the search results. Again, all server-side. The browsers are rendering what they are sent by the server.

But I feel like the TIME that was spent to demonstrate this PROOF is time WASTED. Because my name doesn't begin with a "D" so answers, despite 100% accurate and true, will never be "liked". Yeah, that was a rib-jab.

This thread is technically about Supermium (which is not being sent tracking links BY THE SERVER), your question is more about New Moon (which is being sent tracking links BY THE SERVER). Again, this is all SERVER-SIDE. The browser doing the rendering is rendering exactly what is being sent to that browser BY THE SERVER. And New Moon is being SINGLED OUT. Chrome/Chromium/Supermium/Catsxp/r3dfox - all of these are not being sent tracking links BY THE SERVER. It's all in the USER AGENT (in this case). New Moon without a useragent override (note: you have to hover over a search result link to see the tracking URL, it is not always shown in the address bar): New Moon with a useragent override:

I'd be more interested in a screencap from here -- https://mate.tools/vpn-detection-test Here is mine:

Current New Moon. Current 55 basilisk also show page without errors, after some seconds i see popup with message "We'd like to send you notifications." - maybe you use external adblocker with agressive profile?

I don't know if I'm the only one , but Aero Snap , Aero shake , shadows under icons (yes , that thick (bold) ugly Win7 shadows , were the first things I disabled when I tested Win7 on my new laptop a decade ago (which ,sadly, came with it). Also , never pinned anything to my taskabar , I don't know why , perhaps it's just a habbit. Well , as it seems , I'm not the only one who wants this off , here's a guide (for true Vista lovers , which for some reason need Win7 for testing) how to disable it , you're welcome : https://www.sevenforums.com/tutorials/3069-aero-snap-turn-off.html

FWIW, I don't believe that the slproweb distributed binaries have been optimised to load on SSE-only CPUs (I don't have the ability to test this hypothesis, though ), which is the case with Reino's DLLs. Personally, I prefer his for TLS-fingerprinting reasons... During recent months, many popular web services have been put behind aggressive anti-bot/anti-AI filters run by Cloudflare ; these filters treat web requests by yt-dlp as originating from a non-browser client (this is true, of course ) and block them "with prejudice" . On supported platforms (Windows 64-bit >= Win7), these blocks can be mitigated (not always successfully) by using the optional curl_cffi yt-dlp dependency and the associated "--impersonate" cmdline flag; but on 32-bit, especially when < Win7, this method can't be used ... One has to try other means of modifying yt-dlp's web requests, so as for them to have TLS fingerprints slightly different from the values inside CF's blocklists; in some cases, the use of the "--legacy-server-connect" flag might be enough, but usually it's not... Another method is to load the web service in a sanctioned browser, then extract session cookies and pass them to yt-dlp, along with the exact --user-agent the cookies came from; doesn't always work. If you are in a position to update the OpenSSL version bundled with the CPython installation used to launch yt-dlp with, then you have best hopes of beating CF's block (because their blocklists contain values generated from "stock" CPython versions, containing whatever "default" OpenSSL version assigned by PSF; usually one of the 3.0.x LTS branch). It's under the above scenario that Reino's DLLs can prove most helpful, because a) with their "special" configuration, they generate TLS-fingerprints deviating (in a good way) from a standard/mainline OpenSSL binary (like the ones from slproweb/overbyte) b) the link to them is less "prominent" in the web, so less prone to be found by CF personnel/bots and their TLS-fingerprints added inside an anti-bot filter; I have found these DLLs to be quite successful in "tough" cases, like the "dailymotion.com" one; so, many thanks Reino for those ... Best regards.

No, this makes things difficult for a server admin. Another site I admin on can often see bot swarms at levels that exhaust server resources (database specifically) and will make the site slow. So I've had to pull the access.log a couple of times and run it through an analyzer tool to find out just how these bots appear. The "good" ones, bots operated by legitimate (although some people may disagree) corporations, have user agents or other identifying information that they send along with their HTTP GET requests. These are bots like search engine spiders and AIs. The Western world bots from Microsoft, Amazon, XAI, etc are all identifyable and more importantly do not tend to bombard sites likely because a lot of information is already cached in datacenters. The corporate bots from SEA have user agents but tend to send way too many requests. The issue is tied between the SEA AI bots and the "unknown" variety that can be determined to be from an AI or LLM setup *somewhere* but they send no information along to the web server. So when 6,000 bots decide to hit the server at some point, 5% are legit western origin, 45% are legit eastern origin and the rest are the unidentified. Of course, many of the unidentified are not actual mysteries, but you can't determine that just from the logs. You'd have to research IP addresses, ports, GET strings, etc and it can be figured out. But this takes an incredible amount of time to not only research, keep up to date and set block/control lists on the server that using a go-between that already has most of this information tracked is very compelling. Especially since Cloudflare has a free option that many sites can use, this is likely why you end up seeing it used so much. All Cloudflare is, basically a software firewall that sits between a website and the user. Cloudflare shows different things to different browsers, browser settings (js enabled or not, etc) and based on perceived country or region of origin. There is also likely a difference between their free and paid version. I personally have not see any sort of captcha from Cloudflare in a long time, I only get a checkbox to prove I'm human.

This site, while it is "heavy", works fine in latest Serpent 52.9 here (asked me about cookies and all).

Here you go.

Tells us a lot about your location! I can. Screen 1 shows I'm from Switzerland and my IP. Screen 2 shows I'm from Switzerland. Hence Google is offered in: Deutsch, Français, Italiano for me. Screen 3 shows a random word I used in this Google search now. See - no Tracking links! Screen 4 shows "about me" Ungoogled Chromium 138 . Is this enough proof now? Are you satisfied?

They are actually and always have been. I don't update the upstream script anymore, but all that I locally changed was "openssl-3.3.1" to "openssl-3.6.1". https://github.com/Reino17/ffmpeg-windows-build-helpers/blob/master/ffmpeg_local_builds/cross_compile_ffmpeg.sh#L78-L104 C:\>openssl.exe version -a OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026) built on: Sat Jan 31 22:56:33 2026 UTC platform: mingw options: bn(64,32) compiler: /cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc -m32 -O2 -march=pentium3 -mtune=athlon-xp -mfpmath=sse -msse -DL_ENDIAN -DOPENSSL_PIC -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -D_WIN32_WINNT=0x501 OPENSSLDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/ssl" ENGINESDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/lib/engines-3" MODULESDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/lib/ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0xfed8320b078bffff:0x00405fc6f1bf97a9:0x0000003000000110:0x0000000000000000:0x0000000000000000 The last time I've updated the "MingGW-w64 Build Script" was 18 Sep 2022.

I investigated this myself and the reason appears to be that @Reino's DLLs haven't been "stripped" post successful compilation : https://en.wikipedia.org/wiki/Strip_(Unix) In an MSYS2 environment, $ strip libssl-3.dll will reduce the filesize from 1.22 MiB to just 890 KiB, while $ strip libcrypto-3.dll will reduce the filesize from 5.20 MiB to just 3.88 MiB Finally, as a general observation, different compilers will produce binaries with different filesizes, even when the source code is always the same; and, of course, using different compilation flags between two different compiler invocations will also produce binaries with (slightly?) different filesizes, even when the compiler and source remain unchanged... The DLLs obtained from slproweb were compiled using a "CL" compiler (MSVC C/C++), as you can see by running: openssl version -a => OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026) built on: Wed Jan 28 15:01:03 2026 UTC platform: VC-WIN32 options: bn(64,32) compiler: cl /Z7 /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG" -D_USE_32BIT_TIME_T -D_WINSOCK_DEPRECATED_NO_WARNINGS -D_WIN32_WINNT=0x0501 OPENSSLDIR: "C:\Program Files (x86)\Common Files\SSL" ENGINESDIR: "C:\Program Files (x86)\OpenSSL\lib\engines-3" MODULESDIR: "C:\Program Files (x86)\OpenSSL\lib\ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0x0000e39defebffff:0x0000000000000000:0x0000000000000000:0x0000000000000000:0x0000000000000000 These two are also linked to vcruntime140.dll (external MSVC dependency, thus this further reduces the DLLs's filesize). My educated guess is that Reino's DLLs were compiled with some flavour of MinGW/MSYS2 (as can be deduced from the linked GH issue ), and that compiler is known to produce larger binaries than MS's Visual Studio (but I could be wrong somewhere, without knowing all the finer details ) ...

Edge appears to be the same, so I guess it's a Chromium thing?

@mina7601 If I understood correctly, you did all from scratch, just for testing purpose?

And that's exactly what I prefer to do in most cases: manually as much as possible to gain full control. Unfortunately it's not possible in all cases. One can say a bit "old school" but I take it rather than a compliment. AIO packages can be great but they are not my favourites.

In step 4 of my guide I wrote: Therefore @maile3241's tip should work. BTW I made a shortcut in my start menu targeting this url: http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=en&g_sconsumersite=1

No problem. Do it when you are able to! Furthermore I have updated my guide completely and now it should be in a final state. The biggest change is in adding new steps at the end of my guide, but I think you have to compare it to your last version completely. Kind regards, AstroSkipper

It's the same with me! But there are users who have to unblock wuauclt.exe, for example like @mina7601, otherwise MU won't work for whatever reason.

@cc333 Unfortunately I had to update my guide once again. Just as info for you! Kind regards, AstroSkipper

I totally agree. No problems here at all. Very strange!

@mina7601 Is your Windows XP already activated?

I have had a very sad experience with HP laptop in 2007 . In fact , I hate HP - it's utter junk in my opinion ! For those who are lazy to read , I'll make this short: I had bought a quite expensive laptop it was approx 1500 Euro in 2007 , let me remind about the inflation , it's like 2500 or so nowadays. It was an expensive gift from me to myself for my jubilee. So one could guess how I started to hate Hewlett - Packard when it literally caught fire , right after 1 year warranty , almost at my next birthday. Yes , that's right , it was burning , it's videochip to be precise . Nvidia 8600GT 512mb with fast (by that standards) DDR2 128bit memory . HP cheaped out on the cooling system , as I was told by repairmen . It was so expensive to repair it , so I decided to buy Siemens instead (made in Germany) and it was very good , fast and durable , with Vista , of course . Edit : Forgot to mention specs . DDR2 4gb RAM Nvidia 8600GT 512mb Intel Mobile CPU (don't remember the exact model , I think Core Duo , but it was fast enough) Two separate HDDs (each 250GB)

Oh , it's no secret . Some of them are : Hellgate:London ( I like all those wonderful demons), Diablo II and it's addon , Sacred 1 (frequent) and 2 (rarely , I deleted it , it didn't entertain me enough to ever get back). I like the first one more , the 1st is kinda more realistic and bloody, there are programs that can make it run in full HD. Actually , I'm not a die hard gamer . Also, I played Road Redemption DX11, but on x64 system , deleted too , I think it needs more tracks in free game mode. But it's kinda reminded me of SEGA's Road Rash which I played in 1991. And what about you ?

No fight was intended , you started this marvellous topic about Vista , suddenly there are people that say other (newer WIndows) are somewhat ok too . And this is said among us (!) , Vista die-hard fans . How can it be ? This has been discussed a million times , go to Win7/8/9/10/11/12 forum and discuss it there , besides going off-topic is simply not polite.

Dear asdf2345 , I really appreciate your advice , but why would I wanna do that ? I see you are using Server 2008R2 , it's your choice and I respect it . But I use Windows Vista on all of my PCs. And this topic is about our pleasant experience with it. Please tell us about your experience with Vista.

This topic slowly turns into Vista vs. 7 nonsense ...