3 ms·

I don't have a problem with seeking consent from the user, and that's exactly what Firebase Dynamic Links offered by including "Check to continue my place in th

by asow92 3y ago

I don't have a problem with seeking consent from the user, and that's exactly what Firebase Dynamic Links offered by including "Check to continue my place in the app" on by default, but that product is no more thanks to Apple. Consent is given on the webpage before going to the App Store. My issue is with Apple acting as the arbiters of what consent looks like. You have to consent with the flow to go through with it, right? Nobody's forcing our users to continue. And like I have already said, it's not like we can't do what you're suggesting. In fact, we have, but that equates to more churn in our flows because users get confused or are fatigued by the amount of hoops they have to jump through to make the product work, which was my original point to this whole thread.

eropple 3y ago
Ground truth, inviolate: the OS owns the trust relationship with the user. The OS may allow the extension of that trust relationship (MDM, custom TLS roots, etc.) but that's informing the OS's own authorization, it's not supplanting it. It follows, then, Apple is the arbiter of consent on an iOS device because they own the OS (the user has chosen to, by buying an iOS device, grant the authorizee's part of the trust relationship). Apple does not have a trusted relationship with you, the software developer. And Apple doesn't know about a trust relationship between the user and the software developer until the OS sees confirmation from the user. It then follows that consent must be given at or inside the security boundary to be provable; the web page you refer to is outside of it. You are asking to move from a less trusted environment (a web browser, generally watched like a hawk) to a more trusted environment (an application, with additional implicit permissions and the explicit ability to ask for others). That isn't a decision you are allowed to make and it isn't something that, for all Apple knows, you confused-deputy'd your way around a user's affirmatively consenting to. It's turtles all the way down. You have to acquire consent at a trustable level. That means the OS or, if the OS isn't sure, the user themselves, through an OS-verifiable method. Sorry that your third-party vendor doesn't count, but it shouldn't. "Just trust me" isn't security. "But nobody cares" might be next up, so let's settle that now: nobody cares because they pay Apple to care for them.
- asow92 3y ago
  > Apple does not have a trusted relationship with you, the software developer. Yeah, they do, because they have to trust the certificates and entitlements that my app is signed with. All I'm asking for is an extension of that same idea to other parts of the app experience. I just don't think we're going to agree on this, and that's fine. Care to call it a day and we can respectfully both walk away?
  - deleted 3y ago
    [deleted]
  - Kamq 3y ago
    > Yeah, they do, because they have to trust the certificates and entitlements that my app is signed with. That's a 401 vs 403 distinction. They know who you are, they don't know that you're authorized to do this.
    - asow92 3y ago
      I get what you’re saying but have to disagree because it’s kind of different. Apple has to review our apps before they’re released and they certainly have capability to review a trusted pasteboard copying predicate as I am suggesting. They would have the authority to revoke it at any time and I would certainly not want to risk my developer account being put into jeopardy by breaking their trust.
      - Kamq 3y ago
        > Apple has to review our apps before they’re released and they certainly have capability to review a trusted pasteboard copying predicate as I am suggesting. Are you willing to provide signed proof that the user consented to this action? The same way you provide signed code to prove you're the one uploading the code. Presumably this would have to be via a key that you don't have access to (only the user would be able to consent to this). Because that seems like the parallel here. Technically, apple should be auditing your flows at that point too, to make sure there aren't any dark patterns. But, yeah, at that point, I think you could make that argument stick.

by asow92 3y ago

eropple 3y ago

Ground truth, inviolate: the OS owns the trust relationship with the user. The OS may allow the extension of that trust relationship (MDM, custom TLS roots, etc.) but that's informing the OS's own authorization, it's not supplanting it. It follows, then, Apple is the arbiter of consent on an iOS device because they own the OS (the user has chosen to, by buying an iOS device, grant the authorizee's part of the trust relationship). Apple does not have a trusted relationship with you, the software developer. And Apple doesn't know about a trust relationship between the user and the software developer until the OS sees confirmation from the user. It then follows that consent must be given at or inside the security boundary to be provable; the web page you refer to is outside of it. You are asking to move from a less trusted environment (a web browser, generally watched like a hawk) to a more trusted environment (an application, with additional implicit permissions and the explicit ability to ask for others). That isn't a decision you are allowed to make and it isn't something that, for all Apple knows, you confused-deputy'd your way around a user's affirmatively consenting to. It's turtles all the way down. You have to acquire consent at a trustable level. That means the OS or, if the OS isn't sure, the user themselves, through an OS-verifiable method. Sorry that your third-party vendor doesn't count, but it shouldn't. "Just trust me" isn't security. "But nobody cares" might be next up, so let's settle that now: nobody cares because they pay Apple to care for them.

asow92 3y ago
> Apple does not have a trusted relationship with you, the software developer. Yeah, they do, because they have to trust the certificates and entitlements that my app is signed with. All I'm asking for is an extension of that same idea to other parts of the app experience. I just don't think we're going to agree on this, and that's fine. Care to call it a day and we can respectfully both walk away?
- deleted 3y ago
  [deleted]
- Kamq 3y ago
  > Yeah, they do, because they have to trust the certificates and entitlements that my app is signed with. That's a 401 vs 403 distinction. They know who you are, they don't know that you're authorized to do this.
  - asow92 3y ago
    I get what you’re saying but have to disagree because it’s kind of different. Apple has to review our apps before they’re released and they certainly have capability to review a trusted pasteboard copying predicate as I am suggesting. They would have the authority to revoke it at any time and I would certainly not want to risk my developer account being put into jeopardy by breaking their trust.
    - Kamq 3y ago
      > Apple has to review our apps before they’re released and they certainly have capability to review a trusted pasteboard copying predicate as I am suggesting. Are you willing to provide signed proof that the user consented to this action? The same way you provide signed code to prove you're the one uploading the code. Presumably this would have to be via a key that you don't have access to (only the user would be able to consent to this). Because that seems like the parallel here. Technically, apple should be auditing your flows at that point too, to make sure there aren't any dark patterns. But, yeah, at that point, I think you could make that argument stick.