7 ms·

It looks like Twitter is using SFSafariViewController for their in-app browser. This is the system-recommended way of creating an in-app browser. It prevents th

It looks like Twitter is using SFSafariViewController for their in-app browser. This is the system-recommended way of creating an in-app browser. It prevents the embedding app (Twitter in this case) from reading website data and injecting JavaScript into the view. You can also break out of the session into Safari pretty trivially by hitting the Safari button in the lower right corner. Apps that implement a custom web browser using WKWebView (e.g. IG) are much worse and can do those nefarious things.

kitsunesoba 4y ago
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]
ocdtrekkie 4y ago
So it sounds like the solution here is to not cater to Open Web Advocacy's particular flavor of advocacy as the article prescribes, but in fact, prohibit apps from using any webview except the official one provided by the OS.
- kelnos 4y ago
  iOS already does this, and that hasn't solved the problem. The issue is that the system-provided webview (well, on iOS, one of the two of them) allows the native app full control over it. And on Android, that would mean Firefox couldn't use Gecko. Screw that.
  - ocdtrekkie 4y ago
    See: https://news.ycombinator.com/item?id=32419845 https://news.ycombinator.com/item?id=32419845 iOS does have a restricted/safe webview experience, it just currently permits more custom ones. The solution presumably is to ban those.
- the_gipsy 4y ago
  Why do you come to that conclusion? The users want to open links in their browser - no matter if the link is in an email, chat message, or in an app.
  - ocdtrekkie 4y ago
    That's a very large assumption, one I think is outright false considering the discussion I've read about this post. The issue is that apps are allowed to embed webviews to do malicious things.
    - the_gipsy 4y ago
      No, it's a large assumption that users want to open a link in an in-app browser. Why would they? On the other hand, there are clear motives for the app to keep users in the app as much as possible. Because the in-app browser in general is a degraded experience, for example being logged out of habitual websites, the user won't navigate the web as usual, and will soon return to the app. It's nothing but a dark pattern.
hamandcheese 4y ago
Either way I don’t want it and I don’t know why anyone would.
the_gipsy 4y ago
Still, apps do this against the interest of the user, to keep them inside their app. In some apps even if you find a setting that disables this "feature", they then don't open links not in my default browser (firefox) nor in safari, but chrome.

kitsunesoba 4y ago

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]

ocdtrekkie 4y ago

So it sounds like the solution here is to not cater to Open Web Advocacy's particular flavor of advocacy as the article prescribes, but in fact, prohibit apps from using any webview except the official one provided by the OS.

kelnos 4y ago
iOS already does this, and that hasn't solved the problem. The issue is that the system-provided webview (well, on iOS, one of the two of them) allows the native app full control over it. And on Android, that would mean Firefox couldn't use Gecko. Screw that.
- ocdtrekkie 4y ago
  See: https://news.ycombinator.com/item?id=32419845 https://news.ycombinator.com/item?id=32419845 iOS does have a restricted/safe webview experience, it just currently permits more custom ones. The solution presumably is to ban those.
the_gipsy 4y ago
Why do you come to that conclusion? The users want to open links in their browser - no matter if the link is in an email, chat message, or in an app.
- ocdtrekkie 4y ago
  That's a very large assumption, one I think is outright false considering the discussion I've read about this post. The issue is that apps are allowed to embed webviews to do malicious things.
  - the_gipsy 4y ago
    No, it's a large assumption that users want to open a link in an in-app browser. Why would they? On the other hand, there are clear motives for the app to keep users in the app as much as possible. Because the in-app browser in general is a degraded experience, for example being logged out of habitual websites, the user won't navigate the web as usual, and will soon return to the app. It's nothing but a dark pattern.

hamandcheese 4y ago

Either way I don’t want it and I don’t know why anyone would.

the_gipsy 4y ago

Still, apps do this against the interest of the user, to keep them inside their app. In some apps even if you find a setting that disables this "feature", they then don't open links not in my default browser (firefox) nor in safari, but chrome.