3 ms·

Came here to say this. Custom webviews like Facebook likes to use are another matter but SFSafariViewController is for all intents and purposes real Safari with

Came here to say this. Custom webviews like Facebook likes to use are another matter but SFSafariViewController is for all intents and purposes real Safari with per-app cookies, storage, etc to bust tracking. And I have to say, I would be pretty irritated if every site demanded to open in my main browser. Many if not most links I tap are quick one and dones I’d prefer to not clutter up my tabs.

seandoe 4y ago
I disagree. If it's a link to the web, I want my main, default browser everytime. No exceptions. The context switching is never an issue for me. App browsers screw up magic links too. I wish they'd go away.
- hmcamp 4y ago
  I agree. I’d prefer the exploit choice to have the link open in my default browser.
danboarder 4y ago
Perhaps it can be an option to check: "Always open websites in your default browser".
- monkpit 4y ago
  Funny thing - the Gmail app has this prompt on the iPhone buy it never remembers my preference. It asks me every time even when I tell it not to.
  - rafram 4y ago
    If it’s like the one in Google Maps, it’s just an ad for Chrome. Chrome shows in the list whether or not it’s installed, with an option to get it from the App Store.
  - hackmiester 4y ago
    I bet if you selected Chrome it would remember it.
- modeless 4y ago
  Many apps have this setting but some don't. When they do it is invariably buried in the most inconvenient and hard to find place, different in every app, named something non-obvious, moved every year or so when some PM decides that the settings screen needs rearranging, and it is never synced or saved so you have to set it separately on every device and again whenever you get a new device, in every app. I wish there was an OS level setting.
  - kelnos 4y ago
    Hell, I remember that both Facebook and Instagram used to have this setting! I uninstalled both of them quite some time ago, but I assume from the gripes in the article that this option has been removed.
sneak 4y ago
Why shouldn't clicking a link open your browser application? It's done that the entire history of the web and computing. Embedding a browser in apps to try to keep users "engaged with your brand" after they have already clicked a link to leave for the web is a new thing and is erroneous. Why would you be irritated that clicking a web link opens the link in the browser? That's what's supposed to happen.
- kitsunesoba 4y ago
  Because I don't necessarily want the link I'm visiting cluttering my history and tabs, and I probably don't want the site in question to have access to my cookies and whatnot. It's much more likely that I'll check out random links in apps (HN client, reddit, twitter, etc) if I know SFSafariViewController will be there to act as a wall between the visited site and my primary browsing setup. The only thing I can see acting as a replacement is iOS offering to open links from external apps in a private browsing tab instead of a regular one.
  - kelnos 4y ago
    > * probably don't want the site in question to have access to my cookies and whatnot* Er, why not? Sites don't get access to any random old cookie, they get access to cookies they themselves have set before (more or less). Why should a tap from a native app be any different wrt cookie access than if you navigated to the site yourself in the web browser?
    - MaxBarraclough 4y ago
      > Sites don't get access to any random old cookie, they get access to cookies they themselves have set before (more or less). Well, kinda. Remember Facebook are able to track people around the web using their famous embedded Like button. This happens regardless of whether the button is clicked. This is unfortunately under-reported, so I'll make do with linking to, of all places, BuzzFeed: https://www.buzzfeednews.com/article/alexkantrowitz/heres-how-facebook-tracks-you-when-youre-not-on-facebook https://www.buzzfeednews.com/article/alexkantrowitz/heres-ho...
