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.
Could you elaborate? What 24 hour delay?
Could you elaborate on exactly what you did at Google since you apparently have no idea what they are doing Re: sideloading and the security you claim they need to protect users from what google doesn't want them to do?
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.
There should be an option for a password which unlocks the phone in a separate sandbox which is benign.
Of course, if the government has a warrant, even this will get you into trouble.
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.
If you have a strategy that would work better
Not shitting on users would work better for making them not pissed off at your bullshit. Specifically, giving users a way around the 24 hour delay not-your-phone-google's-phone fuckery.
Could you elaborate? What 24 hour delay?
Copilot: "A million AI tokens costs between half a cent and eight cents in electricity in the U.S., depending on the efficiency of the hardware and the electricity contract."
Can they pay for Operations & Maintenance out of stock sales?
Yo are apparently easy to convince as long as the ones manipulating you use big words.
What have "they" convinced me of?
The anti-reset feature (called "Factory Reset Protection") dates back to 2014, but it had some holes, which I fixed in Android 15.
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
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.
I asked Claude about your AIX scenario and it was able to fill in the gaps.
The Python `cryptography` library has some Rust dependencies since version 3.4 (because Rust is an exceptionally good choice for writing crypto libs -- which is also what I'm doing), and in the absence of a pre-built copy for AIX, that would have to be built from source, which requires a Rust toolchain. Claude corrected me about the C compiler requirement. The Rust `cargo` build system does use `cc`, not to compile anything, but as an interface to the linker. My own setup uses the Bazel build system (because my employer uses Bazel for everything) and that uses a normal linker, not `cc`, so I didn't realize `cargo` does by default. You can actually change that; you can adjust the `cargo` configuration to use a different linker driver, but out-of-the-box it's going to be looking for `cc`. And if you didn't license IBM's OpenXL compiler for AIX, and didn't install gcc or clang (either of which is free and would provide the necessary executable), then the build would fail.
For phone use, it is probably a lot easier to get into the phone some other way. Especially if you just want to reset a stolen phone to sell it in some country where the government does not care and hence the Telcos will accept devices on the list of stolen ones.
No, if you don't have the LSKF (Lockscreen Knowledge Factor, i.e. PIN/PatternPasscode) for a Pixel, you can't reset a stolen device, not since Android 15. The anti-reset feature (called "Factory Reset Protection") dates back to 2014, but it had some holes, which I fixed in Android 15.
The way it works is that there's a "boot secret" stored in TrustZone (TZ) and in a directory in
During normal boot, the system reads the secret from file system, passes it to TZ, TZ flips off the "I'm stolen" bit, and everything works normally. But if you do an untrusted factory reset (trusted resets require entering the LSKF) the copy in the
To recover from this state, the setup wizard offers you an opportunity to enter the LSKF. If you do, it's passed to TZ, TZ flips off the "I'm stolen" bit and allows a new secret to be stored in both TZ and in the data partition, and we'e back to the normal operational flow. In case you have forgotten your LSKF, the setup wizard also allows you to connect to Wifi and log into some Google account that was on the phone just before the reset. If you can, then the Google server will send down an encrypted copy of the boot secret that was encrypted on-device and uploaded and stored associated with the account. It's encrypted so Google can't decrypt it, but the device can. So the device decrypts the secret, sends it to TZ, and if it's correct, TZ flips off the "I'm stolen" bit and allows a new secret to be stored in TZ and the data partition, and uploaded (encrypted) to Google (I omitted that third copy previously just to keep the explanation simple; the secret is only set when network is available and the upload is successful).
How can this be defeated? Nothing is perfect so there are a few ways, but they're not so easy:
1. If you can compromise TZ you can undermine the whole scheme.
2. If you can bypass kernel restrictions on access to the file where the secret is stored (both filesystem permissions and SELinux controls), you can grab a copy before the reset, and if you can then do the same thing after reboot to write the file to the right place, then reboot, you're golden. Note that the secret changes frequently, though, so be sure you grab the right one. It changes at least on every boot (assuming network is available) and sometimes during operation (but only when network is available; gotta be able to upload the encrypted secret).
3. If you can replace the system image with one that just ignores the TZ FRP stuff entirely, you can avoid the worst of the restrictions, though KeyMint and attestation won't work so the phone will be hobbled. But doing that requires compromising secure boot which is definitely not easy. A remote code execution vuln in one of the early bootloader stages would be suffiicent, but that is carefully-validated, small code and hard to exploit because the phone is not talking to the world, there's just very little attack surface. It's probably more practical to find a persistent kernel compromise that you can use after boot, then modify the relevant system pieces to always report "Ok". But KeyMint still won't work.
4. If you can compromise the system while the user is still holding it so you can steal their LSKF when they enter it, you're golden. Alternatively, if you can get their LSKF by shoulder surfing, rubber-hose cryptanalysis, etc., that works, too. Similarly if you can steal their Google account credentials (or make them provide an interactive video selfie!). Stealing the phone while it's unlocked is not sufficient because the trusted reset flow requires an additional LSKF presentation.
5. If you can brute force the user's LSKF, that works. Then you can do the trusted reset and avoid the whole thing. LSKF authentication is done by the Titan security chip, though, and it imposes exponentially-increasing rate limits on guesses. That was also my doing, but the UI team forced me to water it down and make the schedule far more generous than I think it should have been. That was in the process of being improved last year, though, so I think it's been fixed, and even with the generous schedule you were still looking at months or years of trial and error unless you got pretty lucky or the user chose a bad LSKF (sadly, many do).
Note that the FRP infrastructure I'm describing is part of the base Android system, but it does require some OEM work to enable it. There was a plan to mandate that OEMs do that work. I've left Google so I don't know what the state of that is. But the context here is Pixel, and I know the work was done for Pixel because I did it. Note also that the FRP scheme depends on a few things:
1. The user has to set an LSKF. That is, if they have an open, unlocked-all-the-time device, you can factory reset it.
2. The user has to have a Google account on the device. This is needed to use the Play store and other stuff, so nearly all devices have it. The common exceptions are users who have unlocked their bootloaders and flashed a non-GMS Android (e.g. Graphene, Lineage, Caliyx, etc.). You'll have to ask those OS authors how they deal with FRP. I briefed them on how the system works, but don't know what they did with it. The reason for making this a pre-requisite for FP is because of concern that some users might not know their LSKF; maybe the phone sat in a drawer for a long time.
3. (Implied by the previous) The user has to be running an official image with Play Services.
4. The phone must not be enrolled in an enterprise device management service that has disabled FRP. Of course, generally that's only done on devices that are enrolled in zero-touch configuration, which means that on every reboot they require authentication from an authorized enterprise account. This is also very hard to bypass.
TL;DR: No, you can't just factory reset a stolen Pixel device.
The biggest problem I have with rust is that it doesn't work if you aren't on a platform with a C compiler.
There's a platform without a C compiler? What?
Even in Python I can't use some modules on AIX (like cryptography) because that depends on rust which you cannot compile unless you have a commercial C compiler.
Rust does not depend on a commercial C compiler, and couldn't use one for anything even if it was persent. The only rust toolchain uses LLVM, the open source toolchain for Clang. There is no Rust-to-C compiler; the only Rust compiler is native, and works on any platform that LLVM works on (which is all of them).
(The fact that only one Rust compiler exists is a common criticism of the language, though I've yet to understand why it's a bad thing. The compiler is open source, uses the LLVM backend which makes it possible to easily target any ISA / environment, and is very high quality. The error messages are incredibly good, I've never seen anything like it. There is an effort under way to make a GCC front end for Rust, so eventually we'll have two.)
Even that had a bunch of comments from people that were trying to compile it and couldn't
Can you tell me what exactly you're talking about? You mentioned AIX... IBM has a fully-supported Rust toolchain (which is just the open source toolchain, packaged and distributed by IBM), available free of charge (I only know that because I googled it; I haven't touched AIX since I left IBM in 2011). Well, they only provide support if you pay.
It would be interesting to see if I could even port my application to rust. I bet it would be riddled with unsafe blocks anyway.
Why, are you doing lots of hardware interaction, writing to device registers and whatnot, or calling C APIs, or exposing C APIs to callers? Outside of those cases, I think I've only needed unsafe once or twice in the ~100 kloc I've written in Rust.
Google doesn't have a problem with non-Play and sideloaded apps being installed in general. They do have a problem with malicious apps, regardless of source.
And yet, their method for addressing that issue 1) doesn't prevent the installation of malicious apps, it only delays it, and 2) gets in the way of the user installing non-malicious apps from sources other than Google. Therefore Google is broadly incompetent and/or malicious since this thing they've done only harms the user.
If you have a strategy that would work better, by all means go talk to the Android security team about it. They'd be happy to pay you a lot of money, if your ideas are good, and feasible. Honestly, that's very unlikely; a large number of very smart people have been thinking hard about this since about 2013, but maybe you can see something no one else has.
The strategy has a few parts:
1. Scan the the Play store apps for malicious code using both static and dynamic analysis. This will never catch everything; it's a continual arms race and the malware authors have insuperable advantages, but what the scanning can do is make the malware authors have to work hard, raise their development costs.
2. Require app authors to identify themselves and pay a small fee. This is another "cost-increasing" strategy, one that is obviously imperfect, but surprisingly effective anyway, which is why they want to apply it to all apps, not just Play store apps.
3. Put some friction in place to make it somewhat difficult for clueless users to be tricked into installing software from outside the Play store. It would be far, far easier to simply block sideloading or third-party app stores, but Google is committed, philosophically, to keeping those options open (which is also why Pixel phones have unlocked bootloaders, Chromebooks have "dev move", etc.). This is a balancing act; it needs to be hard enough to prevent casual installation, but still accessible.
4. Google Play Protect scans all apps (regardless of installation source) on all GMS devices (devices with Google Play), with user permission. If known malware is identified, GPP can either warn the user or simply remove the app. AFAIK, the "remove the app" option has never been used, but the last time I asked about it was several years ago, so I could be wrong.
5. Safe by default APIs. APIs are designed to limit potential abuse. This can't always work, in some cases because necessary APIs are abusable and in some cases because APIs were deployed that no one realized could be abused, and taking APIs away is hard (breaks apps).
6. Tight app sandboxing and tight mandatory access control (SELinux). This is largely successful, most malware works by abusing legitimate APIs, not by breaking out of the app restrictions, but there are always exceptions.
Again, if you have better ideas, by all means share!
That humans have sufficiently directional hearing is perhaps the most impressive part. Once you have that, then the rest really just follows,
However, this continues the unexpected senses in humans, one of the first discovered was that humans have a weak magnetic sense.
The potential, both in fact (if you can "see" walls and gaps by clicking then you can presumably navigate a cave even if your light source goes out) and in fiction (this one should really be obvious), is considerable.
Android does protect against malicious non-Play and sideloaded apps, and Google doesn't have a problem with those being installed.
I didn't write that very clearly. Google doesn't have a problem with non-Play and sideloaded apps being installed in general. They do have a problem with malicious apps, regardless of source.
Thrashing is just virtual crashing.
