Live data from Hacker News

Actively exploited sandbox RCE in all Chromium versions

nvd.nist.gov

551–554 of 554 posts

Re: Actively exploited sandbox RCE in all Chromium versions

#551

Earlier quoted context omitted.

> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox. It's easy to be safer, as long as performance can be sacrificed for it.

> easy to be safer It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.

Sure, but compare that to the effort it would take to have the same safety guarantees without any drop in performance.

Re: Actively exploited sandbox RCE in all Chromium versions

#552
post #516

Earlier quoted context omitted.

You're just offering non-helpful ivory tower criticism without even understanding the problem space (which is actually one of the hardest open research problems in software engineering, cs.PL + formal methods). But if I'm wrong, dare say, how would you write a production memory-safe JIT compiler today ?

If I couldn't guarantee memory safety, I wouldn't. We're talking about an optional feature for JavaScript engines. Security is where the rubber hits the road. It's whether customers' identities get stolen. It's whether leaders of undemocratic countries can monitor communications, locations, and social networks of people whom they oppress. Calling this an "ivory tower" criticism is, ironically, a lack of acknowledgeme…

[deleted]

Re: Actively exploited sandbox RCE in all Chromium versions

#553

Earlier quoted context omitted.

The features of HTML are still greatly limited. You can’t really create applications with just one HTML page and no client-side rendering. You can play a video, sure, but that’s not an application. You can also do magic with CSS but that’s an experimental fun thing, not a thing people actually do. As soon as you, say, use JS to update the DOM or a canvas, I consider that client-side rendering. That you can do, and th…

You can inline the following in one HTML page: CSS (.css) JavaScript (.js) Plain Text (.txt) HTML (.html) SVG (.svg) Raster Images (.png, .jpg, .jpeg, .gif, .webp, .bmp) Audio (.mp3, .wav, .ogg) Video (.mp4, .webm) JSON (.json) PDF (.pdf) plus bring in other source resources as needed. To answer your question: The installer for GrapheneOS / Google Pixel phones is an “SPA” (or “webapp”). I’ve seen bespoke fitness trac…

Right, but if you’re dynamically changing the HTML from JS, like the graphemeos website does, then that’s client-side rendering, which is my whole argument. Embedding the JS in HTML makes zero difference, it’s the same thing.

So, they are truly inseparable IMO. You can’t have a SPA without some amount of client side rendering, your example demonstrates that. So, what makes a SPA a SPA is the rendering. A SPA is “single page”, but only in literal meaning. Logically, every SPA is many pages, you just render them purely client-side.

Re: Actively exploited sandbox RCE in all Chromium versions

#554
post #545

Earlier quoted context omitted.

The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Becaus…

That is surely not the case for C#, contrary to most JVM implementations, on the CLR CIL is always jitted before execution since .NET 1.0, and this not taking into account AOT scenarios like NGEN (since .NET 1.0), and everything that came later as AOT toolchains. The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET worklo…

You’re correct, where I got confused is the lazy per-method JIT and the tiers of JIT optimization. My understanding is that dotnet only compiles on first function call, or when it has to for things like generics. So, some code is never compiled if it’s never executed. And then, functions will be re-JIT at higher optimization levels under certain conditions later. You certainly know more about this than me, but yes I was wrong about conditional JIT.
Post reply on HN