[1] https://www.law.cornell.edu/uscode/text/31/3729#b_1

There is not one single legal definition of "knowingly" that applies to all laws and claims in the US.

Furthermore, even under this specific law, you need to prove the accused acted in "deliberate ignorance of the truth or falsity of the information", which has its own standard of evidence which is not exactly trivial.

Bottom line: companies like Meta build in plausible deniability because it's legally more effective versus the alternative, even if it's not bulletproof.

If software improved to the degree that hardware and physics-level exploits were the easier, we would be in a world 100x more secure than what we have now.

The real question you should be asking is why is it not “game over” right now given that most people would only hope in their wildest dreams that they would be so lucky that worrying about Rowhammer and the like would be a good use of time compared to the other much larger gaping software holes.

Work-based flushing exists to batch work to amortize overhead. It allows you to tune how much time you spend in overhead in a work period. However, this can result in unbounded delay.

Time-based flushing targets a worst-case latency in low throughput environments. This ensures you do not get unbounded delays. Interestingly, this also allows you to tune how much time you spend in overhead in a work period.

So, with work-or-time based flushing what you are really tuning is how much time you are willing to spend in overhead in a work period and balancing that against latency.

As a nit, the article calls this a derivative of Nagle’s algorithm, but it is basically the opposite. Nagle’s algorithm is about batching until acknowledgement with no mention of time. In fact, the lack of time-based flushing in Nagle’s algorithm is why it interacts so poorly with TCP Delayed Ack.

To explain more seriously, almost all visible cyberattacks are carried out by profit-motivated criminals. This has a very clear cost-benefit analysis; your revenue is hacking organizations and extorting them for available money, and your costs are developing and deploying attacks. The ROI is outrageously good easily being on the order of 10x to 100x. If it is so easy and so profitable why do not they just hack all of the millions of organizations on the planet with millions of dollars of available cash for trillions of dollars of revenue? Sure, all they have to do is create a trillion dollar revenue commercial organization bootstrapping themselves with no outside investors, loans, or access to financial resources or the financial system.

I mean, it took Mark Zuckerberg 20 years and a metric ton of VC investment and public investment to make 200 billion dollars in revenue. So what kind of loser can not make a commercial organization 5x larger with a trillion dollars in revenue in less time with no outside investors? Are they even trying? Just make more revenue than any other commercial organization in the entire world and extract that money in a freely usable form, how hard can that be?

They are not there yet, but they are trying. If you look at cybercrime reports you see something like 3x-10x growth year over year. Ransomware reports from a few years ago were showing a 3x year over year growth in number of attacks and simultaneously a 3x year over year growth in ransom amount with the averages being on the order of 100,000 dollars. Chump change for any serious organization, but give that a few years of 3x and that starts to look like real money. However, as it becomes real money it becomes harder and harder to launder it into a usable form. Sure, you could hit someone for 30 million dollars, but how are you going to get that into your bank account? Cryptocurrency helps some, but even there the big money tries to steer away from large overt crime. Maybe you could launder a few tens of billions a year that way, but that is still a far cry from the trillions for everything everywhere.

And of course even assuming you can scale your organization 10x year over year it still takes a decade of sustained growth, scaling your hiring and organization across 9 orders of magnitude, to get to billions per year. A literal decade even if you were growing at a outrageous pace for a outrageous amount of time just to reach a fraction of the total addressable market. A decade of that and you are still nowhere near blowing up all the power plants. Give it time, we need a lot of bears to get there.

5.9 homicides per 100k annually [1]. Assuming the average person who commits homicide commits 1 homicide in their lifetime (known homicide distributions support this) then that is 5.9 new murderers per 100k annually. Distributed over expected lifetime that would be 200-350 murderers per 100k.

So, if the US successfully imprisoned every murderer and only murderers, it would still be ~25th (~Nicaragua) to ~80th (~Russia). Nearly 2x the total incarceration rate of France and 3x the total incarceration rate of Germany if only murderers were incarcerated and we used the low estimate.

