Er, I meant legislative branch. Wow. I can't believe I typed executive there. Embrace the autocracy?

Bwahahaha!! Wow, what a mistake. Yeah, absolutely legislative. I wonder what I was thinking.

Imagine what it would be like to have an efficient and hard-working executive branch, so that rather than making judges scratch their heads to figure out how to fit an old square peg into a new round hole, we could pass a new law that fits the modern context.

You need to read my previous post, and understand it.

The reason MITM isn't a problem for online banking (and TLS in general) is certificate authorities. As I said, it's an authentication problem. For web servers (and other TLS uses) what you need to verify (authenticate!) is that the public key the server handed you belongs to the site your browser thinks it's talking to. To make that work, the public key comes in a certificate that (a) contains the domain name of the server and (b) is signed by a trusted certificate authority. Your browser comes with a pre-installed list of trusted CA public keys, which it can use to verify those signatures.

So, as long as CAs only sign certs when they've verified that the private key is owned by the same entity that controls the server, it's secure. And with a few significant exceptions, they have been quite good about that, at least to the extent of it not being possible for entities other than nation-state intelligence agencies to subvert the CAs. I don't know that nation-state intelligence agencies do this, but I'm pretty sure they could. But they have no interest in your bank account, at least not enough interest to be willing to divulge the fact that they can MITM TLS connections. There are also some other mitigations in use that make this harder and riskier for them (notably, Certificate Transparency; Google it if you're interested).

At the risk of appearing to argue from authority, I've been a professional cryptographic security engineer for over 30 years, the last 15 of which were as a crypto security engineer at Google, designing and building a lot of the stuff that makes the net work, including widely-used international standards that have stood up to academic cryptanalysis. I'm always happy to answer questions and explain things, but your starting assumption should be that I know what I'm talking about. I certainly make mistakes, but this stuff is super basic.

Three reasons:

1. It doesn't work. A thief can drop your phone in a Faraday bag faster than turning on airplane mode. And, yes, phone thieves carry Faraday bags just for this reason.
2. Pixel has "Offline Device Lock". You have to enable it (Settings -> Security & privacy -> Device unlock -> Theft protection), but if your device goes offline for any reason -- airplane mode, Faraday bag, whatever, your device will lock after a couple of minutes. It's a little annoying to have to unlock your phone after you get on the plane, but with biometrics that's pretty trivial.
3. Pixel has "Theft Detection Lock". Again, you have to enable it, but it uses the accelerometer and on-device AI to notice when someone snatches your unlocked phone out of your hand. If this happens it engages the screen lock instantly. The snatch detection is surprisingly accurate; few false positives and basically zero false negatives.

While I'm at it, I should also mention that Pixel has a Remote Lock feature (also has to be enabled). This only works if the phone is still online (obviously), but if you can get to a browser somewhere you can go to https://android.com/lock and type in your phone number to lock your phone remotely. This feature generated a lot of discussion in Google because of the obvious risk that someone who knows your number can annoy you by repeatedly locking your phone, but the team found a good solution. If someone does that to you your phone notifies you that it was locked remotely and offers you the opportunity to set an unlock secret which has to be typed in addition to the phone number to remote lock.

You could already remotely lock your phone with Find My Device (https://android.com/find) but that requires that you're able to log into your Google account. Lots of Android users don't even know they have a Google account because someone at the Verizon store (or whatever) created it for them without telling them, and those who heavily use their Google account may have MFA set up, so it might not be easy to log in without their phone, or might take longer.

I certainly did. Pinky's Brain made an excellent point about how Meta can trivially MITM end to end encryption unless there's a way to authenticate the other person's public key. He was entirely correct, and you were incorrect to dismiss his comment, which was the point of my reply -- to educate you (and anyone else interested) on why he was right.

TBH, the TRS-80 was my friend's computer. My first computer was a Timex Sinclair 1000, with 1 KB of RAM. Though I did eventually get a 64 KB RAM upgrade attachment. So much RAM! But unfortunately it didn't attach very securely so sometimes after waiting for 10 minutes to load a game from the cassette drive you'd bump the thing and it would momentarily disconnect the RAM and crash the system.

I learned my powers of two by emulating Ender Wiggins and doing "doublings" in my head... no computer required.

Only if they kept the copy around. Ephemeral copies are allowed for lots of purposes.

After I posted my comment it occurred to me that there might be a benefit in destroying the paper original. That way they can argue it's just format shifting, for which there is a lot of legal precedent.

Cite? My understanding is that multiple Supreme Court rulings have found that the Free Speech Clause prohibits compelled speech. The government can order you to be silent, but not order you to say things you don't want to say.

That's a really, really strong claim. Do you have correspondingly-strong evidence?

AFAIK, warrant canaries are still a thing. Some prominent organizations who had them have stopped publishing them, or have modified them to reduce their scope, but the cause of this appears to be that those organizations can no longer claim not to have been served by warrants. They can't be compelled to keep them up, so they have taken them down. The real problem with warrant canaries is that a global canary is only useful until the first warrant is served.

Encryption isn't the problem, it's authentication.

Say Bob wants to talk to Alice through WhatsApp. They've never corresponded before. To encrypt a message to Alice, Bob needs Alice's public key. How does he get it? There are two options. Either he looks up Alice's public key on WhatsApp's server, or he sends a request to Alice through WhatsApp's server for her public key. In either case, he gets Alice's public key from WhatsApp.

Or, rather, he gets a key that WhatsApp tells him is Alice's public key. How does he know? That is, how does he authenticate the key? Alice has the same problem. She needs Bob's public key. However she gets it, how does she know it's Bob's?

WhatsApp can send its own public key to both Bob and Alice, then when Bob sends a message to Alice, encrypted with WhatsApp's public key (which Bob thinks is Alice's), WhatsApp can decrypt the message and re-encrypt it with Alice's public key, and forward the result on.

In practice, though, none of that matters because WhatsApp also writes the app. So they can just act as an honest broker of public keys and then have the app forward copies of everything to WhatsApp. I don't know if they're actually doing that, but it seems like that's what's being alleged.

BTW, my description above is for "public key encryption", but that's not what anyone actually does any more. What we use instead (and what Signal, and therefore WhatsApp, use) is "hybrid encryption". Specifically, ephemeral-key hybrid encryption. With that, Alice and Bob don't use public keys for encryption at all, and the public keys they advertise to the world are only used for creating digital signatures. Call these "identity keys", because they identify the user. When Bob wants to send Alice a message he generates an ephemeral key pair, signs the ephemeral public key with his identity key and sends it to Alice. Alice verifies the signature so she knows it came from Bob (because she got Bob's identity key from WhatsApp, so she's still fundamentally trusting WhatsApp). Then she generates her own ephemeral key pair, signs the public key, and uses her ephemeral private key with Bob's ephemeral public key to "encapsulate" one or more symmetric keys. Then she sends the signed public key and the encapsulated symmetric key(s) to Bob, who verifies the public key signature and uses Alice's ephemeral public key with his ephemeral private key to de-encapsulate the symmetric key(s). Then, Bob encrypts messages to Alice using a symmetric key and she does the same back. Public/private keys aren't used after the symmetric keys are set up. Oh, and both Alice and Bob discard their ephemeral key pairs and, per the Signal protocol, every time they use a symmetric key they derive a new one from it and discard the old one. All of this discarding of keys provides "forward secrecy", which means that if at any point in time Alice's phone is compromised and all of the keys extracted, the attacker can't decrypt any of the past messages.

Very nice security... unless WhatsApp is just caching a copy of all the message plaintext on their servers.

This is true, but DrYak's point is that doesn't matter if the two ends are just uploading all of the data back to Meta after the safely-encrypted copy is received. They don't need to MITM the connection. If WhatsApp allows out-of-band fingerprint verification, MITM wouldn't even work.

Child.

Let me tell you about my first computer, a TRS-80 in 1978 with a whopping 4 KB of RAM, so 1 GB would have just confused me, and the only games available were ones I got from computer magazines and had to type in by hand. :-D

Cue someone to tell us about "their" first computer, an IBM mainframe in the 1960s or something...

What about a human with an eidetic memory who can retain vast amounts of what they read verbatim? What about a human who invests a few months or years in memorizing a whole book (or book series)? Does that constitute copyright infringement? If not, why not, and why is it different if the entity is a machine that can do the same thing faster? Copyright defines a copy as "fixed in a tangible medium". Aren't neurons a tangible medium, just as much as bits on an SSD?

The only logically-consistent answer I can see is that learning (whether human or machine) does not constitute making a copy... but that copying the resulting trained LLM probably does. Of course, this isn't so much an answer as moving the question to one of how you define "learning", and I don't have a good answer for that.

That's irrelevant.

If training the AI on the book is making a copy of the book, then it doesn't matter if they kept the source copy or destroyed it, they created an infringing copy.

If training the AI on the book is not making a copy of the book, then it doesn't matter if they kept the source copy or destroyed it, they did not create an infringing copy.

This question really boils down to "Is a stored copy of an AI's weights a copy of the source material fixed in a tangible medium"? When a human reads a book, we say "No, the neuronal connections that result from reading are not, legally, a copy fixed in a tangible medium", even if the reader memorizes the book. Is machine learning different from human learning? If so, what makes it different?

These are not easy questions, and the courts haven't settled on legal answers -- which may or may not bear any relationship to the correct answers, assuming there even are correct answers. But I strongly, strongly doubt that whether or not the owner of the AI kept a copy of the book will matter. There's just no basis for that mattering, in law or in common sense.

Maybe. 75 kWh/day is a pretty big solar system. Not huge, but significant. I just installed a 19 kW system (in late November), and so far I never get much above 75 kWh. Of course, the days are still short and as they get longer it will go up. Still, 19 kW is a good-sized system, and not cheap.

However, if your remote cabin really rarely needed the motor/generator, maybe you could get by with a 5 kW system that generates, say, 10 kWh per day. 10 kWh per day would mean you'd create about 50 gallons per year -- reduced by whatever amount of electricity you used directly. A small cabin should easily get by on ~250 W of power (average) even when inhabited, which is 6 kWh per day. So... put in a 10 kWh battery and while you're using the cabin you'd normally never need the generator, but be producing a gallon every three weeks. And when you're not using the cabin and the whole solar production goes to make gas, you'd be generating about a gallon a week. As long as you don't need the generator very often (e.g. multiple stormy days in a row, so the battery is depleted and you need a little bit of generator power to supplement -- note that solar production doesn't go to zero on such days, but you'd probably only get 2-3 kWh), the numbers would work.

This all assumes the gasoline generator is reasonably inexpensive and doesn't require a lot of maintenance or babysitting, of course. I'm sure none of those things are true now, but that's not to say they couldn't become true.