globie

D'oh!

We're talking about this line, right?

>The precision of outages (at :29 and :44) matches a network-synchronized clock (NTP).

I think this just correctly points out that if the trigger was something unsynchronized like animals chewing on wires or someone digging underground, you wouldn't have 61% of events occurring at these two second markers. Even if the trigger was something digital but on a machine that isn't NTP synchronized, you would eventually have enough clock drift to move the events to other seconds. 61% combined at two markers (exactly 15 seconds apart) strongly suggests synchronized time.

When writing this inflammatory post, you seem to have forgot the bigger picture of the thread you are flaming.

We're discussing whether it's right to take a second look from a security standpoint when a software implements WebRTC. In this case, it's nuanced, and the implementation in FFmpeg is very different than the more complete implementations you find in browsers. And when browsers have implemented WebRTC, many vulnerabilities have followed.

So the double-take is justified here, even if only in principle. No one is saying WebRTC is insecure, or FFmpeg, or node, or Linux..........

I did a cursory read of each CVE. Wherever you got the idea I did not, you must have forgot to include it in your post. Just now, I picked one from random. It reports "Multiple WebRTC threads could have claimed a newly connected audio input leading to use-after-free."

Does that exactly qualify as an "implementation bug"? I don't know, and I don't care, because how you taxonomize a CVE has nothing to do with whether it's a vulnerability that was introduced when implementing WebRTC. And it is.

I'm really surprised they do it at all. I always thought they'd be crazy to.

That's a good point. I suspect as the renewal period is shortened, scripts will attempt renewal faster and faster.

I hope they don't go any shorter than a month. Let the user pick, any value up to a year should do.

Right you both are! I had no idea.

Like many others have pointed out, Apple is obsessed with avoiding antitrust scrutiny. A fun (edit: incorrect) example: they are fine owning the device you use to connect to their own streaming service to watch their own produced TV shows, but appear to strictly avoid showing their products in those shows.

EDIT: I stand corrected! Multiple "Apple Original Series" contain Apple products, such as in Ted Lasso and (I think implied) in For All Mankind, as people pointed out below. Shows what I know about TV.

I wonder why some Apple Original Series have Apple products, and some don't. I would love to see if there's any correlation between the number of shows which feature a specific product and that product's market share in the show's region or demographic.

Yep, the embedded video in the article really says it all. Proven Industries' wording here at at the very least ambiguous as to whether or not a shim that works on one lock will work on another of the same model.

If you had to take apart the lock to make a shim for only that lock, of course that would be misleading to suggest otherwise. Instead, they're going directly after the researcher for demonstrating the insecurity of an entire line of locks.

Either the TSA should sue the man who published photos of the "Travel Sentry" keys, or Proven Industries should look into rebranding as "peace of mind" locks :)

Here's a (very) small sample gathered from a search for "webrtc" on cve.org and picking high-severity CVEs affecting browsers:

* CVE-2015-1260

* CVE-2022-4924

* CVE-2023-7010

* CVE-2023-7024

* CVE-2024-3170

* CVE-2024-4764

* CVE-2024-5493

* CVE-2024-10488

Of course, I agree that it's not relevant to ffmpeg. But seeing "WebRTC" triggers the same part of the brain that looks out for unescaped SQL statements. Good opportunity to point out the difference in this implementation.

I assume autoexec is referring to the plethora of WebRTC vulnerabilities which have affected browsers, messengers, and any other software which implements WebRTC for client use. Its full implementation is seemingly difficult to get right.

Of course, you're right that this implementation is very small. It's very different than a typical client implementation, I don't share the same concerns. It's also only the WHIP portion of WebRTC, and anyone processing user input through ffmpeg is hopefully compiling a version enabling only the features they use, or at least "--disable-muxer=whip" and others at configure time. Or, you know, you could specify everything explicitly at runtime so ffmpeg won't load features based on variable user input.

A "Fiduciary responsibility to shareholders" means exactly what I said: "legally bound to extract profit without these silly notions of empathy or trust".

The only notions of empathy or trust you see from publicly traded companies nowadays is the over-engineered calamity of ESG. If you have a single example of a moderately-adopted trend which demonstrates a genuine desire to do right by their society, or to build long-term trust at the expense of short-term profits, I'll readily adopt it into my world model.

I know, we're locking everything down behind WAFs and repeating captchas so only attested identities can get access in the end.

From the article it's sure starting to seem like people across the internet are just starting to realize what happens when you don't have just 3-4 search engines responsible for crawling for data anymore. When data becomes truly democratized, its access increases dramatically, and we can either adjust or shelter ourselves while the world moves on without us.

Did Google never ever scrape individual commits from Gitea?

My bad, I forgot I'm a liquid. It's too late to edit, but s/po\w*/poured over/ anyway :)