> This would explain why HTML entities are so effective.

Could also be that they learned that sending spam to obfuscated addresses doesn’t gets much response. Such messages might get filtered out more and/or addressees might be less inclined to reply to it.

I think Elon made loads of money from full self driving, without Tesla even delivering it once.

He personally might have made money on Cybertrucks, too.

I don’t see this article showing that. They query for extensions that could be used to do that, and that likely already is illegal, but those queries could solely be used to uniquely identify users (grabbing more bits makes it less likely to get collisions)

The list of queried extensions includes things that would be used by particular religious groups, and people with certain medical conditions.

Those being in the list doesn't mean that's what they're looking for. Take a look at the database of extensions, there's far more extensions that don't seem limited to any particular group. The author just called those out specifically because they're perfect for implying nefarious intent.

> doesn't mean that's what they're looking for

It does suggest that’s what they’re collecting. That is per se a violation in many jurisdictions. It should trigger investigations in most others to ensure it wasn’t mis-used.

The claim I replied to is “They try to profile for things like political beliefs”.

I wasn’t contesting that they query extensions that can be used for that purpose, or that they use query results for that purpose, but indicated that the fact that they make such queries doesn’t necessarily imply that they try to do such profiling.

From the "Why It's Illegal" section:

>Political opinions

>LinkedIn scans for Anti-woke (“The anti-wokeness extension. Shows warnings about woke companies”), Anti-Zionist Tag (“Adds a tag to the LinkedIn profiles of Anti-Zionists”), Vote With Your Money (“showing political contributions from executives and employees”), No more Musk (“Hides digital noise related to Elon Musk,” 19 users), Political Circus (“Politician to Clown AI Filter,” 7 users), LinkedIn Political Content Blocker, and NoPolitiLinked.

>Each of these extensions reveals a political position. If LinkedIn detects any of them, it has collected data revealing that person’s political opinions. Article 9 prohibits this.

https://browsergate.eu/how-it-works/: “Every time you open LinkedIn in a Chrome-based browser, LinkedIn’s JavaScript executes a silent scan of your installed browser extensions”

⇒ which Chrome allows sites to do.

TLDR: the idea is

- to have a convention to, instead of signing “payloads, to always sign “type identifier + payload”, to prevent adversaries from reusing your signature to sign the same payload, interpreted as a different type.

- use 64-bit type identifiers

- put the identifiers in the IDL (may need augmenting IDL to allow that)

#1 makes sense to me; #3 also makes sense, as that’s the place where people will have to look to learn about your types.

#2, I think, is up for discussion. These could be longer, Java-like strings “com.example.Foo”, or whatever.

I think some people also may disagree with the argument that putting type identifiers inside the payload makes messages too large, but I don’t have enough experience on that to make a judgment.

What’s wrong with

  #define var auto
  #define function void

? ;-)

It follows tradition (https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd...)

Also, some compilers will accept 'foto' + i, interpreting 'foto' as a hex constant 0x666F746F.

Similarly, 'bigImage' may be interpreted as a 64-bit literal.

> I too feel that storing the array's length glued to the array's data is not that good of an idea, it should be stored next to the pointer to the array aka in the array view.

