6 ms·

No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their

No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so you only have yourself to blame for this. Apple's rules can be harsh but I would rarely call them arbitrary. There is a very good security reason for Apple's stance here. And ultimately it's their store and their rules.

deleted 10y ago
[deleted]
jonathanstrange 10y ago
now we have to trust you to deliver that code safely to the user without being manipulated in transit. You have to trust app developers anyway, since they run native code on your machine. While there are security concerns, these are not the real motivation. Apple is gradually closing down their platform, as many people have predicted in the past. You can also see that in various subtle changes to Gatekeeper and the Sandboxing features. For me personally, the red line is when unsigned executables can no longer run on MacOS. If Apple ever disallows unsigned executables, I will immediately discontinue my application on MacOS and redirect customers who rely on it to Apple's customer support.
- rickycook 10y ago
  especially with relation to iOS you can't really say they're closing the platform further when at the most recent developer conference they opened a ton of APIs (siri, maps, imessage to name a few)
- ballenf 10y ago
  MS is ahead of Apple in this race to security via taking back control from the end user. I'm with you in theory, but really doubt that on either platform there won't be at least a dev-only way of running arbitrary unsigned apps. Time will tell. I think it will really come down to the severity of malware problems of the future. But I really think we'll just move 100% into bifurcated systems (we're already there with Intel's ME to a large extent) where the place that arbitrary code can run is completely segmented off from trusted code.
- eeeeeeeeeeeee 10y ago
  Yes, you have to trust the app developer. And Apple is acting as a check/oversight on that relationship, too. Whether it's of use or not, that is really another discussion. That is my personal red line also. But I am 100% in support of them enforcing signed apps for the majority, but it should be something you can turn off for advanced users via firmware/bios. My mom does not need to run unsigned apps she finds on the Internet.
jpetso 10y ago
> And ultimately it's their store and their rules. It wouldn't be as bad if their store weren't also the only store available for the platform. Because of this forced monoculture, the criticisms are well within scope.
- johndoe4589 10y ago
  Yeah, so we can have one store with strict policies that protect users and the value of the hardware; and a bunch of other shit stores that offer apps that can hijack our devices. That makes sense! And then Apple is to blame, and can spend tons of dollahs and man hours to fix problems caused by your "open" alternatives.
  - deleted 10y ago
    [deleted]
  - jessaustin 10y ago
    Oh yeah because that's what Android have been spending all their money on...
  - digler999 10y ago
    remember a few years back when windows was trying to promote their mobile app store and they were paying people to write shit apps just to have them hosted in the store? Or android where (at least they used to ) have fake apps that tell you how to "get" the real app ?
- valuearb 10y ago
  ios has as many stores as Android, all you need to do is jailbreak.
- ballenf 10y ago
  Criticisms of the rule are valid. Criticisms of Apple for enforcing existing rules are counter-productive. It's to everyone's benefit that all devs play by the same rules.
mikeash 10y ago
Security on iOS comes from the sandboxing that all apps run in. Apple's review process is really quick and adds approximately nothing in terms of security. Apps running in the sandbox should be safe no matter how evil they are, and if they can break out, the proper solution is to fix the sandbox.
- w0utert 10y ago
  That seems like a strange way to put it. Apps can still do all kinds of nasty things inside their sandbox, for example calling private API's that are now supposed to be caught in the review process, but also less obvious things like hot-patching strings (e.g. URLs) in the binary, sabotaging the device by deliberately hogging the CPU, playing sounds through the speaker, popping up fake prompts for fishing, etc. I agree that the review process itself does little for security, but surely you don't want to allow applications to pull in unchecked native code over the network, right?
  - mikeash 10y ago
    What's so bad about calling private APIs? I get why Apple doesn't want it, but as a user I don't care. The sandbox prevents apps from pulling in native code over the network. The OS won't allow pages to be marked as executable unless the code is signed by Apple.
    - Jonnax 10y ago
      Because a private API could give out details about you that you don't want shared to a random application or 3rd party advertising/analytics platform. For example serial numbers, user ids, lists of installed applications, etc.
      - mikeash 10y ago
        If a private API is a privacy or security concern then the sandbox needs to block it. Apple blocks private APIs because they don't want to maintain their compatibility across OS releases and don't want third party apps to break when those APIs change. Edit: I'm starting to suspect that people don't know what "private API" means, so I want to lay it out real quick. Apple ships a bunch of dynamic libraries with the OS that apps can link against and call into. Those libraries contain functions, global variables, classes, methods, etc. Some of those are published and documented and are intended for third parties to use. Some are unpublished, undocumented, and intended only for internal use. The difference is documentation and support. The machine doesn't know or care what's public and what's private. There's no security boundary between the two. Private APIs do nothing that a third-party developer couldn't do in their own code, if they knew how to write it. The only way Apple can check for private API usage is to have a big list of all the private APIs in their libraries and scan the app looking for calls to them. This is fundamentally impossible to do with certainty, because there's an unlimited number of ways to obfuscate such calls. Functionality that needs to be restricted due to privacy or security concerns has to be implemented in a completely separate process with requests from apps being made over some IPC mechanism. This is the only way to reliably gate access. Apple's prohibition against using private APIs is like an "employees only" sign on an unlocked door in a store. It serves a purpose, but that purpose is to help keep well-meaning but clueless customers away from an area where they might get confused, or lost, or hurt. It won't do anything for your store's security.

