vasachi

You do know there are other EV manufacturers, right? Tesla can go bankrupt today, and supply will not be all that worse.

Say they introduce a bug, that will try to call that API even when there is no key.

Name one site, that works "not so great" with Firefox.

Am I the only one, who is frightened, that current stable version of React is almost two years old? Even if React#19 will be mostly backwards compatible (I hope), how many subtle differences will be introduced?

Yes it would work in any other industry. Users can overload a power grid. Users can overload a telephone network. Users can overload a grocery store. NO industry can deal with critical overload without problems.

OK, but how should an ISP distinguish a good HTTP/2 connection from a bad one (I'm talking about this particular attack)? As far as I can tell, the DoS starts after the connection from bot to server is established, at which point the connection is fully encrypted. Should all ISPs MITM their clients to ensure that all traffic is good and proper?

Nope, the bad guys don't care that much.

> This removes the last piece of information that can be used to block HTTPS traffic based on the site your visiting without being a party to the exchange.

And that will cause blocks by IP. It's not like authorities in those countries care that much if a user can't access a not-blocked site, as long as they can't access a blocked one.

"Public network" can mean many things, but in context of IP addresses it usually means a network, that uses a globally addressable IP range. Now, that doesn't mean that the network is globally accessible. It can be tightly firewalled.

What? Private networks are defined as networks, that use private address ranges[0]. They are most certainly not AWS "rhetoric".

And why are unique MAC addresses a problem?

[0] https://en.wikipedia.org/wiki/Private_network

Good luck administering IPv6 networks, they are so much easier to understand.

Are hundreds of publicly addressable services better?

Well, I wouldn't put _any_ service on a public network, unless it is explicitly required. Firewall is all well and good, but security in depth is even better.

Private networking is good. IPv6 doesn't help here at all.

IPv6 can help with a small scale attack, but not a large one. Your ISP can still be DDoSed, although it is a bit more difficult to do that.

Weeeeeeell, Googlebot can just lie about itself, no?

Actually an interesting point here. What will happen if USA sanctions your country? Can WEI stop working by remotely killing it?

Honestly, just use a real db in testing. Purity is all well and good, but not at the expense of more bugs caught.

Well, yeah. At least I can read the smart contract and audit transactions on the blockchain, if we are talking about decentralized exchanges. Google is faaaaaaaaaar less transparent. As in, not transparent at all.

Once on a conference one guy gave a talk about how he overrode python's module loading to load them from a mongodb instance. The reason was, if I remember correclty, because "it was easier for the juniors".

It made me veeeeeeeeery uncomfortable. Still a very good talk.

Well, that is your right as an owner of the packages. By the way, what are those packages?

They probably would, if it was legal.

Both tables have an ID primary key, one is also a FOREIGN KEY to the other.

What? Why whould the signaure be invalidated?

It still is easier to copy, when you own manufactiring process.

Kinda. The problem is your threat model, no? If you think of US law enforcement as adversary, using Amazon products is a very bad idea.

Do American companies manufacture anything in China? Yes. Do Chinese companies manufacture anything in USA? No.

So USA can only watch, while China can actually steal.

Don't they give camera feeds to law enforcement without warrant?

How would they detect if the car is sold?

Oh yeah, totally. But not always. I'm very glad that we now have an option to have both behaviours.

It is kinda weird, if you don't know how it works. For instance:

Say you have a unique constraint on two columns (column_a, column_b). column_a is not nullable, column_b IS nullable. Obviously these values are unique:

(1, 2) (1, 3) (2, 2)

But these values ARE ALSO UNIQUE:

(1, NULL) (1, NULL)

It is obvious in hindsight (NULL isn't equal to NULL), but can be quite a surprise.

...

Oh wait, postgres 15 deals with just this situation. Huh.