Great points! I use high-entropy random secrets as passwords in the Basic Authorization header, with their hashes stored in a database. I also use cookies to make the browser experience pleasant and secure. The cookies are based on a HMAC hash that uses a single server-side secret, a string representing the principal, and a timestamp. So the cookies work without needing server sessions.

HTTPS is mandatory of course, and caching successful authorizations help performance.

All of this seems inferior to just using a 128 bit random token drawn from /dev/urandom and stored in a database. If you see "HMAC" in an API authentication design, something weird and probably bad is happening.

I would say, store the hash of the token in the database, but that's my personal preference to add a bit of defense against timing attacks, insider stealing the token, or token database breach.

I don't think this buys you anything. Keep things simple.

I feel like picking a fight. What's the downside? It's super simple to hash them, and it prevents a read-only exploit from turning into a major catastrophe.

Example from something I built. If our db was used by an attacker, with all client API keys, they could go liquidate those accounts (place phone calls). Huge loss, and not far-fetched (this kind of attack happens daily and is profitable). With hashed API keys, nothing is possible. We don't even need to tell people to rotate keys. With plain keys, we'd need to freeze usage for people without e.g. IP address restrictions in place.

Read-only leaks happen all the time. Why not make sure they don't impact your clients API usage?

I'm not just trying to fight. It's a handful of trivially-validated lines of code that significantly mitigate the impact of a data leak. Seems like a super easy tradeoff.

Click the link in his comment.

I don't think unshielded nukes in orbit are easy to detect. Back on Earth you need to get up close (within a few meters) in order to distinguish the radiation signature from the background radiation, and in space the background level is much higher. Source: https://fas.org/sgp/crs/nuke/R40154.pdf (see page 78 and onwards for a discussion about detecting nukes at a distance)

Those nukes on Earth are heavily shielded, especially the physics package.

Historical anecdote: Algol-68 disassociated variable assignment from mutability already 50 years ago. Whenever mutability was desired, a reference to a mutable value holder was used.

Example of immutable assignment: int n = 2

Example of reference to mutable value: ref int n = (heap int := 2)

However, in order to make Algol-68 code look more similar to Algol-60, they introduced backwards-compatible shorthands, so for example the declaration int n; was actually a shorthand for ref int n = (loc int);

This shorthand magic probably contributed to why Algol-68 syntax was perceived to be difficult.

Footnote: loc and heap were the two memory allocation operators available in Algol-68.

Rust takes a similar approach with let some_var and let mut some_var, respectively.

Since Facebook users are the company's products rather than their customers, I wonder what Zuckerberg means when he uses the term "our community"?

i don't think that "product" and "customer" are exclusive notions, nor that "community" would only apply to just one of those notions.

What exactly counts as "starting a war"? The Korean war is mentioned here as an example, but that war was started by the Korean communists when they invaded South Korea on June 25, 1950. The United States UN-sanctioned involvement was a reaction to that. Does that really count as "starting a war"?

The article talks about fusion chain reactions in hydrogen bombs, but the fusion in hydrogen bombs isn't an exponential sequence of chain reactions, it's due to very high temperatures caused by fission chain reactions in the primary. Hence the term "thermonuclear".

Why is the AC necessary for this recursive tree traversal?

The AC is necessary[1] because at each of the infinitely many steps, you have to choose which of possibly several candidates to use.

[1] As mrmyers points out, you actually only need a weaker version of AC, called Countable Choice.

I don't find the AC intuitive at all. It assumes that a choice function exists for any set of non-empty sets, including infinite ones. How can anyone have an intuition for such things? Except of course when the intuition is built upon taking finite cases to some limit. But in those cases the AC is reduced to a theorem, making it completely unnecessary.

I once had a homework assignment to attempt to construct the choice function for the set made up of all non-empty subsets of the reals. A lot of intuitive ideas come to mind and it's a good exercise to show why they don't work. You should feel weird about the axiom of choice after working through a few.

AC is equivalent to the statement: The Cartesian product of any family of nonempty sets is nonempty.

This is very intuitive.

It's only intuitive if you take cartesian products infinite families for granted. I think it's only considered intuitive because when people think "cartesian product" their model is finite families.

So how does anyone form an intuition for even defining the Cartesian product of infinite sets in general, without assuming the AC in the first place?

Consider something like the Cartesian product of countably infinitely many copies of the naturals: this is nothing more than the set of all countably-infinitary tuples (n1,n2,...). It's obviously nonempty, e.g. because it contains (0,0,...). It seems intuitively obvious that similar reasoning should make any arbitrary Cartesian product of nonempty sets be empty.

That reasoning applies only to products of an arbitrary family of the same set, provided you know an element of that set. That is an exceptionally simple special case, don't you think?

Yes, that particular example is intuitive. But I don't see how a similar reasoning should apply to arbitrary infinite sets however. That's a huge intuitive leap in my opinion, and it's one that I can't follow.

Ok, you're presenting to an audience consisting of lots of tables, each with at least one person at it. You say: "Will every table please have a representative stand up."

To question the AC is to suggest that for some configuration of (sufficiently many) tables, it's impossible for the audience to fulfill your request, on account of there not existing a function f(table)=representative. This sounds absurd, because obviously each table can independently choose a representative, and it isn't like they need to coordinate with the other tables in order to fulfill your request.

Do you have an example of a union without a known choice function?

Lacking an exact measure that we can all agree on, "influential" is kind of subjective. So I'll contribute with my subjective opinion: Paul Graham's essays are (collectively) among the highest quality content that I have found on the Internet. They are the opposite of click-bait and attention-spam. I don't agree with everything Paul writes, but so far I have never regretted spending the time to read one of his essays. This is rare in today's Internet environment. I can only think of Scott Aaronson and a few others who are comparable. But to repeat myself, this is my subjective opinion.

I totally agree with your view!

I used Hylang to program an Arduino Yún a few years ago, via cross-compilation. This was a very nice experience, since it allowed me to use the great Python ecosystem without having to be limited by Python the language.