If we assume that homicide is relatively rare compared to severe physical violence that most nations consider worthy of incarceration, then just imprisoning all violent offenders in the US would likely require 1,000+ per 100k at the low end, over twice the actual rate in the US.

[1] https://www.cdc.gov/nchs/fastats/homicide.htm

You have a fixed number of small-size block allocators (say 8-256 bytes) and then a sequence of exponentially-sized large block allocators.

For small-size block allocators you want limited allocator overhead, limited over-allocation, high speed, and likely the ability to support certain alignments like 8, 16, and 64 (cache line). Attaching a requested size and actual size (or even just one) to every block would be tremendous overhead.

For large blocks you care less about allocator overhead and over-allocation since it is less overhead as a percentage. So, attaching requested size and actual size to every block is a small cost. However, you likely also want the ability to support certain alignments like 4K, 16K, 2MB, etc. (natural hardware or OS sizes).

So, you generally want two distinct strategys and bookkeeping mechanisms based on the size of the allocation. If deallocation does not take the requested size, then your very first problem is figuring out which mechanism you are using. The problem with this is that you want small-size allocations to have small overhead, so the discrimination mechanism must also be small-overhead.

If you pass in the requested size, then it becomes trivial to distinguish with zero allocator overhead. Is it less than 256 bytes (or whatever small size you choose)? Cool, it is small-size. Round up to the nearest small-size block. Release the memory to the identified small-size block allocator. This has zero per-block overhead, is totally trivial, extremely fast, and preserves alignment.

If the allocated size is in the large-block regime, then you know you can use a per-block overhead scheme. Except, this is still better. If you do not know the requested block size, then you are limited to either a header at negative offset or a auxiliary data structure keyed on the pointer value to determine the actual size. The former messes with your alignments and the latter requires the allocator to be stealing unrelated memory for its own data structures. If deallocation tells you the requested size, then you can easily use a footer scheme instead. Just always over-allocate enough space for a footer and then you can always just jump forward by the requested block size to find the footer and you do not mess up your alignments.

Getting the requested size, which the caller is basically always already remembering via type information, gives you a lot of advantages and optimization levers.

You know how they currently spend lots of money designing and focus grouping to see if the average consumer will get the wrong idea about the product? They have to do the opposite. If they spend lots of money on the advertisement (enough that you would reasonably focus group, etc.), then you need to focus group until their impression of the product is something you would not disagree with in a court of law.

Why did they do that over a purely informational advertisement depicting the soft drink and explaining the taste and ingredients? I would consider such a advertisement clearly acceptable.

They have to demonstrate why their advertisement showing people having fun on the beach is intentionally truthful and non-misrepresenting relative to the consumer impression following the advertisement. I am sure they have focus groups who can answer your question. Ask them.

Sounds like a court battle that could last for years and years. And in the end I think they would win for the simple reason that they can defend the advertisement by saying the image of people having fun at the beach and enjoying their drink is the intended use of the product.

And this is supposed to be easy? There are millions of companies advertising out there and the government is going to pursue these long court battles against all of them to prove their intent?

Proving intent to deceive is almost impossible in far more straightforward situations. What you have proposed is ridiculous, draconian, and would not be at all effective without essentially shutting down all media and installing a censorship bureau. So much for free speech!

As we know, false commercial speech is already, rightfully, not protected by freedom of speech. However, the standards for such have been so thoroughly blinded for the benefit of liars to the detriment of society as to fail to detect attempts to deceive so obvious that even children can tell let alone more subtle attempts.

Instead, the standard should be strengthened. Commercial speech should need to affirmatively “prove” it is non-deceptive and safe for consumption in reasonable proportion to the resources allocated to its production. Commercial speech should become more truthful and accurate and immune to misinterpretation the more resources that are allocated to it unlike the status quo where is becomes more deceptive.

