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.

My guess is companies will simply pretend like generated code is copyrighted, file fraudulent DCMA notices if leaks happen and hope no one decides to challenge them in court.

That page describes a few recent CS people in AI arguing intelligence is being able to predict accurately which is like carpenters declaring all problems can be solved with a hammer.

AI "reasoning" is human-like in the sense that it is similar to how humans communicate reasoning, but that's not how humans mentally reason.

Of course those were first built in the 19th century.

If someone from the UK calls me on the phone and I start reading them posts on 4chan, is the UK going to fine me too?