That’s not cache-friendly, though. I think the short string optimization (keeping short strings alongside the string length, but allocating a separate buffer for longer strings. See https://devblogs.microsoft.com/oldnewthing/20240510-00/?p=10... for how various C++ compilers implement that) may be the best option.

> That’s not cache-friendly, though.

How so? The string implementations in that post are pretty much that:

    struct string
    {
        char* ptr;
        size_t size;
        union {
            size_t capacity;
            char buf[16];
        };

The pointer and the size are stored together, and they may optionally be located right next to the string's actual data, but only for very small, locally-allocated, short-lived strings; but in normal usage, that pointer points somewhere into the heap.

> they may optionally be located right next to the string's actual data, but only for very small, locally-allocated, short-lived strings

Only for small strings. Locally allocated and short-lived aren’t required for short string optimization to take an effect.

Also, I can’t find a good reference, but “only for small strings” in many programs means “for most strings”.

: Stupidly, yes, with carpet bombing. Practically, no, that would be horrible.

Could that work? It didn’t end well in Vietnam, which is about a fifth of the land area, and, in 1970, half the current population of Iran.

Also, they’ll pack a bigger punch, but I think the USA has way fewer bombers now.

> Could that work? It didn’t end well in Vietnam

We can't carpet bomb to regime change. But we can probably depopulate critical areas around the coasts while ships transit. It's stupidly expensive, both in materiel and collateral cost. But it's feasible. Whether we have the bomb-production is a separate question to which I don't have the answer.

> probably depopulate critical areas around the coasts while ships transit.

(looks at map) the city of Bandar Abbas, population ~500k? It's already being hit as it contains the Iranian Navy HQ, but actually depopulating it is a much bigger project.

Depopulation won't stop the IRGC from digging up a Shahed buried in the sand and launching it. The range is so great you would have to pacify the entire east of Iran, an absolutely impossible task.

> Depopulation won't stop the IRGC from digging up a Shahed buried in the sand

Carpet bombing. You don’t get to bury things in the sand, much less unbury them. It’s an old tactic—shaping movement with artillery—except done with remote pieces.

> range is so great you would have to pacify the entire east of Iran

West. Also, I don’t think so. Just critical zones. Worst case, only U.S. escorted and Iran toll-paying ships get through. (Worst case for the world. Not the belligerents. Which…that might be the solution.)

> Carpet bombing. You don’t get to bury things in the sand, much less unbury them.

https://en.wikipedia.org/wiki/Củ_Chi_tunnels#U.S._campaigns_...:

“Operation Crimp began on January 7, 1966, with B-52 bombers dropping 30-ton loads of high explosive onto the region of Củ Chi, effectively turning the once lush jungle into a pockmarked moonscape. Eight thousand troops from the U.S. 1st Infantry Division, 173rd Airborne Brigade Combat Team (including an artillery battery of the Royal Regiment of New Zealand Artillery), and the 1st Battalion, Royal Australian Regiment combed the region looking for any clues of PLAF activity.

The operation did not bring about the desired success. […]

By 1969, B-52s were freed from bombing North Vietnam and started "carpet bombing" Củ Chi and the rest of the Iron Triangle. Towards the end of the war, some of the tunnels were so heavily bombed that some portions actually caved in, and other sections were exposed. But the bombings were not able to destroy most parts of those tunnels.”

Carpet bombing doesn't cover a large area. Besides which there is nowhere to stage so an enormous campaign that isn't also in reach of one way drones.

The vast areas in the East are where you can strike shipping. You would only strike the West if your intention was to kill Iranians rather than end the war.

> I could argue that Apollo had a 1 in 20 chance of killing a crew.

NASA computed the chance of “landing a man on the Moon and returning him safely to Earth” as less than 1 in 20. I would think a lot more than 1 in 20 of those failures would result in killing crew members.

https://ntrs.nasa.gov/api/citations/20190002249/downloads/20...:

“Appreciating and deemphasizing risk in Apollo

Joseph Shea, the Apollo program manager, chaired the initial Apollo systems architecting team. The “calculation was made by its architecting team, assuming all elements from propulsion to rendezvous and life support were done as well or better than ever before, that 30 astronauts would be lost before 3 were returned safely to the Earth. Even to do that well, launch vehicle failure rates would have to be half those ever achieved and with untried propulsion systems.”

The high risk of the moon landing was understood by the astronauts. Apollo 11's Command Module pilot Mike Collins described it as a “fragile daisy chain of events.” Collins and Neil Armstrong, the first man to step on the moon, rated their chances of survival at 50-50.

The awareness of risk let to intense focus on reducing risk. “The only possible explanation for the astonishing success – no losses in space and on time – was that every participant at every level in every area far exceeded the norm of human capabilities.”

However, this appreciation of the risk was not considered appropriate for the public. During Apollo, NASA conducted a full Probabilistic Risk Assessment (PRA) to assess the likelihood of success in “landing a man on the Moon and returning him safely to Earth.” The PRA indicated the chance of success was “less than 5 percent.” The NASA Administrator felt that if the results were made public, “the numbers could do irreparable harm.” The PRA effort was cancelled and NASA stayed away from numerical risk assessment as a result.

> the concept of a "function" was undefined but generally understood to be something like what we'd call today an "expression" in a programming language. So, for example, "x^2 + 1" was widely agreed to be a function, but "if x < 0 then x else 0" was controversial

Good answer, but not the best example. In many programming languages, the latter is easily written as an expression:

   (x - abs(x)) / 2

It boils down to what you call an elementary function (https://en.wikipedia.org/wiki/Elementary_function).

Taking the absolute of a number generally is not assumed to be in that set, but there is no generally accepted strict definition.

A step ‘up’ from elementary functions are special functions (https://en.wikipedia.org/wiki/Special_functions). Likewise, that is loosely defined.

For example https://en.wikipedia.org/wiki/List_of_eponyms_of_special_fun... mentions lots of polynomials, one of them https://en.wikipedia.org/wiki/Cyclotomic_polynomial, which definitely are elementary according to https://en.wikipedia.org/wiki/Elementary_function.

Wikipedia also contradicts itself in https://en.wikipedia.org/wiki/Closed-form_expression, where it says

“a closed form expression or formula is one that is formed with constants, variables, and a set of functions considered as basic and connected by arithmetic operations (+, −, ×, /, and integer powers) and function composition. Commonly, the basic functions that are allowed in closed forms are nth root, exponential function, logarithm, and trigonometric functions”

and

“For example, if one adds polynomial roots to the basic functions, the functions that have a closed form are called elementary functions”

That would put the goniometric functions in the basic set allowed in elementary functions.