deleted 10y ago

[deleted]

jonathanstrange 10y ago

now we have to trust you to deliver that code safely to the user without being manipulated in transit. You have to trust app developers anyway, since they run native code on your machine. While there are security concerns, these are not the real motivation. Apple is gradually closing down their platform, as many people have predicted in the past. You can also see that in various subtle changes to Gatekeeper and the Sandboxing features. For me personally, the red line is when unsigned executables can no longer run on MacOS. If Apple ever disallows unsigned executables, I will immediately discontinue my application on MacOS and redirect customers who rely on it to Apple's customer support.

rickycook 10y ago
especially with relation to iOS you can't really say they're closing the platform further when at the most recent developer conference they opened a ton of APIs (siri, maps, imessage to name a few)
ballenf 10y ago
MS is ahead of Apple in this race to security via taking back control from the end user. I'm with you in theory, but really doubt that on either platform there won't be at least a dev-only way of running arbitrary unsigned apps. Time will tell. I think it will really come down to the severity of malware problems of the future. But I really think we'll just move 100% into bifurcated systems (we're already there with Intel's ME to a large extent) where the place that arbitrary code can run is completely segmented off from trusted code.
eeeeeeeeeeeee 10y ago
Yes, you have to trust the app developer. And Apple is acting as a check/oversight on that relationship, too. Whether it's of use or not, that is really another discussion. That is my personal red line also. But I am 100% in support of them enforcing signed apps for the majority, but it should be something you can turn off for advanced users via firmware/bios. My mom does not need to run unsigned apps she finds on the Internet.

jpetso 10y ago

> And ultimately it's their store and their rules. It wouldn't be as bad if their store weren't also the only store available for the platform. Because of this forced monoculture, the criticisms are well within scope.

johndoe4589 10y ago
Yeah, so we can have one store with strict policies that protect users and the value of the hardware; and a bunch of other shit stores that offer apps that can hijack our devices. That makes sense! And then Apple is to blame, and can spend tons of dollahs and man hours to fix problems caused by your "open" alternatives.
- deleted 10y ago
  [deleted]
- jessaustin 10y ago
  Oh yeah because that's what Android have been spending all their money on...
- digler999 10y ago
  remember a few years back when windows was trying to promote their mobile app store and they were paying people to write shit apps just to have them hosted in the store? Or android where (at least they used to ) have fake apps that tell you how to "get" the real app ?
valuearb 10y ago
ios has as many stores as Android, all you need to do is jailbreak.
ballenf 10y ago
Criticisms of the rule are valid. Criticisms of Apple for enforcing existing rules are counter-productive. It's to everyone's benefit that all devs play by the same rules.

mikeash 10y ago

Security on iOS comes from the sandboxing that all apps run in. Apple's review process is really quick and adds approximately nothing in terms of security. Apps running in the sandbox should be safe no matter how evil they are, and if they can break out, the proper solution is to fix the sandbox.

w0utert 10y ago
That seems like a strange way to put it. Apps can still do all kinds of nasty things inside their sandbox, for example calling private API's that are now supposed to be caught in the review process, but also less obvious things like hot-patching strings (e.g. URLs) in the binary, sabotaging the device by deliberately hogging the CPU, playing sounds through the speaker, popping up fake prompts for fishing, etc. I agree that the review process itself does little for security, but surely you don't want to allow applications to pull in unchecked native code over the network, right?
- mikeash 10y ago
  What's so bad about calling private APIs? I get why Apple doesn't want it, but as a user I don't care. The sandbox prevents apps from pulling in native code over the network. The OS won't allow pages to be marked as executable unless the code is signed by Apple.
  - Jonnax 10y ago
    Because a private API could give out details about you that you don't want shared to a random application or 3rd party advertising/analytics platform. For example serial numbers, user ids, lists of installed applications, etc.
    - mikeash 10y ago
      If a private API is a privacy or security concern then the sandbox needs to block it. Apple blocks private APIs because they don't want to maintain their compatibility across OS releases and don't want third party apps to break when those APIs change. Edit: I'm starting to suspect that people don't know what "private API" means, so I want to lay it out real quick. Apple ships a bunch of dynamic libraries with the OS that apps can link against and call into. Those libraries contain functions, global variables, classes, methods, etc. Some of those are published and documented and are intended for third parties to use. Some are unpublished, undocumented, and intended only for internal use. The difference is documentation and support. The machine doesn't know or care what's public and what's private. There's no security boundary between the two. Private APIs do nothing that a third-party developer couldn't do in their own code, if they knew how to write it. The only way Apple can check for private API usage is to have a big list of all the private APIs in their libraries and scan the app looking for calls to them. This is fundamentally impossible to do with certainty, because there's an unlimited number of ways to obfuscate such calls. Functionality that needs to be restricted due to privacy or security concerns has to be implemented in a completely separate process with requests from apps being made over some IPC mechanism. This is the only way to reliably gate access. Apple's prohibition against using private APIs is like an "employees only" sign on an unlocked door in a store. It serves a purpose, but that purpose is to help keep well-meaning but clueless customers away from an area where they might get confused, or lost, or hurt. It won't do anything for your store's security.