NotHereToPlayGames

I'm seeing if I can find a non-Proxomitron solution. When it comes to the MSFN keylogger, all we need to do is prevent a specific javascript timer. But we cannot block all timers because then the reply box doesn't "expand" when you click inside the small reply box and it expands into the actual reply box. Proxomitron is smart enough to know which timer to block and which timer not to block. Most of the Tampermonkey solutions block the javascript "event" alongside the javascript "timer". Disregard - Proxomitron is a solution that works for me and it's too time-consuming to reinvent the wheel when I already have a wheel that works for me. Maybe a Tampermonkey / Greasemonkey / Violentmonkey / Userscripts guru will come along and offer something, but that level of scripting is kind of above my head, I can "see" (most of) what existing code does, but I cannot write the code from the ground up.

Yeah, I feared that was going to be the case for most folks. That was true in 2004 when I started using it. Still true today even with the "modern web" basically making it more vital than ever before.

That is valid for this thread - I personally do not agree with "OT" anywhere, not here, not there, if the conversation leads us here, then it is not "OT". [Well, "within reason", and we all know when "within reason" has been overstepped.] I agree that Firefox and Chrome can tackle CNAME "trickery" differently. What could be "OT" is if the Firefox + UBO method to prevent the CNAME "trickery" can not be ran on "Older NT-Family OSes". I don't run Firefox and I don't run UBO - so I rely on others for that info. I can speak towards XP + 360Chrome + NoScript + uMatrix and that combo has blocked each and every CNAME trickery that has been presented thus far. I have Proxomitron as a fall-back in the event that NoScript + uMatrix isn't going to be enough - but so far those two alone has blocked every CNAME "trickery" we have seen thus far.

Blocked without even having to try to block it -- since UBO / uMatrix blocks frames by default (well, my uMatrix does, I guess I cannot remember if that was "default" or not) -

@XPerceniol - are you using UBO or uMatrix? If so, visit https://www.mathon.fr and look at the UBO or uMatrix dropdown - Note that in my config, uMatrix "thinks" there is a script being allowed at www.mathon.fr - but they (plural) are in reality being "replaced" by one dummy script by Proxomitron and no scripts are being allowed. But if I allow that script, this is what the dropdown looks like - The key is that 16ao.mathon.fr - it did not actually come from mathon.fr, it arrived through CNAME trickery as a "subdomain". I now block ALL subdomains with my Proxomitron config. This also blocks media.mathon.fr (which I don't care about because it's a French web site that I'll never visit). But I can whitelist the media subdomain while still blocking the 16ao subdomain. Plus, with this approach, I could care less if 16ao changes to 17ao or 19zo or 20az, I could list a thousand, they are blocked by default and I didn't have to wait for a UBO "list" author to find it, update it, and redistribute the "list".

Not really. I personally feel VERY strongly that nobody should allow javascript on a web site they have never visited before. Then only allow the javascript on a whitelist basis. We "simply" do one more step - disable ALL subdomains and now only allow subdomains on a whitelist basis. "Zero-Day" virus definitions take DAYS, if not WEEKS, to be discovered, for antivirus developers to create the detection, for that detection to get updated in a database, for the end-user to receive that updated database. DAYS, if not WEEKS, that the end-user was left "naked". Which is how you are at 20,589 rules when the other week it was about 15,000. I guarantee you that the Proxomitron approach will protect you FASTER than "waiting" for your UBO list to find the offense, to update their list, and for your UBO to download that updated list.

I've already found half a dozen ways that Proxomitron blocks that CNAME example web site. The Eulerian comment tag, the more generic Analytics comment tag, blocking all scripts by default [something that nobody on the planet should not already be doing by DEFAULT] (SO WHAT if it makes your browsing experience a little less "user-friendly"!), break the "cn+i" portion of the script, break the .location tested against a "list", block all sub-domains unless whitelisted.

True. Also note that the only example we have seen thus far is already blocked if you don't allow javascript on https://www.mathon.fr/

Nope, not enough. Not to the best of my knowledge. You also need a web browser that supports DNS over HTTPS (DoH) - 360Chrome does not! What do you see when you visit here -- https://1.1.1.1/help