derefr 4y ago
> And I have to say, I would be pretty irritated if every site demanded to open in my main browser. Many if not most links I tap are quick one and dones I’d prefer to not clutter up my tabs. Sure, but why does that have to imply that you get "per-app cookies, storage, etc"? What I want is a Safari tab as a modal temporarily overlaying the app. It is a tab of my regular web browser, with access to my regular web-browsing profile, and without the app having access to it any more than the app would have access to a tab it caused to open in regular Safari — except that 1. it doesn't show up in Safari's tabs, only as a window "stuck on top of" the particular app; and 2. the window knows what it's displaying is ephemeral, so it's easy to close it and return to the app by just swiping it away. (A lot like the Safari long-press preview modal, actually.) Basically, SFSafariViewController should work less like an isolated browsing session, and more like the way OS file-pickers work in desktop OSes — where the UI-as-client makes a synchronous request to another app-as-IPC-server to pop a window, and then blocks until that window goes away.
- kitsunesoba 4y ago
  I do agree that SFSafariViewController should use the newer style of sheet that can be pulled down on to be be dismissed. It makes more sense than the current navigation stack style presentation, and the extra context of the spawning app being visible around the top edges under the sheet would be helpful in app switcher. The reason SFSafariViewController switched to per-app containers is because the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes, dampening the benefits of it being out-of-process and isolated from the spawning application. I suppose it might be nice to have a setting to toggle this behavior, but it'd need to have disclaimers with red text next to it to prevent advertisers, etc social engineering users into toggling modes.
  - derefr 4y ago
    > the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes How did this work, exactly? Was the app able to observe/interact with the SFSafariViewController in any way? In my mind, the SFSafariViewController should literally "be" a Safari tab, in the sense that once it's open, the spawning app has no more connection to it than it would have to a tab in Safari itself which it caused to open; other than the fact that this tab would be 1. modal on top of the app, like a sheet; and 2. the app would be told when you closed this sheet, so that it could pause anything actively going on "underneath" the sheet until it was closed. (And, to be clear, the Safari tab would be running _in_ Safari, and just composited onto the sheet, rather than running inside the app process in any way. This is how OS file-pickers et al work, which is what I was trying to get across with that comparison.) The closest analogy would actually be within the browser itself: one browser tab using JS window.open(target=_blank, opener=false) to open another browser tab within the same browsing profile, where the new tab loads a page from a different origin; where when that new tab gets focused, the original tab gets obscured, and so the page it has loaded is given a visibilityStateChanged event; followed by another one when you close the new tab and the original tab comes back to focus.
kelnos 4y ago
Why should this clutter up your tabs, though? Hitting the back button/making the back gesture should (given a sane implementation) close the tab and return you to the native app where you clicked the link, no?
- josephg 4y ago
  This already happens when apps open links in safari. There’s a little back button in the top left of the screen to go back to the app which opened that webpage.
  - benhurmarcel 4y ago
    This doesn't close the tab though.
liminvorous 4y ago
On the other hand I am almost always annoyed at apps opening websites in SFSafariViewController, and would prefer to be able to completely disable it and have it always open in the real browser.
- deleted 4y ago
  [deleted]

seandoe 4y ago

I disagree. If it's a link to the web, I want my main, default browser everytime. No exceptions. The context switching is never an issue for me. App browsers screw up magic links too. I wish they'd go away.

hmcamp 4y ago
I agree. I’d prefer the exploit choice to have the link open in my default browser.

danboarder 4y ago

Perhaps it can be an option to check: "Always open websites in your default browser".

monkpit 4y ago
Funny thing - the Gmail app has this prompt on the iPhone buy it never remembers my preference. It asks me every time even when I tell it not to.
- rafram 4y ago
  If it’s like the one in Google Maps, it’s just an ad for Chrome. Chrome shows in the list whether or not it’s installed, with an option to get it from the App Store.
- hackmiester 4y ago
  I bet if you selected Chrome it would remember it.
modeless 4y ago
Many apps have this setting but some don't. When they do it is invariably buried in the most inconvenient and hard to find place, different in every app, named something non-obvious, moved every year or so when some PM decides that the settings screen needs rearranging, and it is never synced or saved so you have to set it separately on every device and again whenever you get a new device, in every app. I wish there was an OS level setting.
- kelnos 4y ago
  Hell, I remember that both Facebook and Instagram used to have this setting! I uninstalled both of them quite some time ago, but I assume from the gripes in the article that this option has been removed.

sneak 4y ago

Why shouldn't clicking a link open your browser application? It's done that the entire history of the web and computing. Embedding a browser in apps to try to keep users "engaged with your brand" after they have already clicked a link to leave for the web is a new thing and is erroneous. Why would you be irritated that clicking a web link opens the link in the browser? That's what's supposed to happen.

