4 ms·

I see you asserting this over and over. What I don't see is you providing any real evidence that this is a core part of the decision-making process. Apple isn

I see you asserting this over and over. What I don't see is you providing any real evidence that this is a core part of the decision-making process. Apple isn't particularly incentivized to find a different way that avoids the tools they already have that already make it harder and costlier for parties to get around their security mechanisms. That is not the same as making decisions because they protect the business model. Which is to say, it appears that you're the one oversimplifying and conflating (btw, I do not think that word means what you think it means) some very different motivations.

sneak 6y ago
Apple charges 10x the market rate for credit card processing on the purchase of mobile apps on iOS. Why do you think this is possible? Take it from dhh if you don't believe me: https://mobile.twitter.com/dhh/status/1328339591389175808 https://mobile.twitter.com/dhh/status/1328339591389175808
- shadowfiend 6y ago
  Sorry, you seem to have deviated into an unrelated axe you're grinding. Try again, this time with the axe you were originally grinding, which I'll help with: > [Online signature check] is also a move to protect certain streams of Apple services revenue, in addition to protecting users from malware, and it always has been. To restate and avoid drifting into another non sequitur, this ascribes intent; that is, it suggests that part of the reason online signature check was added, and part of how it has been evolved, is to protect certain streams of Apple services revenue. That would be your argument, which has no evidence to support it, but you suggest is backed by “facts”[1], which appear to be nowhere to be found. Are these facts somewhere to be found? Or are you stating hypotheses as facts? [1] https://news.ycombinator.com/item?id=25210475 https://news.ycombinator.com/item?id=25210475
  - sneak 6y ago
    I have no axe to grind with Apple. I'm a happy Apple customer and have been for most of 30 years. The same code that keeps malware from running on a mac (or iphone) keeps non-app-store apps from running on an iphone, or prompts you to move non-notarized apps to the trash on a mac. It's not some separate thing: the exact same code path that protects the consumer store revenue and developer notarization service revenue also protects users against malware. EDIT, for clarity: I am speaking of Apple-developed, Apple-owned platform security code, where root keys are not held by anyone other than Apple, not generic crypto primitives or the concept of code signing in general (where we have a P-as-in-public PKI).
    - Spivak 6y ago
      Which is the same code that keeps unsigned bootloaders from running on PCs which is the same code that keeps unsigned packages from being installed on Linux systems which is the same code that keeps unsigned browser extensions from running on Firefox which is the same code that shows the scary warning on Windows. Everyone seems to like code signing.
      - novok 6y ago
        Lol you have never had to deal with apple's over complicated code signing as a developer. Adds a lot of wrenches when your just trying to do basic stuff like codesign and push test builds onto a USB connected device from a bash script and it is flaky and undocumented as fuck. I am honestly jealous of my android counterparts with their far simpler system and first class command line support via adb.
shawnz 6y ago
I agree that there is no direct evidence that this decision was part of their formal decision-making process. But there is still something to be said for designing systems where it's not possible for those negative incentives to exist, whether or not there is any current intention of taking advantage of them. Of the tens of thousands of people who had a hand in shaping macOS today, it's impossible to say what their collective intentions were in all the decisions they made. So I think it's useless to talk only about the intentions you can prove just by looking at their formal decision-making process. That is why we need to be working to protect privacy at every level with a "defense in depth" approach. And of course it goes without saying that all major vendors have issues like this and could be working harder to make sure that these incentives don't get created.
- shadowfiend 6y ago
  > designing systems where it's not possible for those negative incentives to exist No doubt, but even in simple systems this is considerably more difficult than it sounds. Incentive systems are not easy, and any incentive system is often twisted into a game that produces unexpected poor behaviors. Try to achieve that at a 100+k employee company and you're guaranteed to end up with misaligned or counterintuitive incentives. The reason something stronger than simple assertion matters here is because Apple actually has added an incentive system: trumpeting privacy as a core feature means they tie their brand to their ability to deliver on privacy. That means that being called out for privacy issues has greater potential harm for the company, and thus its bottom line, in a way that's far more direct and monetarily impactful than $100 annual developer fees ever will be. Even cynically, you can see the same mechanic at work with the recent reduction of app store percentages for small businesses. Apple has made it a core part of its developer outreach that the app store is a good thing for developers: they've made it part of their brand. If they're called out for something that makes many of those developers disagree, or even for something that makes users perceive that part of the brand as incorrect, it has implications to the whole company's bottom line (not just the developer id sliver of it). > it's useless to talk only about the intentions you can prove just by looking at their formal decision-making process For what it's worth, my point isn't tied to formal decision-making, it's tied to the informal parts as well. What I'm saying is that this can be a completely technical decision that relies on the existing business structure without ever taking into account whether it will raise revenue from developer ids. The developer id's existence is a fact. The “DoS resistance” characteristics, if you will, of having the developer ids cost money is a fact. As a system architect, leveraging those facts for system security seems perfectly reasonable. Yes, absolutely they should have taken privacy into account as well. “We haven't used it” and “we won't use it” aren't the same as “we can't use it”. But here's the thing: to me, the strongest indicator of whether a company is committed to an approach is whether they react positively when they are called out, or whether they double down on their mistakes. Apple was called out here, and they've committed to doing just about all of the things they should be doing. You could use this same framing to say that Apple isn't as committed to developers thriving on their platform as they are to living up to their privacy commitment, of course. Tl;dr: customers are part of the incentive system, tying your brand to a commitment aggressively as Apple has tied theirs to privacy has an impact on customers, and this is a great way to introduce an additional external forcing function to your internal teams.

