Bug 1833793 Comment 23 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
(In reply to Greg Stoll from comment #18)
> FWIW I haven't been able to figure out why the block isn't working. eoppbrowser.dll doesn't attempt to load in my dev build, and I can't seem to debug an installed version to figure out why it's able to load there. It is noteworthy that when eoppbrowser.dll loads it loads very early. (right after ntdll.dll and before kernel32.dll)

This may have been caused by the broken DLL blocklist on Win 7 (fixed in bug 1837242) (or maybe it's ESET themselves bypassing the blocklist?). Anyway, the volume is concerningly high again now that `1.0.90.0` is widespread, so maybe the block was working on most machines after all? I think we should definitely try to block `1.0.90.0` for 116 release and 115.0.4esr.
Revision 1 by
on 
(In reply to Greg Stoll from comment #18)
> FWIW I haven't been able to figure out why the block isn't working. eoppbrowser.dll doesn't attempt to load in my dev build, and I can't seem to debug an installed version to figure out why it's able to load there. It is noteworthy that when eoppbrowser.dll loads it loads very early. (right after ntdll.dll and before kernel32.dll)

This may have been caused by the broken DLL blocklist on Win 7 (fixed in bug 1837242) (unless it is ESET themselves bypassing the blocklist?). Anyway, the volume is concerningly high again now that `1.0.90.0` is widespread, so maybe the `1.0.88.0` block was working on most machines after all? I think we should definitely try to block `1.0.90.0` for 116 release and 115.0.4esr.
Revision 2 by
on 
(In reply to Greg Stoll from comment #18)
> FWIW I haven't been able to figure out why the block isn't working. eoppbrowser.dll doesn't attempt to load in my dev build, and I can't seem to debug an installed version to figure out why it's able to load there. It is noteworthy that when eoppbrowser.dll loads it loads very early. (right after ntdll.dll and before kernel32.dll)

This would probably have been caused by the broken DLL blocklist on Win 7 (fixed in bug 1837242) (unless it is ESET themselves bypassing the blocklist?). Anyway, the volume is concerningly high again now that `1.0.90.0` is widespread. I think we should definitely try to block `1.0.90.0` for 116 release and 115.0.4esr.
Revision 3 by
on 
(In reply to Greg Stoll from comment #18)
> FWIW I haven't been able to figure out why the block isn't working. eoppbrowser.dll doesn't attempt to load in my dev build, and I can't seem to debug an installed version to figure out why it's able to load there. It is noteworthy that when eoppbrowser.dll loads it loads very early. (right after ntdll.dll and before kernel32.dll)

This would probably have been caused by the broken DLL blocklist on Win 7, fixed in bug 1837242 (unless it is ESET themselves bypassing the blocklist?). Anyway, the volume is concerningly high again now that `1.0.90.0` is widespread. I think we should definitely try to block `1.0.90.0` for 116 release and 115.0.4esr.

Back to Bug 1833793 Comment 23