5 ms·

> Apple are themselves exempt from the restriction to ship sandboxed apps - this is hypocritical. What makes it hypocritical? Apple developed the OS that you'r

by eridius 12y ago

> Apple are themselves exempt from the restriction to ship sandboxed apps - this is hypocritical. What makes it hypocritical? Apple developed the OS that you're using, so there's hardly a trust issue when talking about running applications from Apple on top of the Apple-developed OS. Sandboxing doesn't exist because of some high-minded ideal, it exists to solve the trust and security problem. Apple should sandbox any apps they ship if at all possible, but only because it protects the app and the user from any security issues. If an app can be remotely exploited somehow, then being sandboxed prevents the exploit from having full access to the local filesystem. But beyond that one concern (which may not even be relevant for apps that don't really do anything with the network), there's no real reason to care whether Apple sandboxes a given app that they ship. > Moreover, it objectively leads to a worse experience for customers What does? You're being a bit unclear here so I don't know what you're referring to with "it" here. Apple being exempt from sandboxing restrictions leads to a worse experience for customers? Doubtful. > It's an example how the MAS effectively cripples 3rd party apps without leaving them a choice What do you mean, without leaving them a choice? The MAS is just one of many storefronts available to Mac users. 3rd-party apps that don't wish to sandbox always have the choice of not using the MAS. They can continue to work exactly as they have done for the past several decades. The MAS is relatively new and is not replacing any existing software delivery mechanism, nor is it imposing any restrictions on apps that choose to ship outside the MAS. It doesn't even prevent users from migrating to a non-MAS variant of the app later; it's been well-known for a long time now how to have an app that supports both MAS and non-MAS distribution channels and have the non-MAS app still validate the MAS license.

