Systematic use of terror as a policy to induce fear in the general public to push them to coerce their government's policy was not widely used.

This could be bad or it could not, but I simply can't take anything seriously that uses ambiguous terms so linked to woo.

Miles is simply a proxy for exposure.

Given risk here does vary by exposure time and trip length varies so much, it seems reasonable to use - at least in combination with crude rates.

In India, for instance, dairy cattle are fed almost exclusively on crop residues and by-products. Crop residues being what's left over in the field after you harvest and by-products being what would otherwise be waste left over after you process for human use.

Elsewhere, in addition to crop residues/by-products, you also have natural grasslands that aren't planted or irrigated, legume feed grown between major crop seasons when you can't grow anything else that also replenishes the soil and feed grown on otherwise marginal land or barely managed land.

Certainly some crops grown for cows would be edible by humans or the land repurposed for growing crops edible for people, but there's often a cost involved like heavier fertilizer requirements, pesticide use, water requirements, added infrastructure and/or labor.

There are permanent US bases in the region.

1. U.S. commitment to ensure no further acts of aggression

2. Continued Iranian control of the Strait of Hormuz

3. Acceptance of Iran's nuclear enrichment rights

4. Lifting of all primary sanctions

5. Lifting of all secondary sanctions

6. Termination of all United Nations Security Council resolutions against Iran

7. Termination of all International Atomic Energy Agency Board of Governors resolutions against Iran

8. Payment of damages to Iran for loss in the war

9. Withdrawal of U.S. combat forces from the region

10. Cessation of hostilities on all fronts, including Lebanon

Which is much different.

[0] https://english.news.cn/20260408/dd8df6148df94252aaa1d3fbb59...

No say (or at least, no influence) might be a bit strong given foreign election interference.

I'm sure if Britain or France or whoever wanted to, they could have their intelligence services release dirt on candidates or engage in some dirty tricks.

How likely is it that they're not using their latest and greatest for their own projects though? Perhaps their ability to find security flaws is surpassed by their ability to create them.

It should be that if tcp_now gets stuck before (<) (2^32 - 30000) ms from boot, it would cause deadline timers for reaping TCP_WAIT would always be greater than tcp_now because it wouldn't wrap. If stuck at or after (>=) (2^32 - 30000), it would cause them to potentially be reaped faster they should be.

Actually looking at the code a bit more, it looks like calculate_tcp_clock() is run at least once per hour even when there's no TCP traffic or sockets open, so getting into the state where it never reaps TIME_WAIT sockets which would be hard to predict if this would happen.

It also looks like if tcp_now gets stuck, other tcp timers may have problems as well.

    tcp_now   = 4,294,960,000  (frozen at pre-overflow value)

    timer     = 4,294,960,000 + 30,000 = 4,294,990,000 - MAX_INT = 22,704

    TSTMP_GEQ(4294960000, 22704)
    = 4294960000 - 22704
    = 4294937296
    = 4294937296 >= 0 ?  → true! (not false)

A bug similar to what the blog described can happen however if tcp_now gets stuck at least 30 seconds before it it would have wrapped. Since tcp_now is only updated if there is TCP traffic, this can happen if there is no TCP traffic for at least 30 seconds before before it would roll over (MAX_INT ms from boot).

It's should be easy to prevent the latter from happening with some TCP traffic, though reaping TCP_WAIT connections early isn't great either.

If tcp_now stops updating at <= 2^32 - 30000 milliseconds, then TSTMP_GEQ(tcp_now, timer) will always fail since timer is tcp_now + 30000 which won't wrap.

This does look like it is possible since calculate_tcp_clock() which updates tcp_now only runs when there's TCP traffic. So if at 49 days uptime you halted all TCP traffic and waited about a day, tcp_now would be stuck at the value before you halted TCP traffic.

In cases where tcp_now gets stuck at > 2^32 - 30000, it looks like TCP sockets in the TIME_WAIT will end up being closed immediately instead of waiting 30 seconds, which isn't great either.

https://discussions.apple.com/thread/250867747

Mac `grep -c` counts lines that match, so it always prints 1 line, so piping to wc -l will always return 1.

Or just open up and do netstat -an |grep TCP_WAIT and just watch it. If any don't disappear after a few minutes, then you're seeing the issue.

$ netstat -an | grep -c TIME_WAIT

If the count it returns keeps growing, you're seeing a slow leak. At some point, new connections will start failing. How soon depends entirely on how quickly your machine closes new connections.

Since a lot of client traffic involves the server closing connections instead, I imagine it could take a while.

It's unclear if it'll leak whenever your mac closes or only when it fails to get a (FIN, ACK) back from the peer so the TCP_WAIT garbage collector runs. If it's the latter, then it could take substantially longer, depending on connection quality.

That can only happen if the extension itself leaks it to the web page and if that happens, scanning isn't necessary since it already leaked what it is to the webpage. It also doesn't tell you what extension it is, unless again, the extension leaks it to the webpage.

The attack on Chrome is far more useful for attackers as web pages can scan using the chrome store's extension ID instead.

Seems like it would be a nightmare to provide evidence of what parts of a half a million line codebase were written by humans if no one bothered to track it.