kitsunesoba 4y ago
Because I don't necessarily want the link I'm visiting cluttering my history and tabs, and I probably don't want the site in question to have access to my cookies and whatnot. It's much more likely that I'll check out random links in apps (HN client, reddit, twitter, etc) if I know SFSafariViewController will be there to act as a wall between the visited site and my primary browsing setup. The only thing I can see acting as a replacement is iOS offering to open links from external apps in a private browsing tab instead of a regular one.
- kelnos 4y ago
  > * probably don't want the site in question to have access to my cookies and whatnot* Er, why not? Sites don't get access to any random old cookie, they get access to cookies they themselves have set before (more or less). Why should a tap from a native app be any different wrt cookie access than if you navigated to the site yourself in the web browser?
  - MaxBarraclough 4y ago
    > Sites don't get access to any random old cookie, they get access to cookies they themselves have set before (more or less). Well, kinda. Remember Facebook are able to track people around the web using their famous embedded Like button. This happens regardless of whether the button is clicked. This is unfortunately under-reported, so I'll make do with linking to, of all places, BuzzFeed: https://www.buzzfeednews.com/article/alexkantrowitz/heres-how-facebook-tracks-you-when-youre-not-on-facebook https://www.buzzfeednews.com/article/alexkantrowitz/heres-ho...

derefr 4y ago

> And I have to say, I would be pretty irritated if every site demanded to open in my main browser. Many if not most links I tap are quick one and dones I’d prefer to not clutter up my tabs. Sure, but why does that have to imply that you get "per-app cookies, storage, etc"? What I want is a Safari tab as a modal temporarily overlaying the app. It is a tab of my regular web browser, with access to my regular web-browsing profile, and without the app having access to it any more than the app would have access to a tab it caused to open in regular Safari — except that 1. it doesn't show up in Safari's tabs, only as a window "stuck on top of" the particular app; and 2. the window knows what it's displaying is ephemeral, so it's easy to close it and return to the app by just swiping it away. (A lot like the Safari long-press preview modal, actually.) Basically, SFSafariViewController should work less like an isolated browsing session, and more like the way OS file-pickers work in desktop OSes — where the UI-as-client makes a synchronous request to another app-as-IPC-server to pop a window, and then blocks until that window goes away.

kitsunesoba 4y ago
I do agree that SFSafariViewController should use the newer style of sheet that can be pulled down on to be be dismissed. It makes more sense than the current navigation stack style presentation, and the extra context of the spawning app being visible around the top edges under the sheet would be helpful in app switcher. The reason SFSafariViewController switched to per-app containers is because the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes, dampening the benefits of it being out-of-process and isolated from the spawning application. I suppose it might be nice to have a setting to toggle this behavior, but it'd need to have disclaimers with red text next to it to prevent advertisers, etc social engineering users into toggling modes.
- derefr 4y ago
  > the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes How did this work, exactly? Was the app able to observe/interact with the SFSafariViewController in any way? In my mind, the SFSafariViewController should literally "be" a Safari tab, in the sense that once it's open, the spawning app has no more connection to it than it would have to a tab in Safari itself which it caused to open; other than the fact that this tab would be 1. modal on top of the app, like a sheet; and 2. the app would be told when you closed this sheet, so that it could pause anything actively going on "underneath" the sheet until it was closed. (And, to be clear, the Safari tab would be running _in_ Safari, and just composited onto the sheet, rather than running inside the app process in any way. This is how OS file-pickers et al work, which is what I was trying to get across with that comparison.) The closest analogy would actually be within the browser itself: one browser tab using JS window.open(target=_blank, opener=false) to open another browser tab within the same browsing profile, where the new tab loads a page from a different origin; where when that new tab gets focused, the original tab gets obscured, and so the page it has loaded is given a visibilityStateChanged event; followed by another one when you close the new tab and the original tab comes back to focus.

kelnos 4y ago

Why should this clutter up your tabs, though? Hitting the back button/making the back gesture should (given a sane implementation) close the tab and return you to the native app where you clicked the link, no?

josephg 4y ago
This already happens when apps open links in safari. There’s a little back button in the top left of the screen to go back to the app which opened that webpage.
- benhurmarcel 4y ago
  This doesn't close the tab though.

liminvorous 4y ago

On the other hand I am almost always annoyed at apps opening websites in SFSafariViewController, and would prefer to be able to completely disable it and have it always open in the real browser.

deleted 4y ago
[deleted]