[HN Gopher] Enabling Developer Mode on a Device
___________________________________________________________________
Enabling Developer Mode on a Device
Author : judge2020
Score : 40 points
Date : 2022-06-06 20:14 UTC (2 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| Melatonic wrote:
| Makes me wonder if enabling the developer options on my Android
| is opening any security holes. I would think not (assuming you
| don't then go into those same options and start messing with
| stuff) but I always do it first thing. I love turning on the
| option where it shows a little white circle exactly where it is
| registering your touch - I am sure this was intended to be just
| for testing but it is super useful on a device as imprecise as a
| touchscreen.
| grishka wrote:
| Does this developer mode come with any changes to the signing
| requirements? For example, does it allow the installation of apps
| with self-signed, non-Apple-issued certificates?
| idle_zealot wrote:
| No, at least not right now. Apple may be preparing to be forced
| into allowing sideloading with this feature though.
| BeefySwain wrote:
| Can someone summarize how this compares to how things were prior
| (if there is even any change at all)? Does this make it easier or
| harder to sideload apps, for instance?
| akmarinov wrote:
| Looks like harder as you have to explicitly opt in and restart
| your device
| sokoloff wrote:
| I think it's an OK kind of harder though. It's harder in the
| sense that you have to more clearly express your intention to
| load a non-store app and take a reboot.
|
| It's not harder in the sense of "you are prohibited from
| doing it".
| irons wrote:
| Previously, each developer had to do one or more of:
|
| * use TestFlight for centralized distribution of pre-release
| apps, through Apple (with some lighter-touch app review
| involved), or
|
| * use enterprise signing (which requires enrolling in a more
| expensive program and jumping through some corporate hoops,
| with your apps subject to deactivation if you abuse it) to
| install on an unrestricted number of devices theoretically
| owned by your company, or
|
| * whitelist a pretty low number of specific iOS devices to
| install arbitrary apps onto -- I think that limit is still 100
| devices per year, per developer account
|
| This sounds like it removes the whitelisting requirement from
| the third option. Hope it's enough friction to prevent the
| worst aspects of sideloading from taking hold.
| akmarinov wrote:
| It's 100 devices per type per dev account, so 100 iPhones,
| 100 iPads, 100 Apple TVs, etc
| Wowfunhappy wrote:
| If this removes the whitelisting requirement, that would be
| awesome--but I'm very much not holding my breath. My
| pessimistic guess would be nothing else changes, just a bit
| of extra fiction.
| akmarinov wrote:
| Hmm this + the new API to check whether an app has been installed
| from the AppStore
| (https://developer.apple.com/documentation/storekit/apptransa...)
| makes me wonder what we're in for
| kgermino wrote:
| This seems like a positive change, or at least a non-issue. It's
| not a big deal to ask developers to check a "I know what I'm
| doing" box.
|
| However, I'm not sure how big of an attack vector they're closing
| here. I'm thinking of two channels:
|
| 1. Drive by installs when someone uses a public charger or
| another person's computer to charge while using their phone
|
| 2. Users being guided to install malicious apps themselves under
| the guise of fake support or similar setups.
|
| These just don't seem like major problems to me. (1) could
| probably work if you were targeting an individual, but it doesn't
| seem like this is the weak link. For (2) I can't imagine anyone
| who goes to the trouble of installing xcode and deploying to
| their device wouldn't be willing to just check that box too.
| jonfw wrote:
| #2 is probably the single biggest attack vector on these
| platforms
| ev1 wrote:
| 2) is basically going to be attempted on nearly every single
| kid with an iOS device (see "free fortnite skins / robux just
| follow these instructions and paste these in, also turn off
| firewall and av")
| kube-system wrote:
| Along with #1, could it also make it more difficult for attacks
| on devices where the attacker has physical access?
| kgermino wrote:
| I don't think so... I'm not sure, but it doesn't look like
| this adds anything beyond knowing the passcode (already
| required in my understanding) if you have time alone with the
| device.
| grishka wrote:
| (1) is already a non-issue because the device would ask you
| whether you "trust this computer" and then your passcode to
| proceed. Xcode won't even see it before you go through this
| prompt.
|
| FWIW Android does a similar thing with USB debugging enabled,
| just without the extra step with the passcode.
| kgermino wrote:
| A massive percentage of users will mindlessly say Trust and
| enter their passcode. Virtually no one will accidentally go
| into settings and enable Developer Mode
| grishka wrote:
| They will do so when plugging into a _charger_?
|
| (I don't oppose there being developer mode, I'm just adding
| that there are extra steps)
| WhyCause wrote:
| I have had iOS tell me I needed to "unlock the phone to
| enable accessories" (or something to that effect) when
| plugging in the charger that came in the box with the
| phone.
|
| This has usually been when the lightning port has been
| fouled by pocket lint or the cord has started going bad,
| but I bet it happens often enough to desensitize users
| (especially for people using off-brand cords) that it has
| been identified as a possible attack vector, and
| developer mode is the solution.
| mikeknoop wrote:
| This seems targeted at adding friction for alternative app stores
| eg. https://altstore.io/
| judge2020 wrote:
| Upon enabling, it shows this warning[0], then upon reboot
| requires the passcode to confirm[1].
|
| 0: https://i.judge.sh/40fyN/1bNGK4tR_k.png
|
| 1: https://i.judge.sh/JbQcE/Q2UdipID_A.png
___________________________________________________________________
(page generated 2022-06-06 23:01 UTC)