I will also point out this - Brave uses an embedded DNS resolver. 360Chrome comes with an embedded DNS resolver but we intentionally disable it. We do not want 360Chrome performing DNS queries so why would Brave users "want" that if it weren't touted as for CNAME purposes? Can Brave users prove that the embedded DNS resolver isn't sending "data" to Brave servers? Hint: the answer is no. I will take the Proxomitron approach

Keep "zero-day" in mind. More often than not, people get hit with a "virus" because they encounter them BEFORE their protection software ever heard of it and therefore no reason for them to have included it an their "definition database". Ah ah! Eureka! I will be blocking ALL subdomains using Proxomitron (only "allow" via a whitelist approach)! Not just eulerian. Not just the "twenty six" that the current UBO "list" contains. This way, I am protected from "zero-day" subdomains before the UBO "list" author even realizes that subdomain needs added to his/her "list". Whoala! That solution will work for me

Which version of Brave? Will it run on XP? If I can get the exact version of Brave that has an API to reveal CNAME, maybe I can find a way to add that API to 360Chrome.

I'm not getting the adobe.com stuff in v13.5 here so it must be related to ISP / IP.

Ha! One more reason for me to stick with v11 for as long as I can. I wonder if v13 build 2206 does that polyfill crap? Or if it is only v13 build 2212 and higher and v13.5?

Could also be an extention managing your cookies or passwords - do you have any extension for cookies or passwords?

Always a possibility. I've never seen anything but cdnjs.cloudfare.com and www.googletagmanager.com and I've always blocked both of them.

What log file? Are you referring to MSFN.org? I'm not seeing any adobe.com links in my log here at MSFN.org - only cdnjs.cloudfare.com and www.googletagmanager.com which are both being blocked.

Proxomitron is not going to be for everyone. My biggest thing is this, you can create uBlock rules to kill the keylogger on MSFN but that rule will do nothing for the 9,999 other sites that you visit where 1,234 of them are logging your keystrokes - you blocked the logger on 1 out of 1,234. But by killing the keylogger using Proxomitron instead, I have safeguarded myself on 1,000 of the 1,234 websites instead of just 1. Sure, there's still 234 out there still logging my keystrokes, but I've never visited them before and likely won't visit them in the future. And if I do visit one of them, I edit Proxomitron to include it also and now I'm up to 1,001. Drastic times call for drastic measures. Sure, it's only MSFN's keylogger "today", but will you catch the next web site that's logging your keys? Kinda doesn't surprise me. I've often opted to keep "older" extensions and disable any-and-all "automatic updates".

I can confirm that the "keylog" is being uploaded to MSFN servers. Why would we expect otherwise, I suppose. How? Because with Proxomitron I can "fake" my cookie by logging in, copying cookie contents, then logging out. Then I can use those cookie contents "in the future", a day, a week, a month, and see what the keylogger contained "yesterday" when accessing MSFN "today". The good news is that Proxomitron disables the keylogger by killing this "timer" (no uBlock required, just Proxomitron's default config in Advanced Mode) -

Please note how OLD those articles are. We shouldn't think that the sky is falling and our computers aren't "secure" based on OLD articles stating THEORIES. That's why I want to see a real-life example and screencaps "blocking" the CNAME trickery and "not blocking" the CNAME trickery. Hulu and KISSmetrics were SUED over ETag "respawning" in 2011/2012 - so while ETag "respawning" is a THEORETICAL vulnerability, nobody does them anymore so why jump through hoops over THEORETICALS ??? Like I say, I want to see a "before and after" screencap to truly assess the "issue".

My approach is going to be different than @Sampei.Nihira 's approach. Sampei.Nihira is using UBO lists and I do not use UBO (or uMatrix) "lists". My approach, once I can physically SEE proof of CNAME trickery, is to use Proxomitron lists/filters to prevent the trickery.

If possible, please create something like a "DNSQuerySniffer" or "TcpLogView" screencap of a specific web site (and provide the URL) of what internet traffic there is with the CNAME "blocked" and another screencap of what internet traffic there is with the CNAME "not blocked".

With all due respect, those screencaps are worthless! I can't read a d@mn thing! Are you doing this on purpose so that we can't recreate?

Yes, please

I will not be able to offer DRM assistance as all of the "workarounds" that I have found are basically "illegal" and I will not be the one to publicly disclose those "workarounds". There are several UA extensions on the Chrome Web Store, I suggest you start there first for your UA needs.