Does it still work if you're not the original retail customer?

> Why have three Ctrl keys?

You could just swap caps with one.

> Why not use an empty modifier and have your own shortcut keys that you can guarantee no other program uses?

Because that would require messy tinkering with multiple layers of software.

Very interesting. Thank you.

I presume you didn't follow the link I pointed to, which for sure points an .apk URL

Now, if you're trying to be extra cute by saying "react native is a webpage with more steps," I'm not trying to have that fight, but I can assure you with 100% confidence that Joplin's apk loads without Internet connectivity, making it not meet my definition of "a web app"

> The internet tethering limits are in the contract though.

I don't recognize that 10 GiB downloaded via my phone, or via my laptop connected to my phone as different, no matter what the contract says.

> on an iPad.

I said iOS not iPadOS, but that's good to know.

Ironically, downloading huge items is easy to do without tethering.

And video streaming, probably most people's biggest bandwidth use, fits very well on phones.

Does anyone offer a tethering plan that's rate limited but not data limited?

> they’re taking measures to reduce bandwidth hogs

My problem with this is that it's the wrong measure.

There's no good technical reason to shape traffic to a specific rate irrespective of network conditions or capacity. All of the links in the chain support QoS.

Shaping a bandwidth hog to a tier below the rest of the users makes sense, but that's not what's going on.

> Any diagnostic and recovery tools available at boot time are going to be designed to be non-privileged, so there are a number of things (such as validating the integrity of the encrypted user data partition) that just aren't going to be possible. That locks you down to basically rudimentary hardware validation.

Eh, sort of. Remember that most users have an iCloud Recovery Key enabled. Meaning that Apple could design a non-tethered restore process for iOS that looks like:

1. The device boots into recovery mode; asks the user to configure a wi-fi connection (if none of the ones it has persisted in NVRAM are available.)

2. The device reaches out to Apple, hitting an "I'm a broken device; help me!" endpoint, referencing the iCloud account the device is signed into, and signing the request with the device's root TPM key.

3. Apple validates that the message is from a device that is registered to the given user's iCloud account.

4. Apple sends back a signed payload containing: a device-root-TPM-key-encrypted copy of the device's own disk encryption key (the iCloud Recovery Key), and some amount of "privileged restore" logic (at minimum, just an XPC daemon for the restore image to load and run as root, with a code-signed capabilities manifest that grants the device-shipped client-side of that XPC connection the authority to make changes through it; or, at maximum, a whole second-stage recovery firmware for the restore image to reboot into.)

5. The resulting boot would have the same privileges to modify the on-disk system that an OS firmware update does. But, unlike an OS update, the boot that results by combining this Apple-delivered privileged payload, with the existing restore image, would be interactive. Just like macOS's Remote Recovery image, it would give the user access to some of the same management functionality that Apple would use to repair the filesystem, forensically archive + wipe the disk, repair user permission databases, etc.

6. However, this privileged recovery experience, would still ultimately be a DRMed kiosk experience. (The tool would have full power to access or modify your on-disk system, but the tool wouldn't give you any way to modify the running tool itself. Within the OS of the recovery experience, you're still an unprivileged user. Like running VM software on ChromeOS, where you have root in the VM but not on the host.) Especially, since the disk is decrypted enough to get at the keychain, regular authentication methods could be used to enforce that the device's owner is present and consenting to the repair — i.e. the device could require a "sign-in" with iCloud password + TouchID/FaceID/etc. — just like when first making a purchase on the App Store on a new device. (If the disk is so corrupted that this info is unavailable, then the device could fall back to "authorize with another device on your iCloud account" auth; and if that too wouldn't work, then it'd probably tell you to stop what you're doing and go to an Apple Store so they can identity-verify you.)

7. At the same time, Apple could add special handling into the Secure Enclave for a sort of PKI latch storage type: "anyone with the pubkey can set latch k to a value v; but only a message signed by the associated privkey can modify/delete the latch k once set." Apple could then make this privileged recovery experience do two things once booted:

- Tell the Apple servers "consider me de-activated for now; and require an extended activation — with full remote attestation — to reactivate!" Boot would not proceed until the Apple servers confirm the de-activation.

- Set an on-device TPM latch, using an Apple-provided pubkey.

