6 ms·

It's been a while, so correct me if I'm wrong, but a "Share -> Copy" action doesn't require permissions, does it? That's the conventional way to do this in Appl

It's been a while, so correct me if I'm wrong, but a "Share -> Copy" action doesn't require permissions, does it? That's the conventional way to do this in Apple's own apps and a user should be able to be expected to follow that if they want to copy a link. (Doing otherwise would be nonstandard and surprising to me, regardless.) Otherwise, accessing UIPasteboard should require permissions. Sorry for Your Flow, but like--the app needs to be transparent about what it's doing, and dirtbags exist, so.

asow92 3y ago
While that works, it's not very user friendly, and that means friction, and friction means churn, and churn means a sad boss. It makes obvious sense to us, but gramma or your luddite uncle have a hard time with that. They need to be redirected (handheld) to where they're going.
- eropple 3y ago
  It absolutely does, and I'm sure your boss doesn't like to hear it, but falling out of your flow is a pretty small price to pay for somebody else not being able to scrape Grandma's credit card off the pasteboard. I want my tech-averse relatives to bail out of an app when they see that unless they're hand-held through it and the reasoning is made sufficiently apparent that they can parse it. If they can't, it's not clear enough, and they (and the OS) should default to no.
  - marcos100 3y ago
    Exactly! Gramma and my luddite uncle are the most vulnerable to whatever bad actors want to do.
  - 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??!"

asow92 3y ago

While that works, it's not very user friendly, and that means friction, and friction means churn, and churn means a sad boss. It makes obvious sense to us, but gramma or your luddite uncle have a hard time with that. They need to be redirected (handheld) to where they're going.

eropple 3y ago
It absolutely does, and I'm sure your boss doesn't like to hear it, but falling out of your flow is a pretty small price to pay for somebody else not being able to scrape Grandma's credit card off the pasteboard. I want my tech-averse relatives to bail out of an app when they see that unless they're hand-held through it and the reasoning is made sufficiently apparent that they can parse it. If they can't, it's not clear enough, and they (and the OS) should default to no.
- marcos100 3y ago
  Exactly! Gramma and my luddite uncle are the most vulnerable to whatever bad actors want to do.
- 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??!"