91–100 of 150 posts
Earlier quoted context omitted.
because qtwebengine isn't updated nearly as often and this appear to be a recent bug not a long running one.
Thanks, I didn't think about that.
Earlier quoted context omitted.
> JavaScript engines with any kind of usable performance are inherently complex Depends on what you're using it for, surely? If you're just watching videos or scrolling through the news (where the JavaScript takes a back seat) then wouldn't any implementation be fast enough?
> just watching videos [...] (where the JavaScript takes a back seat) If you're talking about media websites like YouTube, Netflix, Amazon Prime Video, Twitch and so on or even just videos on sites like Facebook, video streaming actually needs a lot of JavaScript behind the hood. Some of it even being already performance-sensitive today.
Type confusion in V8... May well impact Cloudflare workers too.
Yeah wondering if this also a 0 day for node.js and electron apps...
Node.js and Electron aren't designed to do that in the first place, so this doesn't really affect them.
Earlier quoted context omitted.
> just watching videos [...] (where the JavaScript takes a back seat) If you're talking about media websites like YouTube, Netflix, Amazon Prime Video, Twitch and so on or even just videos on sites like Facebook, video streaming actually needs a lot of JavaScript behind the hood. Some of it even being already performance-sensitive today.
Why would that JavaScript be performance-sensitive?
Earlier quoted context omitted.
You don't seem to understand what I wrote so I'll explain it: - imagine a slow-but-secure browser, 10 to 100 times as slow and using 10 times as much memory as stated by the parent poster - imagine your bank and payment processor using a minimal amount of Javascript on their sites to make it possible to use that secure-but-slow browser without incurring too big a performance penalty Do you now see what I mean? It is…
The dangerous assumption here is that whatever sandbox you put the bad browser in actually contains it.
Earlier quoted context omitted.
If your Electron app executes third party, remote code. But if it does, you should definitely not use it.
>If your Electron app executes third party, remote code. There's a high chance that it does because of embedded content/ads/iframes/in-app browsers.
Earlier quoted context omitted.
If your Electron app executes third party, remote code. But if it does, you should definitely not use it.
>If your Electron app executes third party, remote code. There's a high chance that it does because of embedded content/ads/iframes/in-app browsers.
Genuinely asking here. I've never written an Electron app personally so I don't know how this stuff is done exactly, but the idea of in-app browsers in Electron apps sounds terrifying to me, security-wise.
Earlier quoted context omitted.
There is no indication yet that this is due to complex web standards. It could be, but we literally dont know what the bug is yet.
But we do know that it is Javascript-related, so please correct me if I'm wrong but disabling JS for all websites except the ones you really, really trust and need should offer long-term general protection against such 0-days in most cases.
I'm not sure i would call js part of "complex new web standards". In its original form it was introduced way back in 1995.
Earlier quoted context omitted.
>If your Electron app executes third party, remote code. There's a high chance that it does because of embedded content/ads/iframes/in-app browsers.
Are in-app browsers in Electron even secure in the first place? Does it use Chrome-style sandboxing with multiple processes, etc.? Do bugs in the Electron engine get patched in a timely fashion? Genuinely asking here. I've never written an Electron app personally so I don't know how this stuff is done exactly, but the idea of in-app browsers in Electron apps sounds terrifying to me, security-wise.