NotHereToPlayGames

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.

To the best of my knowledge, you can't. 360Chrome can not do DRM.

lol, cool, and thanks. Basically "semi-retired" at the moment.

Right-click on top of the text you want your extension to change the size of and click "Inspect" then look for something like this -

I would try to elliminate the * and target specific tags instead. Then add to the list of tags as you find them in-the-wild. You shouldn't need to use the body overflow-x this way. /* Limit font size */ a, p, div, h1, h2, h3, h4, h5, h6, span { font-size: 14px !important; }

Found a solution, but unsure if this is your expectation or not. Are you accustomed to having to scroll to the right for "wide" pages with this font extension? Because what msn.com is doing is declaring an @media screen and (min-width: ) declaration and intentionally hiding the horizontal scrollbar. You can revert to having a normal horizontal scrollbar by using this as your Custom.css - /* Limit font size */ * { font-size: 14px !important; } body { overflow-x: unset !important; } Or we could attempt a font-size that utilizes @media screen and only adust accordingly - I'll let you try the above and go from there if it's not exactly what you had in mind.

I see the problem. Will do some digging and report back.

I'm also wondering if this could be a use for .css clamp() ? But that may make it more difficult than needed.

Hmmm... Well, I didn't go so far as to install your extension but I like the method that you used for a CustomCss. I'm kind of reading between the lines here, but my hunch is that you use a custom operating system DPI or that you have a default zoom to enlarge EVERYTHING but then you end up with fonts that were already large being TOO LARGE. So you normalize everything to a default 14px and then your DPI or zoom puts that 14px where you can read it. What happens if you change your * { font-size: 14px !important } to body, html, * { font-size: 14px !important; } Note that I also have an intentional ; right after !important - it souldn't matter but I'm pretty sure all css declarations are supposed to end in one, not sure.

Please do not post the same exact question into three different threads.

Please do not post the same exact question into three different threads.