From: V@nguard.LH   
      
   JJ  wrote:   
      
   > VanguardLH wrote:   
   >   
   >> What I couldn't tell from the CVE reports mentioned by Shadow is whether   
   >> or not the memory reuse vulnerability was in Javascript interpreter in   
   >> Firefox, as Shadow and yeti surmised rather blindly, or in some other   
   >> part of Firefox.  As you say, disabling Javascript in web docs won't   
   >> affect Javascript employed elsewhere.  Plus, the CVEs only mention some   
   >> memory pointer reuse, and never mentioned Javascript at all nor the   
   >> vulnerability was only within the scope of Javascript employed in   
   >> malicious web docs.   
   >   
   > It's likely both. Disability API requires JS to access, and memory   
   > management is beyond the reach of JS code.   
      
   Unless I'm mistaken, I thought proper and automatic memory management   
   was supposed to be a thing in JS.  So, the defect is in the API that is   
   part of Firefox, not in the web doc's JS that accesses the API, and   
   disabling JS only has scope on the web docs.  When the CVE mentions   
   memory reuse after release, didn't seem JS could do that.  In C, you   
   code the malloc() and free(), so devs were responsible for memory   
   management.  The JS engine does the alloc and free, and the JS engine   
   decides when to release (garbage collection).  Automatic memory   
   management in JS is supposed to avoid memory related issues that were   
   too often ailments in poorly coded C.   
      
   While the API was mentioned, it's possible the JS engine had a defect in   
   its memory management.  The JS engine devs can't get everything perfect.   
   However, you'd think the CVEs would target the JS engine as the cause,   
   and not an API which could be written in anything, like C.   
      
   > The first CVE may be a bug in Disability API object destruction routine. The   
   > second CVE may be a long standing bug in Firefox's general memory   
   > management.   
   >   
   > I always suspect that, Firefox's memory management has a problem which kept   
   > piling up little by little getting ready to blow up. If you use Firefox as   
   > your main browser, you might be aware of its long standing memory leak   
   > problem. Most notably, when browsing search results and accessing result   
   > items back and forth in Google Maps.   
      
   Unlike some users, I never leave the web browser running 24x7.  I use   
   it, then I exit it.  Even in Firefox Android, I use its Quit menu entry   
   to unload it rather than let Android leave it running in the background   
   until whenever its memory is needed for a newly loaded app.  I don't   
   have more than a dozen tabs open at a time.  So, I never encountered a   
   big memory footprint with Firefox, but then my use wouldn't tax it.   
   When I saw someone complaining about Firefox's memory footprint size,   
   they left Firefox running all the time, even when not using it, had   
   hundreds of open tabs, and left it configured to run background jobs   
   after it supposedly exited.   
      
   I remember when Mozilla belatedly moved to isolated processes to better   
   stabilize Firefox that there was a swarm of user reactions regarding   
   memory consumption.  But once you learned about Electrolysis in Firefox,   
   those concerns faded, so the ever growing memory footprint of Firefox   
   got rather forgotten.  The big change masked the little problem.   
      
   >> With uBlock Origin still usable in Firefox, you could define it to block   
   >> 3rd-party scripts, but not 1st-party scripts.   
   >   
   > IMO, the uBlock Origin's colored filter UI design is flawed. We have to   
   > block the domain name in order to block 1st party scripts of the current   
   > site. The "1st-party" setting alone doesn't do anything. I kept the old   
   > uMatrix (also based on uBlock) along side uBlock Origin, since it provides   
   > much finer control on this matter. I only use uBlock for URL based filter.   
      
   I guess I wasn't clear.  I wanted 3rd-party scripts blocked, but I did   
   want 1st-party scripts to run.  If 1st-party script filtering didn't   
   work in uBO, I wouldn't have noticed it.   
      
   Are you using uBO's Expert mode to get its grid on what to block?  That   
   isn't perfect, so you still had to define rules to tweak behavior.  Its   
   Expert mode with the grid looks like what you get in uMatrix.  I thought   
   uMatrix got rolled into uBO, but the layout is different.   
      
   I recall uBO had a Javascript option which blocked all JS regardless of   
   source.  You toggled the option to default to blocking JS, and then used   
   Expert mode when you wanted to all 1st-party scripts (and perhaps some   
   3rd-party scripts necessary for proper rendering or behavior of the web   
   doc to a minimum operational level).   
      
   Even uMatrix won't get you full control.  You might want to allow   
   1st-party JS, but disable some JS events, like onclick.  For example,   
   ##+js(ra.js, onclick, input[type=""]).  But doing so   
   requires learning a LOT more about Adblock Plus filter syntax.  The grid   
   views in uBO Expert mode or uMatrix will help, but you need filters for   
   further granularity.   
      
   Some sites want to add their search engine to your web browsers, and   
   many web browsers will do so without asking the user for permission.   
   So, I added the following to my user rules:   
      
   ! Block suggestion to add site's search engine to web browser.   
   ##link[type="application/opensearchdescription+xml"]   
      
   Unfortunately uBO Lite to support Manifest v3 became severely crippled.   
   However, Adguard's Adblocker MV3 extension does let me define user   
   rules, so I migrated by rule to there.  Adguard Adblocker extension also   
   lets me see a log to help in defining user rules.  uBO Lite fell behind   
   too far, so I moved to Adguard Adblocker.  In Firefox, both MV2 and MV3   
   are supported ... for now.  No promise for the future.  uBO is still   
   usable in Firefox Desktop.  Don't remember if Firefox Android (aka   
   Fennix) supports both Manifest versions, so you could still use uBO with   
   it instead of the crippled uBO Lite.  All the Android web browsers are   
   severely crippled compared to the desktop cousins that it is misleading   
   to share a product name to draw an unaware community to use on multiple   
   platforms.   
      
   >> I also used to block 3rd-party web fonts which   
   >> allow the font foundaries (most Google) to track where you visited,   
   >> perhaps even which page, when you visited, and how often.  Problem was   
   >> the pages could get rather difficult to figure out what a placeholder   
   >> icon would do when clicked on unless I dug into code, and that's way too   
   >> much trouble.   
   >   
   > That! I hate that too. Moreover most sites which use them for icons,   
   > they only need less than 25% of the font characters. Wasting more   
   > resources than what they try to save. The final result has bigger   
   > waste ratio.   
      
   The sites using 3rd-party fonts do NOT have to redirect clients to the   
   font foundaries to retrieve them.  The site could cache those web fonts,   
   so they become 1st-party fonts.  If they cache them locally, my   
   3rd-party font filter wouldn't block them since they are 1st-party.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)