(These two actions can be atomic, as a "start non-tethered repair session" endpoint, that both marks the device as de-activated, and returns the pubkey for a new dynamically-generated keypair associated with that repair session in Apple's backend.)

8. The latch means that the regular on-disk OS won't be allowed to boot again until this recovery process "considers itself complete" — so you can't break out of it mid-job by hard-resetting the device. And the remote de-activation means that, if you were trying to use non-tethered repair on "some random grey-market iPhone" to wipe it and/or scrap it for parts, the device and/or parts would still be considered stolen.

9. And "extended activation with full remote attestation" means that, when you do finish the recovery process, you wouldn't boot into the regular on-disk OS, but into a special "remote attester" mode (essentially, another type of small-ish factory-shipped recovery volume, that the repair system either has no right to modify, or always puts back after a reformat) that carefully examines and validates the OS to ensure everything is as it should be to enforce security (no rootkits, no jailbreaks) — sending that info to Apple, who then send back activation only if they're happy with what they see. (And if you somehow trick the device into booting into the on-disk OS instead of the remote attester, the on-disk OS will find that it can't activate with Apple; will notice the latch; and will just reboot back to the remote attester to try extended activation.)

Under this tight set of constraints, you can do whatever you need to do during recovery — you have root on the phone! But you're also forced to put everything back into a valid state, before Apple will be willing to "release" you from that mode back into regular use of the phone.

(Amusingly enough, Apple could even let this repair image totally break the "paradigm" that iOS normally operates under. The repair image could expose Terminal.app. The repair image could display a desktop when connected to HDMI. Heck, for the iPhone 16, the repair image could be a somewhat-neutered copy of macOS [similar to macOS Recovery] running on the M-series processor, where you're expected to connect a keyboard/mouse/display to it using a USB-C dock! As long as that sort of stuff is only available in this repair experience — and this repair experience is in turn useless as a phone [or as a general-purpose computer] — then exposing these capabilities during repair wouldn't be sales-cannibalizing.)

Also, if you think about it, this is in spirit basically the same "workflow" as Apple's Self Service [Hardware] Repair process — but without the series of phone calls being required to validate that you're actually someone who was asked to repair that device (instead of some rando who bought the phone on the grey market) and to sign off on your repair "session" as completed at the end.

In this case, you're repairing your own device that Apple knows you own because it's listed on your iCloud account, so Apple already has all the info they need to auto-authorize the "repair"; and you're purely doing a firmware/OS repair, not a hardware repair, so the device itself can do the "signing off" at the end.

Apple started shipping exclusively USB-C cables/chargers with iPhones with the 11 in 2019. There's certainly a case to be made that they should have done that earlier (iPhone X or even back with the iPhone 7).

It is perhaps worth noting that the USB-IF and Apple had a "complex" relationship for many years, and to this day Apple still doesn't sell a single 1st party device or cable which is USB certified.

There are really only six options:

1. Keep using Lightning

2. Update Lightning

3. Switch to another proprietary connector

4. Switch to a standard but non-USB-C connector

5. Switch to full wireless

6. Switch to USB-C

(1) Makes no sense, they were going to switch to something eventually. If anyone doubts that and thinks Lightning was going to stick around forever, they don't live in the real world. It's so far from reasonable it's not worth considering. Lighting is worse than USB-C for data rates and power, it was outdated years before they made the switch.

(2) Could have made sense but they would have done it earlier if it was in their plans. They could have done that around '20-'21 and given a "Look, see, our new connector is 10x faster than USB-C and fast charges in half the time!" But it would have to match or beat USB-C to make any sense. Maintaining compatibility does means people still get to use old cables with slower charging and data rates for a while until those cables break or get lost, and it means the new cable can still be used with old devices (but will drop to whatever data and power rates they support). It also means Apple has to have, for the iPhone only, an extra team maintaining an extra connector type not used by anything else.

(3) Same issue as (2), but this one has to beat USB-C. And switching to a different proprietary connector means their customers now need at least 3 cables (4 for Apple Watch users, but those folks have to have at least 2 cables anyways since that one is wireless charging only). Users would need Lighting for accessors/peripherals, USB-C for iPad, MBP, and <new proprietary> for a new iPhone. That would go over well.

(4) Same problems as (2) and (3) but at least it's standard. It also has to beat USB-C and what connector would they use that's standard, popular, and not USB-C?

(5) Not viable for the phones. Too many consumers expect their phones to connect, physically, to cars and headsets. Without a 3.5 mm jack that leaves the Lightning, and now USB-C, connector. With cars, unless you have wireless CarPlay (newer cars only) you're SOL for CarPlay, and it's a downgrade to lose that and end up with just audio over Bluetooth. This hurts them substantially in the market and is non-viable. In 5 years, may be a different story.

(6) They already switched to USB-C on pretty much everything else. It opens up every USB-C peripheral (most of Apple's own are already wireless, with Lightning or USB-C to charge, increasingly USB-C). It's the standard connector. It offers fast charging and higher data rates. They already have licenses and contracts in place to use it. They don't have to dedicate an engineering team to support a one-off variant.

(6) is the most sensible option followed by (2). (2) should have happened years ago if it was in their plans. The regulations may have moved up the timeline, but it didn't change what was going to happen.

So what's your argument, which of the non-USB-C options do you think was on Apple's agenda before the regulators came calling? Given that they'd already switched almost every other device in their lineup to USB-C, what was Apple going to do with the iPhone?

Right. I was saying hypothetically if you had a big enough chain of exploits for all the various protections Apple has then this may let you use them without physically touching the device, only being really close.

But if you had that chain of exploits, who cares. You already won the game.

So I don’t think this matters to security.