3 ms·

_My_ flow, was the same flow shared by anyone else who used Firebase Dynamic Links, Adjust Links, and many others. I'm not alone in this. There has to be a com

by asow92 3y ago

_My_ flow, was the same flow shared by anyone else who used Firebase Dynamic Links, Adjust Links, and many others. I'm not alone in this. There has to be a common sense compromise on this, like a revokable certificate for access without a prompt. I completely reject your whole premise.

eropple 3y ago
> _My_ flow, was the same flow shared by anyone else who used Firebase Dynamic Links, Adjust Links, and many others. I'm not alone in this. No, you're not. And that's good. It's a bad pattern! It's a bad pattern whether one app or a million use it. > There has to be a common sense compromise on this, like a revokable certificate for access without a prompt. You seem to think this is the extreme position, and it's not. The extreme position is "you cannot access the pasteboard directly, at all, under any circumstances, and only user-triggered actions through OS-served and unintermediated controls can do so." You have your compromise already: "ask for permission and be sufficiently clear about why you want it to get people to say yes". > I completely reject your whole premise. That's fine. Apple doesn't. That's why I like them. You started this thread with what sounded like a reasonable objection, but you've kept digging to the point where it sounds like you're kind of the reason they're doing it.
- asow92 3y ago
  Agree to disagree, but thanks for your time.
- xp84 3y ago
  While you seem to believe the person you’re arguing with wants that API to do scummy things, it would be more fair to acknowledge that the feature they described is a workaround for the poorly-designed way apps open on first launch. Being able to offer a user an “install and open this in-app” is an incredibly common feature that everyone who has a website and an app wants, and Apple could easily enable this, for instance, by allowing the app to ask the OS to prompt the user for consent “to continue where you left off on the web?” (“Insert Title from Most Recently Used Safari Tab matching this app’s registered website domain here”) Consent -> OS provides that tab’s URL to the app as though the user had clicked a Universal Link No Consent -> do nothing
  - danaris 3y ago
    > While you seem to believe the person you’re arguing with wants that API to do scummy things It doesn't seem like they do believe that, and even if they did, that's not the point. The point is that allowing this access without explicit user consent enables various "scummy things" that neither Apple nor the user can then stop or easily detect. It's really not that different from the person at the bank saying, "But you know it's me! Why can't you give me all my money without seeing my ID??!"
    - xp84 3y ago
      No dispute there. My only point was that that commenter doesn't even actually WANT the user's clipboard. What they want is to let the user consent to resuming the activity/state they were doing on the Web in a freshly-downloaded native app. Apple half-assed this with those little metatag-based banner things, which function great (passing the current web URL to the native app with a tap) when you already have the app, but if you don't have the app, or if you want to use a UI other than that persistent banner, the best you can do is send them to the app store and hope they find their own way. This is a poor experience, and the fact that developers resorted to the clipboard method is at Apple's feet because they didn't make any effort to solve the problem, which they could easily do in a secure, consent-asking way.
      - asow92 3y ago
        Thank you for understanding :+1:
    - eropple 3y ago
      Exactly. The threat model doesn't care what somebody says their intentions are.
  - deleted 3y ago
    [deleted]
TechBro8615 3y ago
And what happens when there's a vulnerability in that SDK and every app using it for "their flow" is suddenly vulnerable to attackers scraping sensitive data from the pasteboard of their users? Or what if one of the dozen other SDKs you bundle in your app includes malicious code that takes advantage of the fact you already enabled the pasteboard API for another SDK? As a developer, I sympathize with you, but as a user, you can get bent. I appreciate that Apple makes it difficult for you to use potentially dangerous APIs with large risk surfaces, and forces you to ask me for permission to take that risk. It's why I continue to buy Apple products and will never switch to Android as long as it's owned by a user-hostile advertising company.
- asow92 3y ago
  The only thing I’m reading from your pasteboard is a routing path that I’ve put there from my webpage, so what’s the risk exactly?
  - TechBro8615 3y ago
    A vulnerability in your SDK that lets a malicious actor control when something is read from the pasteboard. Or a bug in your code that forgets to place the route on the clipboard and ends up reading the previous item from the clipboard and attempting to load it on your server (i.e. sending user clipboard data to your server). And besides, beyond the issue of risk mitigation or code security, there's also that of trust - why should I trust that you're only using clipboard access for the claimed purpose, and why should I trust you implemented and tested your code correctly?
    - asow92 3y ago
      Your concern isn’t addressed by Apple’s solution to this. The user just agrees or disagrees and it’s a black box as to what happens after that.
      - TechBro8615 3y ago
        It's addressed by Apple's permission prompt that allows me to select the "ask every time" option. You're right that it's a black box after that in terms of whether or not the app puts a new item on my clipboard and then reads it (why would it need to do that?), but at least I know that if I have something sensitive at the top of my clipboard then I can decline the prompt. That's not to mention that my concern is fundamentally addressed by gating clipboard access behind a prompt in the first place. That is, I always have the option to decline the permission entirely.

