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.
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.
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.
> 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.
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.
> 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.
No, apps didn’t have any more ability to observe/interact with the view controller than they do now. SFSafariViewController has always been a separate process spawned by the OS, not the app. It was for all intents and purposes a “real” Safari tab the app couldn’t touch.
The way tracking was happening is by apps putting an identifier in the URL, which JavaScript put into the linked page by the authors (social media widgets, Google Analytics, etc) would pick up on the cookies and other identifiers in the SFSafariViewController session carried over from “real” Safari and then tie those with the URL identifier. Boom, Twitter, etc have a nicely fleshed out tracking/advertising profile to attribute to that clicked link, even though they didn’t use a custom webview.
This is exactly how tracking works with regular browser tabs, too. The only way to mitigate it is to give each app its own separate Safari container for SFSafariViewController to run in and encourage devs to use SFSafariViewController instead of the full browser.
What you describe can be achieved by the app opening the page via the system browser. I don’t see any benefit of using a tab in the app instead. The swipe-left gesture at the bottom makes app switching super fast, making rapid switching between app and page a better experience than dragging and re-opening.
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.
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.
> * 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?
> 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:
This behaviour is possible because most browsers aren't configured to block third party cookies. Make sure you've set yours to do so, and embedded content like Facebook's like button will see you as a fresh user every time.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
Your opinion is in the minority, even among the very technical folks I've seen discussing this issue. It's entirely false to reclassify a feature many users want as a dark pattern.
Let me give you an example personally: I want my RSS feed reader to use an in-app browser. Because unless I am going to get significantly more in depth, I just want to see the page content, and then swipe or back out to where I was in my feed very quickly.
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.
Apps that implement a custom web browser using WKWebView (e.g. IG) are much worse and can do those nefarious things.