Ben Markson

In a previous life I did a bit of XUL Firefox add-on development so I thought I'd take a quick peek at the Revert Site add-on: Revert Site by steeev+ I concur. As of v1.2.2, for Windows, it appears to set the User Agent to: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2661.102 Safari/537.36 This is set in background.js starting at line 102: // Switch User Agent ... the Windows NT 10.0 bit is hard-coded. I'm guessing you could probably substitute your favourite OS. There is also this small CSS tweak: div.fbPageBanner {display:none} This hides the "To help personalise content, tailor and measure ads and provide a safer experience, we use cookies. By clicking on or navigating the site, you agree to allow us to collect information on and off Facebook through cookies. Learn more, including about available controls: Cookie Policy." ... which to my mind should really say: remember to clear all Facebook cookies once you're done! Disclaimer: I don't use Facebook Ben.

As always, nothing is straight forward... Microsoft: We're getting rid of Flash by the end of the year - except you can still use it Adobe Flash Player EOL Enterprise Information Page Unhelpfully the document doesn't allow Copy but the Enterprise Enablement section starts on page 28. The Silver Bullet appears to be to add EOLUninstallDisable=1 to mms.cfg (this sits in C:\WINDOWS\system32\Macromed\Flash) How easy it will be to get hold of HARMAN's versions of Flash Player, who knows. Ben.

To get MSE green see; https://msfn.org/board/topic/177099-which-antiviruses-are-known-for-a-fact-to-be-working-on-xp-sp3-as-of-2019/?do=findComment&comment=1166107 I have since increased 0000016d [365] to 000002da [730] I also stopped MSE from connecting to MS every day - it's a useless check in any event - and this is a way to stop it connecting: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Signature Updates] "FallbackOrder"="FileShares" "DefinitionUpdateFileSharesSources"="C:\\MSE" FilesShares means to look for the definition update in DefinitionUpdateFileSharesSources - that source folder needs to contain the sub-folder /x86, so in this example we would have: C:\MSE\x86 (MSE appends x86 or x64 depending on the OS). The x86 folder needs a definition update file on or prior to 1.293.2807.0 - I'm using an mpam-d.exe for version 1.293.908.0 When MSE checks that file it decides its current version (1.293.2807.0) is better and exits. No error, no logging, pretty much instantaneous. Ben.

Recently - maybe in the last week or so - the Rotten Tomatoes search results have stopped rendering. Here's an example: https://www.rottentomatoes.com/search?search=firefox#results_movies_tab ...where there should be a single result listed. Under both FF52 original and basilisk52-g4.6.win32-git-20200620-34cf555-uxp-c05d07a68-xpmod, I can see the data is actually there [<script id="movies-json" ... "url":"https://rottentomatoes.com/m/firefox" ... </script>] but it's not getting rendered as actual results. Compare this to FF77 where we see #shadow-root elements appearing in the page's html. It is inside these #shaow-root elements that the results appear. Soo, does anyone know the story behind the webcompoants (aka shadow dom) stuff? I notice that the latest UXP changes included these: - Bug 1426494 - Share more code between nsIDocument and ShadowRoot (43725c726) - Bug 1429656 - Implement ShadowRoot.activeElement (5e7917e2c) - Bug 1430299 - Add DocumentOrShadowRoot interface (bbd59105d) ...which sounds tantalisingly as if it should support the shadow dom stuff. Or am I missing something blindingly obvious? Ben.

Assuming I've followed this correctly could you use your own personal proxy server like The Proxomitron? Ben.

Just in case it's of help I use the add-ons UAControl and User-Agent JS Fixer under FF52.9 - together they provide a default, and per site, user agent strings through a simple UI. Ben.

Right-click the reg key Signature Updates and go into Permissions... give yourself Full Control, then you should be able to change the entries inside. Ben.

For anyone still struggling to bite the bullet by installing a replacement to MSE (so far I'm finding them all downright scary if not outright destructive and it is just reminding me why I switched to MSE in the first place) these MSE registry changes seem to do two things. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Signature Updates] "ASSignatureDue"=dword:0000016d "AVSignatureDue"=dword:0000016d ...where 16d = 365 days They stop the 2001 Event ID errors for Microsoft Antimalware, plus - and this did surprise me - my MSE has turned from orange back to green. This is deceptively comforting as it is obviously purely cosmetic. Even so MSE is not entirely useless as it is still doing its job even as the signature files become increasingly out of date. I'm guessing this gives 365 days before MSE thinks the 1.293.2807.0 definitions are too old. I'm also guessing the value could be increased even further. Ben.

Very long time lurker and roll-my-own-updates MSE user. In case it's of any help to someone it is still possible to fetch the mpam-d.exe file that can be executed as is (i.e. MpSigStub.exe is executed). To do this you must first have established the two 'base' signature files for the 15900 engine: mpasbase.vdm and mpavbase.vdm - as already described in this thread. Thereafter you can use a URL as if you are using the 15900 engine version (even though we are still using the 15800 engine): http://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x86&prod=EDB4FA23-53B8-4AFA-8C5D-99752CCA7094&eng=1.1.15900.4&avdelta=1.293.312.0&asdelta=1.293.312.0 ...where you supply the delta values according to what you have installed so far. From there you can just execute mpam-d.exe and it will update the delta signature files: mpasdlta.vdm and mpavdlta.vdm - this should work until the engine version changes again. Ben.