by asow92 3y ago

eropple 3y ago

> _My_ flow, was the same flow shared by anyone else who used Firebase Dynamic Links, Adjust Links, and many others. I'm not alone in this. No, you're not. And that's good. It's a bad pattern! It's a bad pattern whether one app or a million use it. > There has to be a common sense compromise on this, like a revokable certificate for access without a prompt. You seem to think this is the extreme position, and it's not. The extreme position is "you cannot access the pasteboard directly, at all, under any circumstances, and only user-triggered actions through OS-served and unintermediated controls can do so." You have your compromise already: "ask for permission and be sufficiently clear about why you want it to get people to say yes". > I completely reject your whole premise. That's fine. Apple doesn't. That's why I like them. You started this thread with what sounded like a reasonable objection, but you've kept digging to the point where it sounds like you're kind of the reason they're doing it.

asow92 3y ago
Agree to disagree, but thanks for your time.
xp84 3y ago
While you seem to believe the person you’re arguing with wants that API to do scummy things, it would be more fair to acknowledge that the feature they described is a workaround for the poorly-designed way apps open on first launch. Being able to offer a user an “install and open this in-app” is an incredibly common feature that everyone who has a website and an app wants, and Apple could easily enable this, for instance, by allowing the app to ask the OS to prompt the user for consent “to continue where you left off on the web?” (“Insert Title from Most Recently Used Safari Tab matching this app’s registered website domain here”) Consent -> OS provides that tab’s URL to the app as though the user had clicked a Universal Link No Consent -> do nothing
- danaris 3y ago
  > While you seem to believe the person you’re arguing with wants that API to do scummy things It doesn't seem like they do believe that, and even if they did, that's not the point. The point is that allowing this access without explicit user consent enables various "scummy things" that neither Apple nor the user can then stop or easily detect. It's really not that different from the person at the bank saying, "But you know it's me! Why can't you give me all my money without seeing my ID??!"
  - xp84 3y ago
    No dispute there. My only point was that that commenter doesn't even actually WANT the user's clipboard. What they want is to let the user consent to resuming the activity/state they were doing on the Web in a freshly-downloaded native app. Apple half-assed this with those little metatag-based banner things, which function great (passing the current web URL to the native app with a tap) when you already have the app, but if you don't have the app, or if you want to use a UI other than that persistent banner, the best you can do is send them to the app store and hope they find their own way. This is a poor experience, and the fact that developers resorted to the clipboard method is at Apple's feet because they didn't make any effort to solve the problem, which they could easily do in a secure, consent-asking way.
    - asow92 3y ago
      Thank you for understanding :+1:
  - eropple 3y ago
    Exactly. The threat model doesn't care what somebody says their intentions are.
- deleted 3y ago
  [deleted]

TechBro8615 3y ago

And what happens when there's a vulnerability in that SDK and every app using it for "their flow" is suddenly vulnerable to attackers scraping sensitive data from the pasteboard of their users? Or what if one of the dozen other SDKs you bundle in your app includes malicious code that takes advantage of the fact you already enabled the pasteboard API for another SDK? As a developer, I sympathize with you, but as a user, you can get bent. I appreciate that Apple makes it difficult for you to use potentially dangerous APIs with large risk surfaces, and forces you to ask me for permission to take that risk. It's why I continue to buy Apple products and will never switch to Android as long as it's owned by a user-hostile advertising company.

asow92 3y ago
The only thing I’m reading from your pasteboard is a routing path that I’ve put there from my webpage, so what’s the risk exactly?
- TechBro8615 3y ago
  A vulnerability in your SDK that lets a malicious actor control when something is read from the pasteboard. Or a bug in your code that forgets to place the route on the clipboard and ends up reading the previous item from the clipboard and attempting to load it on your server (i.e. sending user clipboard data to your server). And besides, beyond the issue of risk mitigation or code security, there's also that of trust - why should I trust that you're only using clipboard access for the claimed purpose, and why should I trust you implemented and tested your code correctly?
  - asow92 3y ago
    Your concern isn’t addressed by Apple’s solution to this. The user just agrees or disagrees and it’s a black box as to what happens after that.
    - TechBro8615 3y ago
      It's addressed by Apple's permission prompt that allows me to select the "ask every time" option. You're right that it's a black box after that in terms of whether or not the app puts a new item on my clipboard and then reads it (why would it need to do that?), but at least I know that if I have something sensitive at the top of my clipboard then I can decline the prompt. That's not to mention that my concern is fundamentally addressed by gating clipboard access behind a prompt in the first place. That is, I always have the option to decline the permission entirely.