IBM's instructions? Of course they said the licensed compiler is required :-)

Those are all part of gcc.

I mostly do heavy multi-disciplinary engineering problems (these I also use for checking an AI, as they're typically not good at these sorts of problems), complex coding, OS analysis, stuff like that. However, sometimes I do throw the occasional odd-ball - I've used ChatGPT to propose a workable quantum mechanics that will cope with Doctor Who canon, for example, and to produce an outline for a story in which symphonic metal appears in 1964 that is compliant with current sociological and psychological models of behaviour.

Claude Opus 4.6 was coping surprisingly well with just about everything I threw at it (but ran out of credits fast), but Opus 5 is churning out incoherent babblings to the point I'm worried I may have accidentally summoned Cthulhu.

But Gemini, Grok, and DeepSeek got hopelessly confused on just about everything past a very low level of complexity. They can handle large problems, yes - Gemini has a huge context window - but complex interactions baffle them.

ChatGPT is able to identify issues correctly, but can only outline solutions, it's just not good at depth. 5.6 is a lot better, but still not good at deep answers. ChatGPT is also prone to agreeing for the sake of it, which makes me nervous about trustworthiness.

My guess is he read the first half of the first sentence of my response and concluded that I was just repeating what Google says about the issue, that I mindlessly believed the company line.

Never mind that I personally designed and implemented the feature, so if there's any official Google PR on the issue, it's based on what I told "them", not what "they" told me.

Thanks. There were good reasons to move on from Android, but it was pretty cool being able to work to improve the world's most-used operating system. Relatively small impacts get multiplied by a big number.

Also 100 miles from any international airport. This covers huge swathes of the country.

Atlanta, GA isn't US soil?

But even if this were one of the overseas CBP checkpoints (the ones that do pre-clearance, so you don't have to go through CBP after landing), I think those are considered US soil as well, under an agreement with the host nation.

That is fair enough. I've been trying out Kimi on the free model, and have subscriptions to Claude and ChatGPT. If Kimi is actually as good or better than ChatGPT, at the pro level, then it might be worth my while moving over as ChatGPT has become very disk-hungry of late and I'm pushing right to the very limits on what it can reliably process.

Maybe. There are multiple SCOTUS rulings that basically declare border checkpoints to be a 4th amendment-free zone. If that means that the agents are "authorized to make such search or seizure", then 18USC2232(a) looks like a problem for him to me.

I was the TL for hardware-backed cryptography and associated bits. No, I didn't always follow every detail of what others on the large (hundreds of engineers by the time I left, though I was #13 on the team when I joined in 2014) team was doing. However, I do quite fully understand the context in which they were doing it. If you'd actually like to understand more about the thinking that likely underlay whatever you're talking about, please elaborate.

I do know about the planned requirement to require all app developers to identify themselves and pay a $25 fee if they want their apps to be installable via any route (sideload, third-party app store), indeed I even explained in my prior post why that benefits anti-malware efforts. I'm not aware of any 24-hour delay associated with it. If you weren't being such a pissy asshole about it, I might go google it, but you've burned pretty much all of my goodwill, so unless you care to actually explain what your problem is, I'm done here.

I think the most plausibly-deniable strategy is to put the phone into a state where it shows the OS setup wizard when powered on, making it look like you wiped it and powered it down just before going through the border checkpoint. Then to reactivate it you have to go through the "setup" process and when you get to the password configuration if you enter the correct password it unlocks and returns to normal. If not, it boots to an apparently freshly-setup state. I think this would be much easier to correctly simulate than an apparently in-use device.

Of course, the safest strategy is to actually wipe it and power it down before going through the border checkpoint, then restore from cloud backup after clearing the checkpoint.

Although the Chinese models are all considerably smaller, it's not obvious to me that they're as good or better. They could be, but I'm not convinced the benchmarks that currently exist are stressing the models enough to establish where models actually are any good.

You use the can of grue repellant in the lake to get past those.

Could you elaborate? What 24 hour delay?

What have "they" convinced me of?

Actually I mostly fixed it in Android 14. The solution architecture was the same as described above, except that TZ's role was played by a low-level userspace daemon instead. This means that "I'm stolen" mode on Android 14 doesn't disable KeyMint, and it opens up more userspace/kernel attack vectors. The reason for doing this is because leaving it in userspace for a year gave me a chance to flush out any corner cases I had missed. Privileged low-level flashing tools could bypass it -- which is not true of the TZ implementation. Given the potential for bricking devices, I thought it wise to leave it outside of TZ for a release.

Still, even without TZ, it's fairly challenging to defeat (barring access to privileged flashing tools -- which actually means access to special signing keys to sign device-unique firmware images).

To defeat it, you need to wipe the secret stored in the persistent data partition, then do the untrusted reset. This persistent data partition is accessible from userspace, but it's highly locked down, same as the copy of the secret in /data. You basically need a kernel compromise. Well, either that or remote code execution in the persistent data block daemon, but that has very little attack surface and is written in Java, making it hard to exploit. The kernel attack surface is bigger and more porous; it's the better target. After you wipe the secret you'd also need to recalculate the persistent data partition hash and write the new value, but that's just a SHA-256 (IIRC) calculation, so no problem.

If anyone wonders whether I shouldn't be sharing this publicly; it's all open source. Anyone can go read the code to see how it works. It's even clean and well-documented code.