4 ms·

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 describe

by 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]

by xp84 3y ago

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]