This is a standard that is trivial to achieve for anybody with interest in the truth. Dry, informational statements that err on the side of caution are obviously acceptable. If you are producing a advertisement at substantial cost then instead of using your focus group budget on making sure the targeted consumer is thoroughly deceived, you will need to use it to make sure they only believe things you would also affirm in a court of law.

I colloquially call this the “Technically, your honor…” standard. If you say that you should probably lose.

This is not to say that the standard is that nobody in the entire world comes to a false belief, just that the overwhelming majority do not.

Reasonable defenses would be:

1. The false belief is not beneficial to the marketer.

2. The false belief is so small as to be immaterial.

3. The person with the false belief is not reasonably in the target demographic. (Nuanced statements might be misinterpreted if not in target demographic)

4. The interpretation leading to the false belief is unreasonable. (People can just be unreasonable and stupid)

5. The false belief is unexpected and could not have been reasonably detected given the resources allocated. (Minor mistakes and blindspots are acceptable, you can not account for everything, but you must account for more as more effort is used).

Who is the judge of their claims?

* Is it a judge in a courtroom? That will never work, as the courts are already overloaded and you're talking about adding hundreds of millions of additional cases to the docket per year.

* Is it a government regulator? That will make the Patent & Trademark Office look like a lemonade stand. You would need tens of thousands of people reviewing ads every single day.

And how do you presume to keep this regulator from being "thoroughly blinded for the benefit of liars to the detriment of society?" All regulatory bodies are subject to regulatory capture pressures.

The same one it always is, the finder of fact for that legal proceeding. This is really basic stuff. It is even more absurd that you did not even have the standard finder of fact amongst your options.

> That will never work, as the courts are already overloaded and you're talking about adding hundreds of millions of additional cases to the docket per year.

That is possibly the most inane argument I have heard in a long time. Adequate judgements against now illegal behavior will strongly disincentivize behavior relative to the past where it was legal. If running afoul of the new law resulted in a 100% of yearly revenue fine do you really think everybody would be chancing those odds resulting in hundreds of millions of additional cases? Obviously not; then my point is proven. Of course what you would actually do is scale the fine until it is commensurate with the desired degree of disincentivizing or until the undesirable behavior becomes unprofitable; the unreasonably gigantic fine I used as a thought experiment above is just there to demonstrate that your point is utterly inane.

You have already claimed above that the burden of proof is on the advertiser to prove that their advertisement is legal. This is a guilty-until-proven innocent system, so ALL advertisements will be part of legal proceedings.

Advertising is ubiquitous. You want to create a regime where all advertisements must be submitted for approval before publishing. You have not demonstrated how this could be made remotely practical, given the enormous volumes involved.

Essentially all modern high speed hardware is batched and asynchronous. The way to get high speed performance is to batch and asynchronously submit operations then wait for batchs of asynchronous completion. In addition to being more efficient to process, batching also enables "smart" hardware to more efficiently schedule the operations if needed since it has more context.

Batching many of the reads you want upfront reduces the need for as much speculative read buffering because you are more capable of telling it "all/most" of the information you actually want instead of it having to guess that you are going to do linear reads. The reads being asynchronous, which is what the hardware does, allows you to issue speculative reads explicitly. If you intend to read a 1 GB file then the userspace I/O library can fire off 1,000 1MB reads and then you can wait until the "next" desired portion of the data comes back before continuing your processing. This is in contrast to issuing a 1 GB synchronous read followed by your processing which delays your processing by the time of the entire read even though the hardware I/O can happen in parallel.

Essentially, the only remaining case where you then want meaningful speculative read buffering (beyond the default efficient block size of the hardware) is that you either do not understand your access patterns enough to batch them, or you have a data-dependent load pattern which happens to regularly resolve to something within the speculative read buffer. For instance, you read 8-bytes which tells you the offset into the file where the desired record is and that record happens to be nearby almost all of the time.