sneak 6y ago

Apple charges 10x the market rate for credit card processing on the purchase of mobile apps on iOS. Why do you think this is possible? Take it from dhh if you don't believe me: https://mobile.twitter.com/dhh/status/1328339591389175808 https://mobile.twitter.com/dhh/status/1328339591389175808

shadowfiend 6y ago
Sorry, you seem to have deviated into an unrelated axe you're grinding. Try again, this time with the axe you were originally grinding, which I'll help with: > [Online signature check] is also a move to protect certain streams of Apple services revenue, in addition to protecting users from malware, and it always has been. To restate and avoid drifting into another non sequitur, this ascribes intent; that is, it suggests that part of the reason online signature check was added, and part of how it has been evolved, is to protect certain streams of Apple services revenue. That would be your argument, which has no evidence to support it, but you suggest is backed by “facts”[1], which appear to be nowhere to be found. Are these facts somewhere to be found? Or are you stating hypotheses as facts? [1] https://news.ycombinator.com/item?id=25210475 https://news.ycombinator.com/item?id=25210475
- sneak 6y ago
  I have no axe to grind with Apple. I'm a happy Apple customer and have been for most of 30 years. The same code that keeps malware from running on a mac (or iphone) keeps non-app-store apps from running on an iphone, or prompts you to move non-notarized apps to the trash on a mac. It's not some separate thing: the exact same code path that protects the consumer store revenue and developer notarization service revenue also protects users against malware. EDIT, for clarity: I am speaking of Apple-developed, Apple-owned platform security code, where root keys are not held by anyone other than Apple, not generic crypto primitives or the concept of code signing in general (where we have a P-as-in-public PKI).
  - Spivak 6y ago
    Which is the same code that keeps unsigned bootloaders from running on PCs which is the same code that keeps unsigned packages from being installed on Linux systems which is the same code that keeps unsigned browser extensions from running on Firefox which is the same code that shows the scary warning on Windows. Everyone seems to like code signing.
    - novok 6y ago
      Lol you have never had to deal with apple's over complicated code signing as a developer. Adds a lot of wrenches when your just trying to do basic stuff like codesign and push test builds onto a USB connected device from a bash script and it is flaky and undocumented as fuck. I am honestly jealous of my android counterparts with their far simpler system and first class command line support via adb.

shawnz 6y ago

I agree that there is no direct evidence that this decision was part of their formal decision-making process. But there is still something to be said for designing systems where it's not possible for those negative incentives to exist, whether or not there is any current intention of taking advantage of them. Of the tens of thousands of people who had a hand in shaping macOS today, it's impossible to say what their collective intentions were in all the decisions they made. So I think it's useless to talk only about the intentions you can prove just by looking at their formal decision-making process. That is why we need to be working to protect privacy at every level with a "defense in depth" approach. And of course it goes without saying that all major vendors have issues like this and could be working harder to make sure that these incentives don't get created.

shadowfiend 6y ago
> designing systems where it's not possible for those negative incentives to exist No doubt, but even in simple systems this is considerably more difficult than it sounds. Incentive systems are not easy, and any incentive system is often twisted into a game that produces unexpected poor behaviors. Try to achieve that at a 100+k employee company and you're guaranteed to end up with misaligned or counterintuitive incentives. The reason something stronger than simple assertion matters here is because Apple actually has added an incentive system: trumpeting privacy as a core feature means they tie their brand to their ability to deliver on privacy. That means that being called out for privacy issues has greater potential harm for the company, and thus its bottom line, in a way that's far more direct and monetarily impactful than $100 annual developer fees ever will be. Even cynically, you can see the same mechanic at work with the recent reduction of app store percentages for small businesses. Apple has made it a core part of its developer outreach that the app store is a good thing for developers: they've made it part of their brand. If they're called out for something that makes many of those developers disagree, or even for something that makes users perceive that part of the brand as incorrect, it has implications to the whole company's bottom line (not just the developer id sliver of it). > it's useless to talk only about the intentions you can prove just by looking at their formal decision-making process For what it's worth, my point isn't tied to formal decision-making, it's tied to the informal parts as well. What I'm saying is that this can be a completely technical decision that relies on the existing business structure without ever taking into account whether it will raise revenue from developer ids. The developer id's existence is a fact. The “DoS resistance” characteristics, if you will, of having the developer ids cost money is a fact. As a system architect, leveraging those facts for system security seems perfectly reasonable. Yes, absolutely they should have taken privacy into account as well. “We haven't used it” and “we won't use it” aren't the same as “we can't use it”. But here's the thing: to me, the strongest indicator of whether a company is committed to an approach is whether they react positively when they are called out, or whether they double down on their mistakes. Apple was called out here, and they've committed to doing just about all of the things they should be doing. You could use this same framing to say that Apple isn't as committed to developers thriving on their platform as they are to living up to their privacy commitment, of course. Tl;dr: customers are part of the incentive system, tying your brand to a commitment aggressively as Apple has tied theirs to privacy has an impact on customers, and this is a great way to introduce an additional external forcing function to your internal teams.