Hacker News Reader

Comment by mrtksn | Hacker News Reader

> instead they just made "SFSafariViewController" which does none of these things

Actually, SFSafariViewController acts as a full Safari without giving any ability to the developer to inject scripts or receive data to track you(except for ad taps through Private Click Measurement). It's actually a nice solution, it shares cookies(non-session ones) with Safari.

View on HN

Right... by "none of these things" I meant... the stuff I listed, which for the record is not incompatible with isolating the browser from the initiating app. It would be totally viable to give SFSafariViewControllers "write only" access to your history (implemented as just an API call that SFSafariViewControllers makes to notify the OS of a page navigation, which it can then store the URL of in your history, so that when you go to history in Safari later, it would show up there). Similarly, there could be a very nice "adopt as tab" button that would "rip" the view controller out of the enclosing app and just plop it into Safari proper, complete with it's back-forward list/history, and make it really easy to transition from the app to Safari without the much less ideal "open in Safari" button that loses navigation/page-state/etc. In other words, the way SFSafariViewController could work is that you are in Safari (forcing the full screen experience), just with a "Done" button that takes you "back" to the app (or an adopt button that "solidifies" the app switch. Think something more akin to the "app banner" that Safari shows when you go to an app's page, just with a nice transition of the webpage coming in from the app, kind of like the old Mail animation from iOS 1). This actually accommodates both goals: you get the real "full Safari" (again, you have effectively opened the link in Safari), but a nice little "Done" button to let you get back to what you were doing in the initiating app, which is the only "good faith" thing the app should care about (obviously we don't care about accommodating tracking/etc.).

I like the "adopt as tab" button idea a lot and generally agree but I also see the associated risks with other suggestions.

For example, write only access to history will also mean SEO-consultant-type people paying app developers to write certain websites to the users history. When Safari does suggestions on the address bar, browsing history is a major source.

The only caller of said API would be the SFSafariViewController itself, the same way the Share Panel can see your Contacts despite you not having given the app that opened the Share Panel Contacts "access". This way, only organic page navigations get recorded (or at minimum is equally susceptible to any history pollution as a normal web page that you encounter). The idea was not to have SFSafariAddURLToHistory(), apologies if that's the way it came off.

Reply on news.ycombinator.com