8 ms·

If you use it and want to develop for it, you can't really whine about how they do things and want to do things differently as an "act of protest" -- you either

If you use it and want to develop for it, you can't really whine about how they do things and want to do things differently as an "act of protest" -- you either pay the money to do it their way -- which massively reduces the amount of trash apps on the App Store, and helps increase user trust compared to random apps being able to open and do what they want without warning -- or you accept your potential users won't have that simplicity. If you love the hardware and the integration, and have the money, what exactly is your issue? -- if you were about FLOSS more than anything you wouldn't be pushing the proprietary platform stuff to begin with, and if you don't like the "walled garden" approach you shouldn't be using Apple ¯\_(ツ)_/¯ The same things apply to the Microsoft Store for apps, and similar (but to a much lesser degree) for the likes of the Ubuntu Software Center. It's about trust, ease of use, and having apps and updates all handleable from one location. If you're distributing the app yourself, outwith the App Store, you don't have any of those "dependencies" -- and if your complaint is paying to have your code signed properly as a dev, that's the same across macOS and Windows, in a similar vein to SSL certs for websites. Sure, you can work without it, but you're going to alienate and scare some users by doing so.

grishka 4y ago
> if you don't like the "walled garden" approach you shouldn't be using Apple But I use none of Apple's online services. Not even the app store. App store for me is the place to update Apple apps, and that's really it. > and if your complaint is paying to have your code signed properly as a dev, that's the same across macOS and Windows, Windows? I know you can sign Windows executables, but why would anyone want to? I have Windows 11 on a VM. It runs unsigned executables just fine and, unlike macOS, doesn't treat them like they're radioactive. You just get a differently-colored confirmation window if you run them as administrator. > in a similar vein to SSL certs for websites And before Let's Encrypt and other similar free automatic CAs came along, SSL/TLS was very niche. See, it's about choice. If you want to throw your money away for some reason, sure you can still pay for an SSL certificate. Or you can use Let's Encrypt for free, set it up once and forget. Your users would see a lock icon either way. No such luck with macOS app signing — Apple is your only option. I like Android's security model better. You sign your apk with a self-signed certificate. No signing identity is enforced upon initial installation, but if you release an update, the new apk has to be signed with the same certificate. You can install an apk with the same package id but a different signature only after you uninstall the previous one (and delete all its private data). This helps with security and data integrity. I see no reason why Apple couldn't adopt a similar scheme on their platforms, except that they want all control they could get away with.
- sbuk 4y ago
  > Windows? I know you can sign Windows executables, but why would anyone want to? I have Windows 11 on a VM. It runs unsigned executables just fine and, unlike macOS, doesn't treat them like they're radioactive. You just get a differently-colored confirmation window if you run them as administrator. It ought to! I'd love to see this in Linux and the BSD's too. Signing applications and binaries should be the norm. > And before Let's Encrypt and other similar free automatic CAs came along, SSL/TLS was very niche. Let's Encrypt came about to help with security. Happy to hear arguments pro a similar service for application signing, but it will have to follow similar, or tighter restrictions and you'd still be at the whim of third party. > I like Android's security model better. You sign your apk with a self-signed certificate. That is most definitely not a security policy. Self-signing is no different to not signing at all. There is no provenance, no chain-of-trust.
  - 0ct4via 4y ago
    Absolutely this.
  - grishka 4y ago
    > There is no provenance, no chain-of-trust. We should've probably started with the fact that I despise security policies based on provenance, chains of trust, public key infrastructure, and third parties. This kind of "security" feels extremely fragile and unnecessarily centralized. We somehow live with how SSH identifies servers by their keys, with no third-party verification, and consider that an okay level of security. Why can't we use the same approach for TLS and for executable signatures? What's so fundamentally different that third parties are required in these cases?
    - sbuk 4y ago
      SSH doesn’t rely on PKI. Using SSH certificates is a password replacement for accessing remote services. While it is a kind of identity verification, its purpose is not the same an application signing. Self signing is open to too much abuse. The whole point of signing is that the provenance can be verified (yes, checksums are a thing) and that the signing can be revoked should something bad happen. Notarising code is the process of a third party verifying your identity. So rather than saying, “hey, you can trust me”, you are asking a third party to vet and prove that you are trustworthy. If you can’t see the value in that for all parties - including the most important party, your customers - then that’s up to you. No sane SOC will allow unsigned or self-signed binaries. Consumers with the slightest bit of savvy will not run unsigned or self-signed binaries, and OS vendors need to take care of the rest. Thinking of the Confidentiality, Integrity and Availability triad, your solution is unworkable.