For writes, what you want is a data-or-time flush strategy which is actually just the flush strategy you should use in basically all cases where you do buffering. Data-based flushing exists to achieve efficient batching. Issuing large amounts of small operations kills you with overhead, so you buffer the operations to attempt to coalesce them into larger operations where the overhead is amortized away. However, if inadequate data is generated to reach the data-based flush condition, then you get large or potentially unbounded latency. You resolve this by also targeting a worst-case acceptable latency in low throughput conditions. In that case your overhead has been "amortized" away as a percentage of your processing time since the processing time was long enough to reach the time-based flush condition. What you are effectively doing is allocating N% of your time to completion to overhead which either fires if you generate enough data to amortize it away or if you generate enough time to amortize it away.

Writes being asynchronous also allows you to resolve the data loss issue (if the hardware cooperates). You fire it off and wait for the hardware to signal persistence of that write. Until you see a asynchronous completion for that asynchronous write, you can not assume it is persisted. You achieve ordering by issuing a write barrier which tells the hardware to signal completion of the write barrier when all writes earlier in the asynchronous queue have signaled completion. This can also be further extended to other layers if desired to allow the detection of various levels of "persistence".

Unfortunately, Linux and other Unix derived systems use the awesomely terrible fsync() model which is antithetical to efficient I/O. Instead of you issuing a write barrier and then getting notified when it completes, allowing you to continue to asynchronously issue subsequent writes, you synchronously wait for all earlier I/O to complete. This serializes execution as you wait ensuring that any attempt at ordering or persisting data is monstrously expensive. In fact, this is so horrible that hardware manufacturers realized they could massively improve their throughput benchmarks by lying about when data is persisted so the fsync() would complete faster ensuring that their throughput benchmarks would not get shot due to data persistence latency which is a different property. With a asynchronous model you can just rapid-fire the operations and the write barriers (which is the way the hardware is designed to operate) allowing you to evaluate both read/write throughput and data persistence latency without confounding them. This is both dramatically more useful and more efficient.

Every target is worth attacking, but there are not enough bears to eat everybody. Sure, the bears are breeding, but exponential growth does not look threatening until it suddenly is.

I don't think the "breeding rate" was the limiting factor.

It reminds me of a bit from the book Lying For Money [0], where the author notes that you can often find multiple layers of scams attached to other scams, just like meta-parasite in biology.

[0] https://www.simonandschuster.com/books/Lying-for-Money/Dan-D...

Let us look on the front page and see if there are any, oh look here is one: https://www.binarysecurity.no/posts/2026/10/one-root-case

I’m not even blaming Zuck for that, he didn’t really invent it, though he certainly popularized it — he just made an astute observation of the dynamics in software and turned it into a company motto.

As is what constitutes the standard of “adequate.” Which BTW is the standard in ALL engineering (not just security or software) because we live in a world where economic pressures apply and costs must be managed. Trivial example: bridges only use an “adequate” amount of steel and concrete because they are not free. The word “adequate” fundamentally involves the concept of tolerances. There’s a reason we consider over-engineering a bad thing.

So which development approach would you say is better correlated with good security outcomes?

Another way to look at it is, bureaucracy is an aspect of the corporate culture, and lasting security comes down to having the right culture. At least in that respect Microsoft is doing something right. Doubtlessly a lot of that bureaucracy is ineffective, but it's a signal that the cultural intention exists.

As a relevant counterexample, we've never heard of these kind of processes at Meta and so you get Cambridge Analytica.

My perspective is skewed by my experience being on a security-adjacent platform team for years. Our biggest challenge was not external threats, it was internal teams seeing us as friction on their productivity, to the extent that it regularly led to escalations.

So when Cambridge Analytica happened, I played it up for all it's worth; Meta may move fast because they didn't have our "bureuacratic team", but look where it got them! Unfortunately the $25B penalty happened just last week... I'd have gotten infinite political mileage out of that.

My bridge that collapses is adequate and acceptable because other people make even worse bridges that collapse even easier? No, the bridge still collapses, everybody gets a F.