4 ms·
This is an entire class of vulnerabilities that would've never been possible with XUL, is that correct? I appreciate they had to move for other reasons but I a
by lol768 2y ago
This is an entire class of vulnerabilities that would've never been possible with XUL, is that correct?
I appreciate they had to move for other reasons but I also really don't like the idea that the DevTools and browser chrome itself now has all of the same security issues/considerations as anything else "web" does. It was bad with Electron (XSS suddenly becoming an RCE) and makes me pretty nervous here too :(
- emiliocobos 2y agoXul would've had the same issues.
- WorldMaker 2y agoXUL would have had worse issues because it could make arbitrary XPCOM calls to all sorts of native components and nearly the full gamut of native component issues written mostly in C/C++. XUL was in many ways always a ticking time bomb.
- fabrice_d 2y agoThe current frontend still has the same XPCOM privilege access from JS, so as emiliocobos said, XUL vs. HTML does not change the security boundary. It's only a different markup language.
- sebazzz 2y agoIt still surprises me parts of Firefox still use XUL.