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.

Were you running certbot multiple times per day?

Looking at the relevant limit, "Consecutive Authorization Failures per Hostname per Account"[0], it looks like there's no way to hit that specific limit if you only run once per day.

Ah, to think how many cronjobs are out there running certbot on * * * * *!

[0] https://letsencrypt.org/docs/rate-limits/#consecutive-author...

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 :)

I don’t think people appreciate the degree to which information is siloed, intentionally and unintentionally, in the federal government.

Thanks for that. Information can be completely siloed and the statements "If a company knows something about you, so does the government(s)" and "This is exactly the state of affairs the government prefers" still be correct.

Is your belief that the federal government has not actually purchased hordes of corporate surveillance data? Or is it that because there are examples of information being siloed or not available, that means it's okay or a non-issue that Americans' data that was once unlawfully collected is now still unlawfully collected but also collected by corporations and purchased wholesale by the federal government?

Do you believe the disaggregation of those monoliths helps to put the "hypothesis to bed"? It sure seems like you were listing "constant litigation" over "records request" as counterevidence of the claim that "if a company knows something about you, so does the government(s)".

If anyone in the U.S. government is extracting data from companies in a manner which is unlawful or should be (and they sure are), I see that as strong evidence of the hypothesis. Pointing out that local agencies may have to fight for their access in court doesn't change that it "is exactly the state of affairs the government prefers".

They only need to pay off or install a single employee to get total or near-total access. Consider this chart from 2013 showing when various tech companies were added to PRISM:

https://upload.wikimedia.org/wikipedia/commons/c/c7/Prism_sl...

A lot of the companies embattled in the "constant litigation" mentioned by the GP are featured in this very chart.

In the vast majority of cases, the US government at least, has to obtain a warrant to collect data on US citizens, so those two sets are not the same

If only that were true[0][1][2][3].

[0] (2022): https://fedscoop.com/dhs-buying-personal-data-from-govt-cont...

[1] (2023): https://www.congress.gov/118/meeting/house/116192/documents/...

[2] (2024): https://www.cnn.com/2024/01/26/tech/the-nsa-buys-americans-i...

[3] (2025): https://theintercept.com/2025/05/22/intel-agencies-buying-da...

I... you're right. I was wondering why the world was only 9x9x9, there's 46k lines showing each block can have air, stone, grass, dirt, log, wood, leaves, or glass.

I kind of like it.

Without a doubt the most impressive thing I've seen with CSS.

This immediately brought "A Single Div"[0] to mind, which stood as the coolest CSS demo I'd seen for... 11 years!

This one takes the cake. I'll be pouring over it. Thanks!

[0] https://a.singlediv.com/

The people behind Cloudflare engineer this issue for profit, which is a very different motive than to "solve" the problem.

The people most interested in doing away with the problem altogether are not Cloudflare, but its customers.

If you have a single server flooding spoofed traffic, it appears as a DDoS to the victim. It's at this point that the distinction between DoS/DDoS breaks down slightly.

It is very much not "trivial" to buy 100Gbps+ of DDoS. I'm highly confident the majority of D/DoS attacks are from single servers, because it works. If you have a 10Gbit server and your target has 1Gbit (or you 1Gbit and them 100Mbit, it still happens), it's not a question of if you can take the target down, but how long you can sustain that traffic level before your upstream notices.

Painting every D/DoS as the most bandwidth ever is a play out of Cloudflare's marketing. If every website operator knew that 1, you don't need that much bigger of a pipe, and 2, you shouldn't buy pipes that charge you $20+/TB like AWS anyway, then Cloudflare would have a much harder time selling you a downgrade in quality, and we would have faster and cheaper networks to boot.

Do you ever find that advocating for these tenets feels "weird" nowadays? As in, don't you know these publicly traded companies are legally bound to extract profit without these silly notions of empathy or trust? What do you expect them to do? To start acting silly?

This conclusion stems from that it is much easier to launch a DDoS from a single server w/ spoofed traffic than to use a botnet. If you have a single 10Gig server, you will likely not be able to take down another 10Gig server unless the target is already doing near 1gbps[0]. I believe most "noise" DDoS which effects random website operators is considerably less than 10Gbps, and pretty much every giant attack uses spoofed traffic which can be blocked upstream without a WAF. So long as your upstream is big enough.

[0]: I made it up, again.

What website? I'm guessing it is not health related or a "critical resource" if you are cheery about 1% of users being blocked?

For people who put stuff online to help people as well as to extract pure profit, knowing the anguish of your users really helps look out for them.

Simple: Connect larger NICs and do "dumb" DDoS filtering at your fattest point.

Consider an HTTP daemon serving static content on a physical server. If that physical server has a 10Gig NIC it will withstand 90%[0] of the real-world DDoS attacks which would affect the same server with a 1Gig NIC.

"Dumb" DDoS filtering means blocking UDP and SYN floods, and other simple attacks. Your goal is essentially to block traffic which could be spoofed, making your downstream traffic somewhat attributable. Many ISPs provide functions like this, and is not nearly as complicated or invasive as letting Cloudflare MITM every bit of your traffic.

Any effort past that point should just be made in caching static assets, and optimizing dynamic pages. If your website uses sessions, you can implement basic rate controls very easily. No WAF required!

[0]: I made it up

Of course it could claim lives. Hopefully Prince has considered people have also likely died as a result of Cloudflare's repeating captcha which holds the next page in front of you like a carrot on a stick, never letting you know that you will be clicking that box forever.

I'm sure while someone's in the process of keeling over is the perfect time to arbitrarily scrutinize their connecting details. You need to contact your doctor ASAP. Okay, but did you neighbor have a virus last week? Is your neighborhood in your city more "problematic" than average? You may have forgot to check these details before you fell ill.

Cloudflare sites should come with a big banner warning all users their connection will be arbitrarily approved by an algorithm with chilling effects built in as dark patterns.

Last I checked, Cloudflare does basically no educating of customers how badly their website will be broken for users arbitrarily when they don't use the ISP or browser Cloudflare likes. No explanation for how many customers you will lose when your website can't be visited by someone who doesn't know how to change their IP, no explanation that if you're offering a critical service then Cloudflare will give that service thousands of tiny downtimes left unknown, the screams too quiet to carry the weight of a tech CEO worried about something similar.

You understand the problem here may repeat itself elsewhere as well, right?

I do, and how is this to cap off our discussion:

You move your money to another bank, because the increased security annoys you.

On my way out, I would quote Benjamin Franklin: "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."

I go out of my way to help my community, and I expect those I support to do the same. That bank could put more resources into investigating/catching the robbers who are attacking not just the bank but the security and liberty of their community, or it could treat every customer with more suspicion than they did yesterday. I know where the latter option leads, and I won't stand for it.

You're right that it repeats itself elsewhere. Often, I find.

To those who see securing genetic privacy rights as a critical issue, what would you recommend they do? Just wait and Vote Harder Next Time?

I think Americans overall would very much support their PII being recognized as such, and to prevent the wholesaling of their genetic data.

Energy spent pointing fingers and throwing hands up would be better spent researching, educating the public, lobbying congress, and drafting legislation to support genetic (or general!) privacy. The corporations lobbying both sides against any kind of privacy regulation are the ones who have constructed the mirage that the entire party opposite of you will undo any attempt you make to improve things.