rockdoe

How many of those are false positives though? Probably just over 5000?

You get bug bounties if you report the kind of bugs Mythos identified. There's a reason no-one collected bounties from the "5000 defects" Coverity identified.

The Mythos reports have several examples of chaining a whole bunch of logic in different parts of the program together to exploit something very subtle. The Coverity reports aren't anything like that. These tools aren't remotely in the same league or even universe.

I think that if you hit the crash in the same line of code many times, you can safely assume it's your own bug and not a memory issue.

If it's only hit once by a random person, memory starts being more likely.

(Unless that LOC is scanning memory or smth)

If the crash is isolated (no other reports) and flipping one bit in the crashing pointer value would make the pointer valid, it's assumed to be a bitflip. This obviously will only catch a minor portion of bitflips, i.e. any image or video data with bitflips wouldn't crash.

From what he's saying they run an actual memory test after a crash, too.

If this were so all devs for apps, games, etc... would be talking about this but since this is the first time I'm hearing about this I'm seriously doubting this.

But they have?

What's the expected behavior of a JavaScript program that allocates all memory on the machine?

I'm pretty sure I saw them present on exactly this at FOSDEM?

Wordfeud uses a different board layout.

has had basic support merged

I read the parent post as saying that this is the problem, i.e. that "complete" support is a mess, because AFAIK even the reference implementation is incomplete and buggy, and that then getting angry at the consumers of it is besides the point and won't lead anywhere (which is what we see in practice).

Browsers supporting a format "a little" is almost worse than not supporting it at all, because it makes the compatibility and interoperability problems worse.

Are there any small engines that have enough of the web implemented that they can run it?

Why would those need a lot of Rust dependencies then? If you want to hand-roll stuff, hand-roll! no_std is a thing because people use it.

Small companies with little development experience like Google and Mozilla.

(You can check the files I linked and see audits between deltas for minor version updates)

The Tauri app just uses the system WKWebView. Memory usage can be misleading due to reporting, see e.g. https://github.com/tauri-apps/tauri/issues/5889

Yeah not sure how it qualifies as lightweight...

Ah yes, then the vendor goes out of business and they have to bring in highly paid consultants to fix bugs in the vendors' gcc 2.95/Linux 2.6.x port to their SoC.

You need to be in the right kind of company - the one where waiting for the external vendor to fix their shit is too slow.

FYI Google and Mozilla audit all their dependencies and share them:

* https://chromium.googlesource.com/chromiumos/third_party/rus...

* https://searchfox.org/mozilla-central/source/supply-chain/au...

It's quite likely that most of your dependencies were already audited.

In C/C++ every project ends up with a hand coded replacement for those external dependencies that is less well written and infinitely less tested.

Firefox and Chrome (and thus Edge, Brave, OperaGX, etc etc) do the same for many allocations - it's safer to crash than to end up in an obscure failure path that never had its error handling exercised and may accidentally be security sensitive.

FhG and Dolby did eventually put up a list of patents you are licensing from them.

It makes for some funny reading if you're familiar with the field. (This should not be construed as legal advice as to the validity of the pool)

Opus isn’t patent free

The existence of a patent pool does not mean there are valid patent claims against it. But yes, you may be technically correct by saying "patent free" rather than "not infringing on any valid patents". That said historically Opus has had claims against it by patents that looked valid but upon closer investigation didn't actually cover what the codec does.

Just looks like FUD to me. Meanwhile, the patent pools of competing technologies definitely still don't offer indemnification they cover all patents, but have no problem paying a bunch of people to spew exactly this kind of FUD - they're the ones who tried to set up this "patent pool" to begin with!

It's not like putting that message there will stop those complaints, more like the opposite.

There's no reason sites from 2000 would no longer work, unless they use APIs that weren't properly standardized.

I guess that's why it recommends Chrome. Hah.

As a first step, I'd appreciate reducing the risk of javascript extracting contents from outside the browser.

But that means essentially reserving a core for the browser only. I don't think that would be shippable by default.

The idea being that the main process and content processes should never be on the same core?

I would worry about cross site leakage. From my understanding that would be unavoidable as soon as you have more tabs open than cores, which feels like an unworkable restriction.

Imagine opening a 9th tab and bring told you need to upgrade your 3700X to a 3900X.

although Opus is very nice, it's not as efficient ... as HE-AAC

Uh, no, this is not correct. If you try to find a source, you'll easily find the opposite is very well established.

I can't tell whether you're kidding or not, but this is exactly the path Firefox was advocating: https://blog.karimratib.me/2022/04/23/firefox-webmidi.html

The page implies it no longer requires permissions, but I just tested and you definitely get a permissions popup, just a different one.

WebHID, WebUSB and Filesystem Access are IIRC, "considered harmful" so they won't get implemented. And Sensor support was removed after sites started abusing battery APIs.

"Firefox's implementation is based on the wgpu Rust crate, which is developed on GitHub and widely used outside Firefox."

Why is there no response from Kahng to G&M's rebuttal of his experiments?

The rebuttal was published less than 2 weeks ago, so that seems a bit early, and it is public, so reading it would answer several of your questions.

https://www.annagoldie.com/home/statement

It's explained in the Wired article that is linked that this was indeed the cause.

The independent reproduction that the IEEE article talks about also tested the method from the leaked paper from Chatterjee and concluded that his method indeed beats CT in almost all cases at a fraction of the computational cost.

The response from G&M to the independent reproduction emphasizes their method was used for production hardware at Google, was in a peer reviewed paper, and that their GitHub repo had a lot of forks and stars (I'm not making this up). Near the end it then raises several technical objections.

Isn't it more like that computing these flags is basically free in hardware? So might as well add support for it.

Previously people pointed out that a lot of the extra M1 stuff (like TSO, x87 FP) is already standardized and/or has shipped in other ARM chips.