I stand by my comparison. If the tool I'm provided is an employer-provided workstation, I should get paid the moment I start using it. If the tool I'm provided is a citrix session across a secure connection, I should get paid the moment I connect to it from my home PC.

Don't like the commute analogy? I would suggest that analogies are never "perfect" or "exact" -- they basically highlight similar bits of two different things to HOPEFULLY illustrate some concept or idea. If you are expecting it to be a 100% match, I think you might be misunderstanding what an analogy is.

I think that might matter. Running software through something like a citrix session via a secure connection on their home PC might negate any "when did they actually start working" argument. Much like I don't start getting paid the moment I hop in my car to go to work.

Kind of like a "digital" comminute.

Well, he renamed it and made minor changes around the edges so he could claim that it was broken and he fixed it. And then, of course, proceeded to violate the agreement he signed.

Excellent post, just a couple of comments.

First, it's interesting that Nikkos said "a previous administration", without naming it. It was, of course, Trump 1.0.

Second, international treaties on refugees don't require a country to accept every refugee and there are multiple examples where nations have made agreements that modify which county must handle asylum claims. For example, the US-Canada Safe Third Country agreement specifies that asylum seekers must make their asylum claim in whichever country they arrive in first. If the US and Mexico had a similar agreement, then refugees could not enter from Mexico at all. Trump tried to get Mexico to sign a Safe Third Country agreement, but Mexico refused -- and it probably would have been invalid anyway, since Mexico might not satisfy the requirements of a "safe" country under the US law that authorizes the signing of Safe Third Country agreements.

Instead, Trump signed the "Migrant Protection Protocols" agreement with Mexico, which was the "remain in place" agreement. You said that no other country should be willing to put up with it, but Mexico did formally agree to it, though only to avoid tariffs. Of course, Mexico has declined to renew the protocols in Trump 2.0 (though Trump announced they had, which Mexican President Claudia Sheinbaum immediately denied -- Trump's habit of unilaterally announcing that an agreement has been reached obviously doesn't really work).

Anyway, there are lots of reasons why countries might agree to various limitations on asylum processes to manage refugee volumes, and these agreements are often perfectly valid under international and national law. Trump, of course, doesn't care about legality, or humanity, only what he can get away with.

China calling Elon. Come in, Elon! :)

bah.

Let me know when they start making *autographic* 120 film again. I have the camera, and am dying to shoot a roll!

The last rolls were apparently made in 1932. The cameras had a flap that could flip up and allow writing directly onto the film with a stylus. When you see handwriting on an old picture print, it was likely shot on autographic.

[and, yes, in fact my autographic camera *does* have bellows!]

That Electrolux isn't really an Electrolux.

a couple of decades ago, in one of those weird corporate maneuvers, it sold the name, and now sells its vacuums under another name, while the buyer sells non-electrolux as Electrolux.

So what she knows of Electrolux from the late 20th and early 21st centuries no longer applies.

But, yes, they were very good and lasted forever. Also extremely pricey.

I once had an interesting conversation with an Android OEM. I sat down with them to discuss what security issues they'd like to see the Android security team work on. They asked me "When are you going to fix the USB hole?". I didn't know what they meant and asked for clarification. They explained that in some parts of the world, notably India and China, there were "free" charging stations set up in bus stops, train stations and other public areas. These charging stations allow the public to charge their phones, for free! There's just one catch. On a sign above the charging station there's a set of instructions that tells users how to go about activating the charging. The sign tells them to go into the Settings app, then "About Phone", then scroll down to the build number, tap it seven times, then... it walks them through enabling ADB and accepting the key of the "charging station" computer, which would then proceed to install malware -- and to start charging.

Huge numbers of people used these charging stations every day, to the point that the biggest problem users had (besides the malware) was that they were always occupied. No one had a problem with "activating" charging for their device.

90% of people are capable of following a list of instructions. 100% of people are capable of either following a list of instructions or getting someone nearby to do it for them.

Anyway, this OEM wanted us to disable ADB entirely, or allow them to, because their users were doing it, getting loaded up with malware, and then blaming the OEM for making a crappy phone. I, of course, told them that we were not going to disable ADB and we were not going to remove the compliance requirement that forces them to support ADB.

Unfortunately, the current change still doesn't fix the "USB hole", but it does offer a way to rate-limit malware installation via downloadables.

Anyway, if you really think your users can't follow instructions, or can't get someone else to do it for them, you can always just register for a developer account. As long as you don't distribute malware, people will be able to sideload your APKs without using ADB. If the $25 is too much for you, maybe share the cost with some buddies, or get one of the limited accounts, though your APKs will only be installable on a small number of devices. Except, of course, by people who can follow instructions, or get someone else to.

Yep. It allows them to stop malware. How terrible!

How did you learn this?

I suspect you actually do derive a lot of utility from AWS and Azure, you just don't realize how many of the services you use every day are running on them.

try using mirrors. What could go wrong? :)

We had to have our entire roof reshingled after a particularly bad storm.

It turns out that of the various colors, the lightest (or 2?) was actually energy star rated. So we took it.

It turned out to be worth about 2F inside as compared to the prior black shingles.

We got another 2F when we replaced the swamp cooler--the newer model had an 18" pad instead of 12".

Between the roof and the bigger pads, we only had a single non-monsoon season day where we had to switch over to AC this summer--in Las Vegas!

(I'm going to miss the swamp cooler when we move, but they're apparently not allowed in new construction. I have no idea when the cutoff was)

Oh, actually, I missed the most obvious flaw in this argument: The verification doesn't give Google any significant control! It does give them the real-world identities of registered developers, yes, but then what? It doesn't do anything to require registered developer to use the Play store or comply with any Play policies other than one: Don't distribute malware.

The real purpose here is malware rate-limiting. Right now, malware authors can pump out huge numbers of apps with small variations to defeat identification. Google may identify one malicious app and warn all of the user that have it installed, but the malware author has thrown out a hundred variations of that app and Google only twigged to one. What ID verification does is require the developer to tie each app to a unique government-issued ID. In countries where you can't just go get a hundred government IDs, this means teams of malware authors can make approximately one malicious APK per team member. In countries where they can go get a hundred unique government IDs per person (because the government is actively cooperating or because they have a cousin in the ID office) it doesn't help so much, but Google can then start working with the governments to crack down.

I don't know if you noticed in the announcement, but this program is starting in a small number of countries, with the cooperation of and at the request of the governments who are trying to defend their populace against waves of malware. This isn't an accident.

Actually, though, your comment and my off-the-cuff response both miss the real difference which is why malware authors would choose to use F-Droid to distribute their apps. They'd have to publish source, which would be a disadvantage in the competitive world of malware authoring, and publishing source code would also make it easy for their malicious code to be identified. It makes a lot more sense for them to publish via downloadable sideloads or -- even better, if they can manage it -- in the Play store.

From a security perspective, it makes sense to treat F-Droid differently from random downloadable sideloads... but how is the Android OS supposed to tell the difference? The Android mechanism for establishing APK trust is signatures. So... F-Droid could arrange with Google to get the platform to trust APKs signed by F-Droid, which would make F-Droid work fine. And, actually, there's no need for Google to go through any complicated process to set that up: F-Droid can simply register as a developer and sign the APKs it distributes. Done. Of course, if F-Droid ever screws up and does distribute malware, it could result in all of their apps being evicted from Android device, but since F-Droid is a zero-malware platform, that's not a problem, right?