6 ms·

Personally I would say App Signing is the smallest worry. Far bigger are: 1. Mandatory XCode for iOS build/debug 2. Mandatory yearly payments for Apple if you w

Personally I would say App Signing is the smallest worry. Far bigger are: 1. Mandatory XCode for iOS build/debug 2. Mandatory yearly payments for Apple if you want to release iOS App 3. Mandatory DRM for iOS apps, even for Open Source apps 4. Horrible Apple certificate/provision profile system if you have multiple devices

zepto 6y ago
Sure - but the alternative is currently worse - a nightmare landscape of Trojans and malware. I actually agree with your basic premise, and think Apple should be required to make a bootcamp for iPhone. But then as a community we’re going to have to do to work to make a new ecosystem that is both open and safe enough for regular people. Right now it is one or the other, but not both.
- the8472 6y ago
  Complete user freedom includes the freedom to activate the orbital footgun array (e.g. kernel level debuggers), it is inherently unsafe. So we can't have both at the same time. But what we can have is more stops along the safe-powerful gradient and provide safe APIs/wrappers for the most popular use-cases that are developed through unsafe means.
  - saagarjha 6y ago
    macOS lets you install a kernel level debugger, though.
  - zepto 6y ago
    All security relies on on trust. Right now, iOS security relies on trusting Apple to evaluate the trustworthyness of third parties. Fully open systems rely on trusting yourself to evaluate the trustworthiness of third parties. I believe it’s possible to engineer a framework where there are more options for delegating trust than just these two. We don’t currently have such an infrastructure, but we need one.
    - yjftsjthsd-h 6y ago
      I mean, doesn't Android already have that middle ground? If I install F-Droid, I have to asses that I trust it, but thereafter I delegate trust to them and can install from their repos without having to re-decide every time.
      - zepto 6y ago
        To a certain extent yes, but delegation at the store level is extremely coarse grained. Also, no automatic updates.
        yjftsjthsd-h 6y ago
        > To a certain extent yes, but delegation at the store level is extremely coarse grained. I suppose that's true. I'm curious what level of precision you would prefer to see? Accepting a developer's key? > Also, no automatic updates. Only because Google decided to be uncooperative in their builds. If you control your own system partition, I believe you can still inject the privileged extension and have this. Google has also implied that this might change with Android 12 (https://android-developers.googleblog.com/2020/09/listening-to-developer-feedback-to.html https://android-developers.googleblog.com/2020/09/listening-...).
- swiley 6y ago
  Apple never sufficiently instruments code during app review; the curation doesn't actually prevent malware, it just lets them remove it once it's well known. If this weren't the case you wouldn't hear about people sneaking behavior apple doesn't like into published apps.
- deleted 6y ago
  [deleted]

zepto 6y ago

Sure - but the alternative is currently worse - a nightmare landscape of Trojans and malware. I actually agree with your basic premise, and think Apple should be required to make a bootcamp for iPhone. But then as a community we’re going to have to do to work to make a new ecosystem that is both open and safe enough for regular people. Right now it is one or the other, but not both.

the8472 6y ago
Complete user freedom includes the freedom to activate the orbital footgun array (e.g. kernel level debuggers), it is inherently unsafe. So we can't have both at the same time. But what we can have is more stops along the safe-powerful gradient and provide safe APIs/wrappers for the most popular use-cases that are developed through unsafe means.
- saagarjha 6y ago
  macOS lets you install a kernel level debugger, though.
- zepto 6y ago
  All security relies on on trust. Right now, iOS security relies on trusting Apple to evaluate the trustworthyness of third parties. Fully open systems rely on trusting yourself to evaluate the trustworthiness of third parties. I believe it’s possible to engineer a framework where there are more options for delegating trust than just these two. We don’t currently have such an infrastructure, but we need one.
  - yjftsjthsd-h 6y ago
    I mean, doesn't Android already have that middle ground? If I install F-Droid, I have to asses that I trust it, but thereafter I delegate trust to them and can install from their repos without having to re-decide every time.
    - zepto 6y ago
      To a certain extent yes, but delegation at the store level is extremely coarse grained. Also, no automatic updates.
      - yjftsjthsd-h 6y ago
        > To a certain extent yes, but delegation at the store level is extremely coarse grained. I suppose that's true. I'm curious what level of precision you would prefer to see? Accepting a developer's key? > Also, no automatic updates. Only because Google decided to be uncooperative in their builds. If you control your own system partition, I believe you can still inject the privileged extension and have this. Google has also implied that this might change with Android 12 (https://android-developers.googleblog.com/2020/09/listening-to-developer-feedback-to.html https://android-developers.googleblog.com/2020/09/listening-...).
swiley 6y ago
Apple never sufficiently instruments code during app review; the curation doesn't actually prevent malware, it just lets them remove it once it's well known. If this weren't the case you wouldn't hear about people sneaking behavior apple doesn't like into published apps.
deleted 6y ago
[deleted]