milen 12y ago
> But beyond that one concern (which may not even be relevant for apps that don't really do anything with the network), there's no real reason to care whether Apple sandboxes a given app that they ship. The concern is that if you want to ship software on the MAS, like some of Apple's, that requires certain functionality which does not have a way to be accessed if you're sandboxed, then you cannot - while Apple can. As I mentioned multiple times, it's Apple's platform, they make the rules and can do whatever they want but this means that there are certain classes of software that cannot be distributed via the MAS by 3rd parties, only by Apple as they are not bound by the same rules. > What does? You're being a bit unclear here so I don't know what you're referring to with "it" here. The request to remove functionality due to (M)AS rules leads to an inferior experience for customers, as those customers can longer access that functionality. > Apple being exempt from sandboxing restrictions leads to a worse experience for customers? Doubtful. I don't know how you came up with that, it was never said nor implied in any way whatsoever. > What do you mean, without leaving them a choice? It means that if you want to distribute via MAS, you have to cripple (or remove) part of your app's functionality in order to pass review. Again, nothing inherently wrong with that but the net effect is that your software might be inferior when distributed via the MAS vs outside.
- eridius 12y ago
  The MAS is Apple's storefront. Of course their own software is going to be distributed via it, whether or not that software is sandboxed. The existence of non-sandboxed Apple software on the MAS does not impact 3rd-party MAS software in any way, shape, or form. Basically, the goal of the MAS is to be able to sell software that users can implicitly trust to not be harmful. For Apple software, users can trust it because it's Apple. For 3rd-party software, the only way to ensure the trustworthiness is to require sandboxing. Apple software should be sandboxed when possible, because that minimizes the downside of certain classes of software bugs, but beyond that one scenario, there's no reason to care whether Apple software is sandboxed. Yes, there are certain classes of 3rd-party software that cannot be shipped on the MAS because of sandboxing. But Apple allowing their own software to ship un-sandboxed has no bearing on this. The sandboxing requirement would prevent this 3rd-party software from shipping on the MAS regardless of whether Apple sandboxed their own apps. The only real argument to be made here is claiming that 3rd-party apps should be able to ship on the MAS without being sandboxed, but that runs counter to the entire purpose of the MAS and will never happen. The only really useful thing to actually try and get Apple to change is to expand the sandboxing capabilities to allow certain things that 3rd-party apps want to do and cannot do today. They've added more and more capabilities over time. The question is what functionality can be effectively exposed to sandboxed apps without opening up a security hole. > The request to remove functionality due to (M)AS rules leads to an inferior experience for customers, as those customers can longer access that functionality. That functionality should never have been in the MAS app to begin with. In the case of GaragePay I'm assuming they used a temporary sandbox exception, as Apple allowed those when sandboxing was new to give 3rd-party apps time to adapt, and to find out what exemptions were commonly requested in order to figure out in what ways the sandbox needed to be extended. If that's the case, then GaragePay's developer should have known from day 1 that they'd eventually have to remove this functionality (assuming the sandbox would eventually allow for invoking `hdiutil` should have been obviously unlikely from the start). In most publicized cases, the app that gets the rejection that requires removing functionality was always in violation of the rule, and were just hoping to not get noticed. Sometimes that works, sometimes they get caught. And when caught obviously violating an existing rule, there really should be no surprise at all that Apple requires compliance with the rule. And there should be no outrage either, or claims that Apple should allow the app to continue violating the rule. The only really valid argument here is that Apple should be consistent in applying the rules, and I think everybody (including Apple) agrees on that point. It's the cases where Apple rejects an app for what many believe is an improper application of a rule that deserves community outrage. In this case, I think the App Store reviewer is incorrectly applying rules meant for regular document storage as if it had anything to do with iCloud Drive. But please note that Panic is not asking for community outrage. They're just explaining to their users why the functionality is gone. I expect they're taking the right steps privately, talking to the Review Board and whatnot. Also note that the claim "Apple shouldn't apply that rule, because it removes app functionality, and that's bad for users" is quite ridiculous. Apple not consistently applying certain rules is the #1 complaint people tend to have with the App Store review policies. And claiming that "user functionality" is so holy that it must be preserved even when it obviously violates the rules makes no sense. The fact that an app manages to sneak rule violations past the review board in the past does not in any way mean it should be able to do so in the future, and the fact that an app relies on rule violations in order to provide functionality does not mean it deserves to be able to violate the rules. > It means that if you want to distribute via MAS, you have to cripple (or remove) part of your app's functionality in order to pass review. Again, nothing inherently wrong with that but the net effect is that your software might be inferior when distributed via the MAS vs outside. If your app requires violating app store rules for certain functionality, then you shouldn't be using the MAS as your distribution channel. It's that simple. > I don't know how you came up with that, it was never said nor implied in any way whatsoever. That was the subject of the immediately prior sentence. It provided the context for the subsequent sentence, and was the natural choice for the meaning of the word "it", except in that it didn't make much sense. Which is why I asked for clarification.
xp84 12y ago
> The MAS is relatively new and is not replacing any existing software delivery mechanism Really now? I feel like I need to preface this by saying I love all my Macs, my iPhones (all 5 that I've owned), iPads, etc. I also love the convenience and simplicity of using the MAS compared to any other way of getting free and paid software. But even I think there is a nearly 100% chance that by, say, 3-5 years from now, Apple will prevent installing software from sources other than MAS. You can tell by the trajectory of MAS. It started out as just an equally-supported option. Now installing software not from the MAS is a warning, and installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app). It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee. Given that iOS doesn't have any supported way to sideload arbitrary third-party apps the way, we should expect this to be the case for the Mac as well. You will be able to run apps you've signed with your own developer or enterprise distribution certificate, but I doubt you'll be able to download & just run an app from Panic or anyone else without jumping through hoops or "jailbreaking."
- eridius 12y ago
  > Now installing software not from the MAS is a warning No it's not. Where did you get that idea? The only issue is installing software that isn't codesigned with an Apple-signed certificate. Any developer enrolled in Apple's Mac Developer program can get an Apple-signed certificate and self-sign their 3rd-party non-MAS software and users will have the same experience as using MAS software. The only dialog they'll get is the standard "Are you sure you want to run this program you just downloaded?" dialog that we've had for a while now. Which, admittedly, I don't think MAS apps have, but that's because MAS apps aren't downloaded with a web browser; if you install a 3rd-party app via some mechanism other than downloading with a web browser it should similarly bypass that dialog. > installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app) Well, the simple answer is to change the Gatekeeper setting, but the more relevant question is why are you even providing support for such an app? Any app that isn't properly code-signed is likely to not have had an update in several years. The only excuse beyond old unsupported apps for not properly being code-signed is the rare open-source cross-platform app that provides an OS X download without codesigning, which is not something most casual users are generally expected to be using anyway. All of this is beside the point anyway. Gatekeper and the Mac App Store are two completely separate technologies. And whether or not your application is distributed on the MAS is not relevant to Gatekeeper, except in that you cannot distribute on the MAS if your app is not properly codesigned. > It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee. That's pure 100% FUD. It is not at all logical to assume that Apple will pull such an insanely stupid move. iOS being locked down does not at all say that OS X will be locked down in the same fashion; it would be virtually impossible to lock down OS X like that, and any attempt to do so would be so incredibly user-hostile that it's laughable to think Apple would do that, and would probably destroy OS X. I have to wonder if you have some vested interest in sowing distrust in Apple and OS X. Why else would you make such an absurd claim with a straight face?

by eridius 12y ago

milen 12y ago

> But beyond that one concern (which may not even be relevant for apps that don't really do anything with the network), there's no real reason to care whether Apple sandboxes a given app that they ship. The concern is that if you want to ship software on the MAS, like some of Apple's, that requires certain functionality which does not have a way to be accessed if you're sandboxed, then you cannot - while Apple can. As I mentioned multiple times, it's Apple's platform, they make the rules and can do whatever they want but this means that there are certain classes of software that cannot be distributed via the MAS by 3rd parties, only by Apple as they are not bound by the same rules. > What does? You're being a bit unclear here so I don't know what you're referring to with "it" here. The request to remove functionality due to (M)AS rules leads to an inferior experience for customers, as those customers can longer access that functionality. > Apple being exempt from sandboxing restrictions leads to a worse experience for customers? Doubtful. I don't know how you came up with that, it was never said nor implied in any way whatsoever. > What do you mean, without leaving them a choice? It means that if you want to distribute via MAS, you have to cripple (or remove) part of your app's functionality in order to pass review. Again, nothing inherently wrong with that but the net effect is that your software might be inferior when distributed via the MAS vs outside.

eridius 12y ago
The MAS is Apple's storefront. Of course their own software is going to be distributed via it, whether or not that software is sandboxed. The existence of non-sandboxed Apple software on the MAS does not impact 3rd-party MAS software in any way, shape, or form. Basically, the goal of the MAS is to be able to sell software that users can implicitly trust to not be harmful. For Apple software, users can trust it because it's Apple. For 3rd-party software, the only way to ensure the trustworthiness is to require sandboxing. Apple software should be sandboxed when possible, because that minimizes the downside of certain classes of software bugs, but beyond that one scenario, there's no reason to care whether Apple software is sandboxed. Yes, there are certain classes of 3rd-party software that cannot be shipped on the MAS because of sandboxing. But Apple allowing their own software to ship un-sandboxed has no bearing on this. The sandboxing requirement would prevent this 3rd-party software from shipping on the MAS regardless of whether Apple sandboxed their own apps. The only real argument to be made here is claiming that 3rd-party apps should be able to ship on the MAS without being sandboxed, but that runs counter to the entire purpose of the MAS and will never happen. The only really useful thing to actually try and get Apple to change is to expand the sandboxing capabilities to allow certain things that 3rd-party apps want to do and cannot do today. They've added more and more capabilities over time. The question is what functionality can be effectively exposed to sandboxed apps without opening up a security hole. > The request to remove functionality due to (M)AS rules leads to an inferior experience for customers, as those customers can longer access that functionality. That functionality should never have been in the MAS app to begin with. In the case of GaragePay I'm assuming they used a temporary sandbox exception, as Apple allowed those when sandboxing was new to give 3rd-party apps time to adapt, and to find out what exemptions were commonly requested in order to figure out in what ways the sandbox needed to be extended. If that's the case, then GaragePay's developer should have known from day 1 that they'd eventually have to remove this functionality (assuming the sandbox would eventually allow for invoking `hdiutil` should have been obviously unlikely from the start). In most publicized cases, the app that gets the rejection that requires removing functionality was always in violation of the rule, and were just hoping to not get noticed. Sometimes that works, sometimes they get caught. And when caught obviously violating an existing rule, there really should be no surprise at all that Apple requires compliance with the rule. And there should be no outrage either, or claims that Apple should allow the app to continue violating the rule. The only really valid argument here is that Apple should be consistent in applying the rules, and I think everybody (including Apple) agrees on that point. It's the cases where Apple rejects an app for what many believe is an improper application of a rule that deserves community outrage. In this case, I think the App Store reviewer is incorrectly applying rules meant for regular document storage as if it had anything to do with iCloud Drive. But please note that Panic is not asking for community outrage. They're just explaining to their users why the functionality is gone. I expect they're taking the right steps privately, talking to the Review Board and whatnot. Also note that the claim "Apple shouldn't apply that rule, because it removes app functionality, and that's bad for users" is quite ridiculous. Apple not consistently applying certain rules is the #1 complaint people tend to have with the App Store review policies. And claiming that "user functionality" is so holy that it must be preserved even when it obviously violates the rules makes no sense. The fact that an app manages to sneak rule violations past the review board in the past does not in any way mean it should be able to do so in the future, and the fact that an app relies on rule violations in order to provide functionality does not mean it deserves to be able to violate the rules. > It means that if you want to distribute via MAS, you have to cripple (or remove) part of your app's functionality in order to pass review. Again, nothing inherently wrong with that but the net effect is that your software might be inferior when distributed via the MAS vs outside. If your app requires violating app store rules for certain functionality, then you shouldn't be using the MAS as your distribution channel. It's that simple. > I don't know how you came up with that, it was never said nor implied in any way whatsoever. That was the subject of the immediately prior sentence. It provided the context for the subsequent sentence, and was the natural choice for the meaning of the word "it", except in that it didn't make much sense. Which is why I asked for clarification.

xp84 12y ago

> The MAS is relatively new and is not replacing any existing software delivery mechanism Really now? I feel like I need to preface this by saying I love all my Macs, my iPhones (all 5 that I've owned), iPads, etc. I also love the convenience and simplicity of using the MAS compared to any other way of getting free and paid software. But even I think there is a nearly 100% chance that by, say, 3-5 years from now, Apple will prevent installing software from sources other than MAS. You can tell by the trajectory of MAS. It started out as just an equally-supported option. Now installing software not from the MAS is a warning, and installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app). It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee. Given that iOS doesn't have any supported way to sideload arbitrary third-party apps the way, we should expect this to be the case for the Mac as well. You will be able to run apps you've signed with your own developer or enterprise distribution certificate, but I doubt you'll be able to download & just run an app from Panic or anyone else without jumping through hoops or "jailbreaking."

eridius 12y ago
> Now installing software not from the MAS is a warning No it's not. Where did you get that idea? The only issue is installing software that isn't codesigned with an Apple-signed certificate. Any developer enrolled in Apple's Mac Developer program can get an Apple-signed certificate and self-sign their 3rd-party non-MAS software and users will have the same experience as using MAS software. The only dialog they'll get is the standard "Are you sure you want to run this program you just downloaded?" dialog that we've had for a while now. Which, admittedly, I don't think MAS apps have, but that's because MAS apps aren't downloaded with a web browser; if you install a 3rd-party app via some mechanism other than downloading with a web browser it should similarly bypass that dialog. > installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app) Well, the simple answer is to change the Gatekeeper setting, but the more relevant question is why are you even providing support for such an app? Any app that isn't properly code-signed is likely to not have had an update in several years. The only excuse beyond old unsupported apps for not properly being code-signed is the rare open-source cross-platform app that provides an OS X download without codesigning, which is not something most casual users are generally expected to be using anyway. All of this is beside the point anyway. Gatekeper and the Mac App Store are two completely separate technologies. And whether or not your application is distributed on the MAS is not relevant to Gatekeeper, except in that you cannot distribute on the MAS if your app is not properly codesigned. > It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee. That's pure 100% FUD. It is not at all logical to assume that Apple will pull such an insanely stupid move. iOS being locked down does not at all say that OS X will be locked down in the same fashion; it would be virtually impossible to lock down OS X like that, and any attempt to do so would be so incredibly user-hostile that it's laughable to think Apple would do that, and would probably destroy OS X. I have to wonder if you have some vested interest in sowing distrust in Apple and OS X. Why else would you make such an absurd claim with a straight face?