grishka 4y ago

> if you don't like the "walled garden" approach you shouldn't be using Apple But I use none of Apple's online services. Not even the app store. App store for me is the place to update Apple apps, and that's really it. > and if your complaint is paying to have your code signed properly as a dev, that's the same across macOS and Windows, Windows? I know you can sign Windows executables, but why would anyone want to? I have Windows 11 on a VM. It runs unsigned executables just fine and, unlike macOS, doesn't treat them like they're radioactive. You just get a differently-colored confirmation window if you run them as administrator. > in a similar vein to SSL certs for websites And before Let's Encrypt and other similar free automatic CAs came along, SSL/TLS was very niche. See, it's about choice. If you want to throw your money away for some reason, sure you can still pay for an SSL certificate. Or you can use Let's Encrypt for free, set it up once and forget. Your users would see a lock icon either way. No such luck with macOS app signing — Apple is your only option. I like Android's security model better. You sign your apk with a self-signed certificate. No signing identity is enforced upon initial installation, but if you release an update, the new apk has to be signed with the same certificate. You can install an apk with the same package id but a different signature only after you uninstall the previous one (and delete all its private data). This helps with security and data integrity. I see no reason why Apple couldn't adopt a similar scheme on their platforms, except that they want all control they could get away with.

sbuk 4y ago
> Windows? I know you can sign Windows executables, but why would anyone want to? I have Windows 11 on a VM. It runs unsigned executables just fine and, unlike macOS, doesn't treat them like they're radioactive. You just get a differently-colored confirmation window if you run them as administrator. It ought to! I'd love to see this in Linux and the BSD's too. Signing applications and binaries should be the norm. > And before Let's Encrypt and other similar free automatic CAs came along, SSL/TLS was very niche. Let's Encrypt came about to help with security. Happy to hear arguments pro a similar service for application signing, but it will have to follow similar, or tighter restrictions and you'd still be at the whim of third party. > I like Android's security model better. You sign your apk with a self-signed certificate. That is most definitely not a security policy. Self-signing is no different to not signing at all. There is no provenance, no chain-of-trust.
- 0ct4via 4y ago
  Absolutely this.
- grishka 4y ago
  > There is no provenance, no chain-of-trust. We should've probably started with the fact that I despise security policies based on provenance, chains of trust, public key infrastructure, and third parties. This kind of "security" feels extremely fragile and unnecessarily centralized. We somehow live with how SSH identifies servers by their keys, with no third-party verification, and consider that an okay level of security. Why can't we use the same approach for TLS and for executable signatures? What's so fundamentally different that third parties are required in these cases?
  - sbuk 4y ago
    SSH doesn’t rely on PKI. Using SSH certificates is a password replacement for accessing remote services. While it is a kind of identity verification, its purpose is not the same an application signing. Self signing is open to too much abuse. The whole point of signing is that the provenance can be verified (yes, checksums are a thing) and that the signing can be revoked should something bad happen. Notarising code is the process of a third party verifying your identity. So rather than saying, “hey, you can trust me”, you are asking a third party to vet and prove that you are trustworthy. If you can’t see the value in that for all parties - including the most important party, your customers - then that’s up to you. No sane SOC will allow unsigned or self-signed binaries. Consumers with the slightest bit of savvy will not run unsigned or self-signed binaries, and OS vendors need to take care of the rest. Thinking of the Confidentiality, Integrity and Availability triad, your solution is unworkable.