No wonder. I recently opened a link on Instagram and the website's responsive elements were completely broken. Then I opened the link in Safari and it worked fine.
Does this script injection break Apple's ToS?
I thought Apple required Safari/Webkit for all in-app browsers?
Zuckerberg has no shame.
PS. I hate in-app browsers. They don't sync with my main browser states such as authenticated sessions.
Apple has been fine doing things that hurt FB, see not giving them special privileges' around the Ad tracking permission changes that were added to iOS.
Click on "Sign In/Up with Google". Opens in app browser. Not logged in even though I'm with Safari. Type email. Type password. Get password wrong. Type password again. Get text/email with 2FA code. Every single time.
Or Gmail app. Click link. Open in-app browser. Not logged in.
> Is anyone under the impression that they are a customer of a service they don’t pay for?
Maybe not on a technical forum like this, but I think the distinction between a "customer" and a "user" is sufficiently fuzzy among non-technical people.
Yeah, tracking your behavior. If you searched for a bar, did you look at other bars? Parking? What other things did you look at? All of this could potentially be used for segmentation.
Yes, Google Maps probably tracks your usage of Google Maps. But when you click through to a location's website, it doesn't open that in a local webview and track how you use their website.
Actually twitter is fine on a mobile browser provided you use an account.
What I miss is the multi-container extension on fennec/firefox mobile. I keep using those sites in incognito mode but that mean I can only use one at a time.
Within 3 days of registering a new account they will prompt you 'for a phone number, because we detected security issues with your usage'. Don't know how having a phone number helps with security issues like that, but again -user hostile-.
I'm not creating a Twitter account just to read their public site, because they are user hostile and privacy invasive.
I actually find Twitter’s mobile web app experience to be pretty good–they don’t nag me to install the app every 5 seconds, it’s reasonably performant, the back button works properly and even mostly preserves scroll position. All of the core functionality is there, except new features like Fleets I don’t care about anyway. I use it regularly and have been pretty impressed.
Reddit on the other hand is absolutely hostile and basically none of what I said above is true of their mobile web UI. I refuse to install their app simply out of spite for how aggressively they nag for me to use it. I’ve said no like 500 times at this point, will I change my mind on the 501st prompt?
I all I ever see when following Twitter links on mobile is the lower 1/3 of the screen with a "it's better in the app" banner bullshit. What web app from Twitter are you seeing that doesn't have that?
Thank you!! I was unsuccessfully searching for something like this.
Btw I also see a full screen, not closable login nag when scrolling down a few tweets. The solutions is to tap on login and close the dialog on the following screen.
I won‘t make an account, twitter. Shut me out completely and I‘ll be gone, just like with reddit.
Its significantly less hostile if you use it as an web app, logged in. Even presents a PWA that is basically indistinguishable from the Twitter-Lite app served to data starved localities in Google Play.
Yeah, maybe, but A) I don't have a Twitter account and B) when following a link from some news aggregator showing a "news" story that is nothing but a string of Twitter posts, the user won't be logged in then either.
They also restrict your ability to copy links and text in apps, so that you can't open things in a non-walled app browser. This I believe is why sites like Twitter also uses URL conversion... There is a wild variety of ways in which they can limit where those URLs go, and I've noticed sometimes it even makes externally pointing links not work properly (Which can be turned on and off at will by the link service owner).
Those URLs also mask origination when they point to other sites, so that site logs don't provide any real specific data on where traffic to them is coming from.
The most Internet/user hostile era ever is probably going on right now. Will be interesting to see where this all goes.
I used this to reduce my usage of the sites. It's so terrible I'm in and out in just enough time to check notifications
Having said that I find Twitter to be quite usable in a mobile browser, it's one of the few that isn't awful
Facebook is by far the worst, image posts overlap the edges of the screen, terrible for anything with text overlaying[1]. You can use the mobile version instead but then you can't use FB messenger at all
It is infuriating that I can't browse certain Reddit pages because they want me to "use the app so they know I'm over 18". I first ran into this in my current attempt to play through Dark Souls 3. It seems like the community there has a lot of good discussions about beating certain bosses, but for some reason, Reddit has decided that the content in that sub-reddit needs age verification and they wall it behind the app.
I just keep an old phone around for when I need to use apps (banking, especially). Can’t steal the information off my device if there’s nothing on there taps forehead
I remember when the Twitter app asked if I wanted to sync the mobile contacts every time I opened the app. Thankfully Android has become better when it comes to this even if there are still flaws.
You mean custom ones, right? WebViews are incredibly useful, but it definitely seems like implementing your own browser gives people a false sense of security, like they've been sandboxed when they haven't.
What would be nice here is a permission requirement if you're injecting code into a browser view.
webviews for clicking arbitrary links in apps like instagram or gmail are absurdly restrictive. i lose my context, cookies, and regular tools (bookmarks are gone, sharing often overridden, etc)
That was a great update, but still not a true browser. No tabs, no bookmarks. Why should the website be restricted to one tab? Just open Safari and be done with it.
If you want a true browser there's always the option to move the current page from the in-app Safari View to the full browser.
In many cases I'd like to stay within the app. Those in-app Safari Webviews allows that. And if it is a website I'd like to browse in my usual, more permanent browsing evironment I always have th eoption to do so.
This two step approach is more useful to me than always opening links in the browser.
They're supposed to be restrictive as to not confuse the user. An in-app browser isn't there to give you a full browsing experience, it's there to do a quick web-only task that somehow cannot be done in the native app itself.
since years ago apple added the little back button to return you to your previous app, even webview is dead weight. apple should only allow one, in some special context, that's so counterintuitive to implement that only frameworks e.g. react native can justify the effort
And yet, we're normally seeing Apple === BAD because they limit everything to just the one Apple thing. Am I actually seeing requests for Apple to limit willingly?
Most of Hackernews doesn't understand why Apple is the #1 tech company in the world -- they're still in the "no wireless, less space than a Nomad, lame" mindset.
How is the walled garden allowing a phone to last for four years? Where you getting new phones because you polluted your non-walled garden device with so many bad apps that you chose to get a new device? Not really following your point, but maybe I am?
i was getting new phones mostly because my devices were getting bogged down by android updates and capabilities. the os allowed developers to do more and more things, and offered more and more customization, faster than the pace of hardware improvements supported, to the point i'd have to get a new phone if i wanted something both up-to-date and fast. if i kept a phone longer much longer than a year, i'd have to worry about software updates as well, OR replace the OS and deal with instability.
and i'm not talking about bad phones here — htc one s, nexus 4, nexus 5, nexus 5x. admittedly, degradation of shitty NAND is still a factor in higher-end android phones, so it's not all about the android ecosystem being a free-for-all
an iphone xr will still run everything fine, including the latest version of ios. hundreds of dollars saved and a whole set of problems avoided over the life of the phone. i only replace my phones when they're smashed to bits now
anecdote: someone in my family just had to replace their android phone because a software update caused the radio to stop working for calls. so the ecosystem issue is not just a userland thing
I'm on an iPhone 6s+, so yeah, I'm a fan of the not needing a new phone all the time. I am pleasantly surprised with each new iOS that my phone is still not deprecated. At that point, I will have to look at updating.
Last I heard (years ago), iOS forced everyone to use Safari for webviews, which lots of people also complained about. Did that change? Or is the Safari webview the subject of this story?
The key aspect here is that Instagram's app is using a Safari Webview but somehow it is injecting its own tracking pixel on the HTML body wether the target website had it or not.
Which honestly does not surprise me, what surprises me is that Apple allows this. I think there was a time where certain Javascript capabilities were present in Safari but not in Safari Webview and there was certain outrage.
Perhaps a solution would be to run the webview through Safaris content blocker engine?
Every webview on iOS is Safari internally. The issue is if an app presents a webview, they can inject whatever javascript they want. This is what allows frameworks like Ionic to work in the first place, the webview runs the "app" and any interface back to the OS is communicated through a bridge to the native world.
Do you want to cripple the entire app industry? Apps built using React Nativ / Flutter e.t.c use the WebView to render themselves. So they’re basically already running “in-app browsers”
But then how do you differentiate when the app is rendering its own view rather than another website? You could apply some restrictions like <iFrame> has nowadays where you need extra security privileges (I think) to render pages / execute scripts not on the same domain
Otherwise you can always open safari from all of these in-app browser views and they could implement a toggle which forces all of them to be opened in Safari automatically
Huh, TikTok is one of the first apps I have seen which do not allow you to open an external website in Safari. I am going to do a bit more research and try to find other apps that do the same
I think the clear answer is to only allow local/whitelisted domains that you can prove you own. I work on Capacitor/Cordova apps regularly and only allowing local code would allow for them to continue to work and close this loophole. Anytime I open an external page I do it in SFSafariViewController which doesn't have the ability to inject code or snoop.
Awful stuff. I shudder to think what a Meta-run App Store or "metaverse" would look like from a tracking perspective. Meanwhile, the "dumb fucks" quote[1] remains evergreen.
The article isn't complaining about in-app browsers per se, but that Instagram implements a special version of an in-app browser that injects Javascript code to track user behaviour. If you have noticed TikTok doing the same thing, please publish a blog post about it, and I expect it would get attention here on Hacker News, at least.
I can't imagine why anyone would expect otherwise. If you're still 'inside' an application, why wouldn't that app be able to track everything you do?
To completely hijack the discussion here, I believe that Apple is actually one of the strongest forces for anti-privacy in the world, because of their long-term, successful push for the convention of app > website (not fully supporting PWAs, disallowing web push, etc). A website may spy on you, but it can only do so in ways constrained by the browser, which has to serve many "masters". Mobile apps are completely unconstrained in their spying, and in-app browsers are just the logical extension of that pattern.
Thanks largely to Apple, we've conditioned ourselves to expecting that you can't have good mobile UX without a mobile-native application, and it's hard to imagine ever escaping back into the relatively open web now that we're this far down this path. Most people will never question the privacy implications of installing the Facebook app, and most of Apple's privacy-directed efforts on iOS are basically playing walled-garden whack-a-mole on problems that are better solved at a societal level with web browser standards.
Yes, it's quite likely that I'm scapegoating here, but it's the way I see it.
Apps that use Safari View Controller cannot view the page - of course Facebook doesn't use SVC for this reason.
While you're right that the Facebook/Instagram app can spy on links opened within the app, it can't plant cookies in your web browser - so those go both ways.
I thought Facebook/Instagram used a WebView for their in-app browser on both iOS and Android? Which means they can do anything they want, including exfiltrate your browsing.
Safari View Controller keeps the users cookies from Safari and prevents this behavior. For most apps, keeping users logged in without leaving the app is preferred, so they give up the ability to inspect the contents of the page.
GP a was referring to a specific “web view” implementation that offers an almost-complete browser implementation and security on iOS. Facebook does not use this but a regular WebView
I generally don't see any appeal to in-app browsers in the first place. They often have extremely broken navigation controls (i.e. attempting to swipe back to a previous page usually just returns back to the app), block the ability to navigate to a specific URL, content blockers don't work, don't allow opening "smart links" that would typically open in another app if opened from a normal browser, etc. From what I'm gathering from this article, it sounds like in-app browsing allows apps to give you all of the "benefits" of being tracked (for their benefit only), with none of the (actual) benefits of using a real browser.
Ironically the whole point of it originally was sandboxing, and it’s true at least on iOS. Thus, you won’t be logged into the same sites within an in-app browser, and clicking a link from within an app (whether it appears to be an link or not) can’t automatically connect you to cookies and any other tracking from your actual browser.
The point with firefox focus is that the whole browser is in private mode. And even another browser, so no shared sessions or anything with your normal browser or precious interactions/sessions.
Not sure if open-links-in-apps is comparable to that, never tried it (I rather prefer multitasking than doing it from within the app anyway).
I frankly am surprised why anyone would think otherwise? The “In-app” in the name should kind of give it away that it is, after all, in the app. Anything you do will be available for the app to track.
Consider the overwhelming majority of users are technically illiterate. Everything is just magic scrolling machines people learned to trust from watching people they trust use them.
I would sympathize with all of the illiterate users. But the person who reported this and the people on HN discussing the article would be considered a little more technologically literate I would assume.
Considering that a simple iOS privacy disclosure dialog box cost FB $10bn in revenue loss, I'd say there are a lot of things users would be surprised to know when it comes to how apps work and what they collect.
On iOS this is traditionally done with UIWebView or WKWebView(like the former but better performance, runs as separate process) and you are right about the problems it creates.
However, the developers do have options to incorporate SFSafariViewController since iOS9.0 and that gives the user full Safari experience with Autofill and everything and without giving access to its contents to the app developer.
It actually makes a lot of sense from users perspective when the context is that the app temporary needs to take you to a webpage for something with the intention of you going back to the app. With SFSafariViewController this is done securely and with good user experience but unfortunately most apps business model revolves around tracking everything you do and as a result, most developers would use UIWebView/WKWebView instead of SFSafariViewController just to be able to track you.
The UIWebView/WKWebView has legitimate uses like letting you sign in from a web interface and transfer the session into the app but I kind of feel like we would be better off to depreciate it in favour of using alternative methods to do the web/app connection and improve privacy significantly.
Personally, I would never do anything sensitive from within a browser that is in an app. It looks like very obvious attack vector to me.
I'm sure this has gotten better as people have become more used to smartphones, but I worked on a popular app for a big company a number of years ago, and we would send people out to Safari to open links. The number of customer service calls we got from people who couldn't figure out how to get back to the app after that was ASTOUNDING. We eventually gave in and did an in-app browser. Not only did it get rid of that category of call, but it also noticeably helped our key metrics because fewer people were leaving the app to never come back again.
I realize that doesn't address the appeal FOR USERS, but it is why we did it as developers.
I'm the opposite, I hate in app browsers as a user. It's like having a bunch of extra poorly made web browsers that can only have one tab, and block me from using one of my apps. When I'm trying to find a tab I had open now I have to search both my browser tabs and every app in my app switcher. And if I want to keep using an app but it's showing an in-app browser I have to either throw away my tab, or navigate a menu to migrate it to my real browser to save for later, then switch back to the app and close the in app browser, and only then can I continue to use the app. It's a constant pain.
I think Android's "custom tabs" functionality is a great compromise. Apps can open a separate instance of the user's default browser which becomes part of the app's activity stack and doesn't share tabs with the main browser instance. However the UI and navigation are controlled by the browser, not the app. Cookies and local storage are also shared with the main browser instance, allowing seamless SSO without the app being able to intercept the secrets.
AFAIK iOS supports something similar, but only for authentication use cases.
I feel like half the time I encounter them is when I’m already in my browser, click a link (probably search results), it opens the app, the app proceeds to display content in an in app browser.. and I’m just left think why, WhY, WHY?
Same issue when your website opens a link in a new tab on mobile: many mobile users have no idea how to get back. The back button does not work and they don't know how to close/switch tabs. They're barely aware of the concept of a tab.
What mobile browsers actually have tabs that look like tabs? Honest question, I've only ever used firefox on android. If the others handle tabs anything like firefox does tabs are way more intuitive on a PC.
That's a very understandable decision from an app developer POV. But the fault lies with the OS and ideally should be solved by it. This isn't a problem on real computers.
It's like putting a toilet in every room because people can't find the bathroom when maybe the bathroom shouldn't have been hidden down in a hatch under a rug. But you can't easily rebuild your house, and now there's shit everywhere, so what is one to do?
iOS 'solved' this by including a back button in the top left that takes you to the previous app, but now I sometimes misclick that when trying to hit a button/control in the top left of the foreground app. On a small 5 to 8-inch display, there's tradeoffs for every change they make and in every stage of the design process.
1. Nothing you visit gets saved in your history. So many times I'm looking through my history thinking "I could have sworn I read an article about this..." only to eventually discover (if I'm lucky) that it was in Twitter's stupid in-app browser. But oh well, never going to find that article again! The irony of the APP knowing everything you visit but you never getting to remember what you visited.
2. All your logins are gone! I actually pay a bunch of stupid newspapers just to click on links in Twitter and STILL be told I can't read the article because of course I'm not logged-in in the in-app browser. UGH.
You could imagine a world where iOS tried to balance the desire of an app to not bounce you out with a more "integrated experience" by providing an "in-app" browser that was completely controlled by the OS, modifying your history, keeping you logged in, running out of process, and being able to be "adopted" as a tab in Safari, but instead they just made "SFSafariViewController" which does none of these things and instead just makes it really really easy for all apps to incorporate these infuriating in-app browsers.
> 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.
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.
Right, I know. I mentioned SFSafariViewController in my post. I am saying, in the 9 years since SFSafariViewController was introduced, Apple could have made the experience with SFSafariViewController better, for example by having pages you visit in a SFSafariViewController get saved into your normal browsing history (this can be done without giving Twitter access to anything, it can simply notify the OS of an internal navigation, and then the OS can add that item to your Safari history. If SFSafariViewController runs out-of-process, then it can be even simpler than that). I then wouldn't have to keep a weird mapping in my head of what "app" I read an article in to ever get back to it. This would go a long way in closing the gap with the benefits you get from opening a link in Safari proper instead of viewing it in-app.
On everything other than iOS (desktop and iPad), I either use Twitter in the browser or it is reasonable to just have links open in the main browser. Using Twitter in Safari on iOS (on the phone, to distinguish it from iPadOS), you end up with kind of the reverse problem of needing to fish around for Twitter in tabs. If Safari on iOS had a better "save web app"/site-specific browser story, then this could possibly remedy some of these problems (or if they implemented some of the basic ideas I described, like storing history).
The original SFSafariViewController did share cookies with regular Safari. The documentation says
> In iOS 9 and 10, it shares cookies and other website data with Safari.
I was also also disappointed that they removed it in iOS 11. But it's still a step-up from other even more horrible in-app browsers like in Instagram, which are implemented with WKWebView. I refuse to read anything in those in-app browsers; I always manually open them in Safari.
lol what you’re describing as a ‘feature’ is actually insecure & vulnerable. There are strong security reasons why Apple mandates WKWebView and bans SFSafari.
SFSafariViewController is not banned. It's recommended by Apple for some use cases. It says,
> If your app lets users view websites from anywhere on the Internet, use the SFSafariViewController class. If your app customizes, interacts with, or controls the display of web content, use the WKWebView class.
My assumption is that it is a Product managers play to get people to stay in the app for longer. If you give people a link out of the app, then they are less likely to come back after.
You get a bump in engagement and time spent in the app at the cost of UX.
Well, I'm sure there are "growth hacker" types out there abusing the ability to observe browsing. But I think the real reason they don't bounce you to Safari, Chrome, etc is because users don't stay in the app if they do that.
I think all of the various bad things people talk about here must happen sometimes, but it's mostly just retention I'd guess.
> i.e. attempting to swipe back to a previous page usually just returns back to the app
Is there any way to turn that damn functionality off? I can’t tell you how many times I’ve been navigating some newfangled web UI and had a swipe go “back”.
That and disabling pinch to zoom backing out to the tabs UI. I wanna zoom out dammit. Is hitting a back or tab button really so hard that you have to break basic pan/zoom mechanics?!
I know I’m putting off “old man yells at cloud” vibes here, but come on
The very first thing I do, every time, is click "open in browser", just because, if nothing else, the framing of the site always feels "off" to me when using one of those in-app browsers.
I once wrote an email to Steve Jobs, saying that operating systems like MacOS and iOS should have a secret phrase or icon that they show to you whenever they show a system-level security dialog. (And of course implement the same restrictions on screenshots of that dialog as they do for movies.)
Because otherwise, an app can totally fake the interface of a security dialog. The only way you know, these days, is that password managers and cookie jars work with the "approved" sites, but they can simply show you a site that doesn't require those, and then fool you into entering your passwords!
Steve never replied to me. And Apple never implemented it.
I hope Apple doesn't disable JS injection in WKWebViews in response to this. JS injection is the (only?) way to call native Swift methods from JS ie. bridging.
I am not sure what the solution here is. Maybe only allow injection to sites you control (via apple association file).
Only intentionally, via setup from a hosting app. If an app uses a WKWebView to display web content, it can use WKUserContentController[1] to inject scripts and additional content into the page dynamically, and can inject functions into JS[2] which will trigger native callback handlers when called.
If your app uses the JavaScriptCore[3] framework to run JS in a VM in-process directly, you have even more options for interfacing between JS and native code.
Note that this has to be explicitly hooked up by the app (i.e., none of this applies within, say, Safari).
With the appropriate libraries you can use JS to call Swift and Obj C code.
Long answer: no
All it really means is that the JS and Swift/Obj C can pass data between each other and the library is set up to parse that data and call the appropriate code. It's just an automatic RPC.
Sure but since the App Store is human review, they can tell the difference between a web view and an external website. Or just require the app to only call web views on their own domain or a whitelist of domains they submit with the app.
Same here. So many apps legitimately depend on these features, which makes me worried about an overreaction from Apple here.
A domain verification would be a huge hassle for me, since I provide an app builder that allows my non-technical customers to build an app (which includes a webview). Asking them to do domain verification would be tricky.
It would be interesting if this violates rights of the website owner the user is visiting. I known that embedding content of other websites into your own via an iframe can be a copyright violation. And what Meta does here is more or less like an iframe.
I believe so. Copyright and TOS of the sites. Copyright also in the sense that content have been changed. This should be on pair with banner swap techs.
My god...you are like the 8th inactive HN user I saw that suddenly springs into action to suggest Brave or post links to Brave
I think we can see whats really going on here. Any chance to drop or mention Brave, after not being active for weeks or months, suddenly congregate to push Brave browser
Dang really needs to do something about this type of astroturfing
what are you suggesting? I didn't recommend Brave to anyone, it's just a comparable example to this issue. You can look up their legal issues and build your own opinion based on that.
And why are you suggesting i'm an "inactive user"?
Yes, but they don't secretly track you on the websites you visit.
They do it in some way, but not directly on the browser. More with settings sync, their search engines, ...
The thing about the law is, that some specific things are forbidden. And if you achieve the same goal, in another legal way, it is fine.
For example saving taxes: If you make a fraudulent report and save 1000$ this is illegal. But if you find a way to save 1000$ on taxes, by declaring something legal, the same 1000$ are fine. But in both cases you save exactly the same amount.
Copyright violations stem from distributing an unauthorized copy of a protected work. Modifying an authorized copy shown to one recipient can't be a violation.
User agents are expected to be empowered to transform the data they receive to suit the rendering requirements of the end user. Having a third party perform part of the transformation by supplying supplementary code executed by the user agent doesn't change anything.
>I’ve disclosed this issue with Meta through their Bug Bounty Program
lol. and this is why companies can be hesitant to run bug bounty programs. it's not a place to complain about things you don't like. Meta/instagram has made a design decision here. just because you don't like it, doesn't mean it's a vulnerability.
Remember this is the same company that just gave police DMs that aided in an abortion investigation. If those had been end to end encrypted that risk would not have existed, but they made a business decision to leave the application vulnerable to spying for profit reasons. That is a vulnerability, in the same way we call it a vulnerability when an entity man-in-the-middles a browser to spy on people.
Personal user browsing or communications leaking in plain text to private companies without explicit and obvious user consent puts users at risk, and is a vulnerability. It just so happens to be one arising from malicious profit seeking behavior that happens to be the status quo.
Not having https was once the status quo, and a boon for corporate spying, but we call that a vulnerability now because the abuses became too big too ignore.
Users are given the choice to accept risks that are buried on page 7 of privacy policies only a lawyer could understand the tricks in.
Services knowingly endangering unknowing users for money should be like cigarettes and be forced to say on the signup page in big bold text they can and will sell user data to anyone, including law enforcement.
Users largely think free services are like public libraries and do not default to expecting they are being exploited for money. Element, Wikipedia, and duckduckgo exist for free without selling user data so it is not a given that exploitation is always present in free services.
This isn't a consumer choice issue. People love morphine too, it doesn't mean Amazon can sell it to them. If Apple enforced its own rules in this case, Facebook would just have to act like any other developer and find some revenue streams that comply with established privacy norms.
I don't think the GP is saying that Meta should have ignored a lawful order. I think they're saying that they shouldn't have put themselves in the position of being able to render that information, and only have done so because it's profitable for them to do so.
It’s really painful to see all of these encryption holes in every product we use daily. Apple claims privacy, yet your whole phone sits unencrypted on their server ready to be served to anyone who asks (assuming you back up your phone to iCloud)
Encrypted but they have the keys so they can serve it to anyone who asks. That’s why “end-to-end” is subsequently mentioned as an “additional” step for certain data. It should all be end-to-end like iCloud Keychain is, at least on demand.
End to end encryption is only useful when the software on each end is open source and deterministically built/distributed by third parties with accountability.
Even Signal or Google/Apple could ship a bad Signal app update to targeted devices to dump convos if ordered. If you use Matrix with a client from an F-Droid build or a reproducible build from debian etc, then the Matrix developers literally could not comply with orders to obtain your plaintext content.
One thing I've noticed is that content-blockers/adblock don't seem to work within the Facebook/Instagram etc. in-app browsers so I usually end up jumping out of them anyway.
The worst is when the link is YouTube and I have to watch an ad even though I pay for YouTube Premium but because it launched in an app browser I'm not logged in.
Not only would CSP block it, but this type of behavior only strengthens Apple's decision to not allow third party rendering engines. Could you imagine the privacy nightmare that would ensue if Facebook could release a browser that bypassed any and all safeguards implemented by site operators?
I believe this is not legal. It is a grey area for users to do things like this but for a browser to change the actual contents is illegal on most sites. Or at least, there is no general way for a browser to validate if it is legal or not.
HN should really get rid of the down votes... Please explain why you think it is legal for a proxy to inject custom scripts. I am sure our TOS states that this is not allowed. Also, I think it basically is a copyright infringement.
If these platforms do things that are abusive and invasive, the solution is not to complain about it, the solution is to stop donating content to them for free and delete your account so they aren't attractive to more users.
Continuing to enrich them, even by your reachability via their DM messengers, makes them more attractive to your friends and family.
Delete your Facebook and Instagram accounts. Stop giving them positive feedback (via continued usage and content donations) after they make clear choices to abuse you.
Is this different from my android experience where I open a link from an app and it opens my default browser, Firefox, but kind-of within the app, but allows me to instantly switch over to the Firefox app instead using a drop-down menu option?
iOS provides a way of showing a browser that looks like it's within the app from which it is launched. This is not what Instagram is doing. Instagram is doing something different from what other apps like Telegram do, according to the article:
> Comparing this to what happens when using a normal browser, or in this case, Telegram, which uses the recommended SFSafariViewController:
> As you can see, a regular browser, or SFSafariViewController doesn’t run any JS code. SFSafariViewController is a great way for app developers to show third party web content to the user, without them leaving your app, while still preserving the privacy and comfort for the user.
468 comments
[ 1.5 ms ] story [ 305 ms ] threadDoes this script injection break Apple's ToS?
I thought Apple required Safari/Webkit for all in-app browsers?
Zuckerberg has no shame.
PS. I hate in-app browsers. They don't sync with my main browser states such as authenticated sessions.
Doesn't apply to special companies.
They are still using Safari/Webkit, but just injecting a script into every page.
Seems like that's probably a good thing :)
Under what circums do you want this?
Click on "Sign In/Up with Google". Opens in app browser. Not logged in even though I'm with Safari. Type email. Type password. Get password wrong. Type password again. Get text/email with 2FA code. Every single time.
Or Gmail app. Click link. Open in-app browser. Not logged in.
And this is exactly why Apple gives them their own cookie jar. The alternative would be [more of] a security nightmare.
Better analytics = better product*.
* for the true customers, i.e. marketing & communication firms, governments, etc.
Is anyone under the impression that they are a customer of a service they don’t pay for?
People would readily identify as a “Twitter user” instead of a “Twitter customer”
Maybe not on a technical forum like this, but I think the distinction between a "customer" and a "user" is sufficiently fuzzy among non-technical people.
Edit: meant why Google wouldn’t do this. I guess what I really mean, is what are the chances they don’t do this?
Whether Chrome tracks how you use it...
Which are increasingly user hostile, if not down right impossible to view on mobile. Go try using Reddit or Twitter on your Mobile browser.
https://play.google.com/store/apps/details?id=com.andrewshu....
For those of us who can't go to the bathroom without reddit.
What I miss is the multi-container extension on fennec/firefox mobile. I keep using those sites in incognito mode but that mean I can only use one at a time.
Within 3 days of registering a new account they will prompt you 'for a phone number, because we detected security issues with your usage'. Don't know how having a phone number helps with security issues like that, but again -user hostile-.
I'm not creating a Twitter account just to read their public site, because they are user hostile and privacy invasive.
Reddit on the other hand is absolutely hostile and basically none of what I said above is true of their mobile web UI. I refuse to install their app simply out of spite for how aggressively they nag for me to use it. I’ve said no like 500 times at this point, will I change my mind on the 501st prompt?
I wonder if it can solve this problem since reddit/twitter/tiktok won't stop.
Those URLs also mask origination when they point to other sites, so that site logs don't provide any real specific data on where traffic to them is coming from.
The most Internet/user hostile era ever is probably going on right now. Will be interesting to see where this all goes.
Having said that I find Twitter to be quite usable in a mobile browser, it's one of the few that isn't awful
Facebook is by far the worst, image posts overlap the edges of the screen, terrible for anything with text overlaying[1]. You can use the mobile version instead but then you can't use FB messenger at all
[1] e.g. https://img.imgy.org/-7p8.jpg
Nothing's stopping you. There is no such message on old.reddit.com.
This gets amplified when using ad/tracker blockers at DNS level (NextDNS).
You have to give apps permission to get your contacts, right?
What would be nice here is a permission requirement if you're injecting code into a browser view.
In many cases I'd like to stay within the app. Those in-app Safari Webviews allows that. And if it is a website I'd like to browse in my usual, more permanent browsing evironment I always have th eoption to do so.
This two step approach is more useful to me than always opening links in the browser.
and i'm not talking about bad phones here — htc one s, nexus 4, nexus 5, nexus 5x. admittedly, degradation of shitty NAND is still a factor in higher-end android phones, so it's not all about the android ecosystem being a free-for-all
an iphone xr will still run everything fine, including the latest version of ios. hundreds of dollars saved and a whole set of problems avoided over the life of the phone. i only replace my phones when they're smashed to bits now
anecdote: someone in my family just had to replace their android phone because a software update caused the radio to stop working for calls. so the ecosystem issue is not just a userland thing
Which honestly does not surprise me, what surprises me is that Apple allows this. I think there was a time where certain Javascript capabilities were present in Safari but not in Safari Webview and there was certain outrage.
Perhaps a solution would be to run the webview through Safaris content blocker engine?
But then how do you differentiate when the app is rendering its own view rather than another website? You could apply some restrictions like <iFrame> has nowadays where you need extra security privileges (I think) to render pages / execute scripts not on the same domain
Otherwise you can always open safari from all of these in-app browser views and they could implement a toggle which forces all of them to be opened in Safari automatically
Honestly it is pretty fascinating how these cross-platform frameworks work.
and no, not all apps do this. tiktok does not offer an escape, and instagram hides it behind two clicks.
[1] https://www.businessinsider.com/well-these-new-zuckerberg-im...
To completely hijack the discussion here, I believe that Apple is actually one of the strongest forces for anti-privacy in the world, because of their long-term, successful push for the convention of app > website (not fully supporting PWAs, disallowing web push, etc). A website may spy on you, but it can only do so in ways constrained by the browser, which has to serve many "masters". Mobile apps are completely unconstrained in their spying, and in-app browsers are just the logical extension of that pattern.
Thanks largely to Apple, we've conditioned ourselves to expecting that you can't have good mobile UX without a mobile-native application, and it's hard to imagine ever escaping back into the relatively open web now that we're this far down this path. Most people will never question the privacy implications of installing the Facebook app, and most of Apple's privacy-directed efforts on iOS are basically playing walled-garden whack-a-mole on problems that are better solved at a societal level with web browser standards.
Yes, it's quite likely that I'm scapegoating here, but it's the way I see it.
While you're right that the Facebook/Instagram app can spy on links opened within the app, it can't plant cookies in your web browser - so those go both ways.
Safari View Controller keeps the users cookies from Safari and prevents this behavior. For most apps, keeping users logged in without leaving the app is preferred, so they give up the ability to inspect the contents of the page.
It does not, because apps decided to abuse it for fingerprinting.
Settings > Advanced > "Open links in apps"
https://support.mozilla.org/en-US/kb/set-firefox-android-ope...
Not sure if open-links-in-apps is comparable to that, never tried it (I rather prefer multitasking than doing it from within the app anyway).
However, the developers do have options to incorporate SFSafariViewController since iOS9.0 and that gives the user full Safari experience with Autofill and everything and without giving access to its contents to the app developer.
It actually makes a lot of sense from users perspective when the context is that the app temporary needs to take you to a webpage for something with the intention of you going back to the app. With SFSafariViewController this is done securely and with good user experience but unfortunately most apps business model revolves around tracking everything you do and as a result, most developers would use UIWebView/WKWebView instead of SFSafariViewController just to be able to track you.
The UIWebView/WKWebView has legitimate uses like letting you sign in from a web interface and transfer the session into the app but I kind of feel like we would be better off to depreciate it in favour of using alternative methods to do the web/app connection and improve privacy significantly.
Personally, I would never do anything sensitive from within a browser that is in an app. It looks like very obvious attack vector to me.
I realize that doesn't address the appeal FOR USERS, but it is why we did it as developers.
My browser would get littered with old tabs and coming back to the app for a small click became a hassle
On the off-chance I do want to save a link, I know I can just open it in my browser anyway
So I much prefer in-app browsers as a user and a developer
AFAIK iOS supports something similar, but only for authentication use cases.
What mobile browsers actually have tabs that look like tabs? Honest question, I've only ever used firefox on android. If the others handle tabs anything like firefox does tabs are way more intuitive on a PC.
It's like putting a toilet in every room because people can't find the bathroom when maybe the bathroom shouldn't have been hidden down in a hatch under a rug. But you can't easily rebuild your house, and now there's shit everywhere, so what is one to do?
This opens Safari, but makes it appear like it's an in-app browser. Best of both.
1. Nothing you visit gets saved in your history. So many times I'm looking through my history thinking "I could have sworn I read an article about this..." only to eventually discover (if I'm lucky) that it was in Twitter's stupid in-app browser. But oh well, never going to find that article again! The irony of the APP knowing everything you visit but you never getting to remember what you visited.
2. All your logins are gone! I actually pay a bunch of stupid newspapers just to click on links in Twitter and STILL be told I can't read the article because of course I'm not logged-in in the in-app browser. UGH.
You could imagine a world where iOS tried to balance the desire of an app to not bounce you out with a more "integrated experience" by providing an "in-app" browser that was completely controlled by the OS, modifying your history, keeping you logged in, running out of process, and being able to be "adopted" as a tab in Safari, but instead they just made "SFSafariViewController" which does none of these things and instead just makes it really really easy for all apps to incorporate these infuriating in-app browsers.
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.
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.
> In iOS 9 and 10, it shares cookies and other website data with Safari.
I was also also disappointed that they removed it in iOS 11. But it's still a step-up from other even more horrible in-app browsers like in Instagram, which are implemented with WKWebView. I refuse to read anything in those in-app browsers; I always manually open them in Safari.
> If your app lets users view websites from anywhere on the Internet, use the SFSafariViewController class. If your app customizes, interacts with, or controls the display of web content, use the WKWebView class.
I'm quoting straight from the documentation. https://developer.apple.com/documentation/safariservices/sfs...
You get a bump in engagement and time spent in the app at the cost of UX.
I think all of the various bad things people talk about here must happen sometimes, but it's mostly just retention I'd guess.
Is there any way to turn that damn functionality off? I can’t tell you how many times I’ve been navigating some newfangled web UI and had a swipe go “back”.
That and disabling pinch to zoom backing out to the tabs UI. I wanna zoom out dammit. Is hitting a back or tab button really so hard that you have to break basic pan/zoom mechanics?!
I know I’m putting off “old man yells at cloud” vibes here, but come on
Because otherwise, an app can totally fake the interface of a security dialog. The only way you know, these days, is that password managers and cookie jars work with the "approved" sites, but they can simply show you a site that doesn't require those, and then fool you into entering your passwords!
Steve never replied to me. And Apple never implemented it.
I am not sure what the solution here is. Maybe only allow injection to sites you control (via apple association file).
If your app uses the JavaScriptCore[3] framework to run JS in a VM in-process directly, you have even more options for interfacing between JS and native code.
Note that this has to be explicitly hooked up by the app (i.e., none of this applies within, say, Safari).
[1]: https://developer.apple.com/documentation/webkit/wkuserconte...
[2]: https://developer.apple.com/documentation/webkit/wkuserconte...
[3]: https://developer.apple.com/documentation/javascriptcore
With the appropriate libraries you can use JS to call Swift and Obj C code.
Long answer: no
All it really means is that the JS and Swift/Obj C can pass data between each other and the library is set up to parse that data and call the appropriate code. It's just an automatic RPC.
A domain verification would be a huge hassle for me, since I provide an app builder that allows my non-technical customers to build an app (which includes a webview). Asking them to do domain verification would be tricky.
This of course is a different case for corporations with a dedicated legal team.
And second the browser manufacturer (usually) doesn’t make any money by tracking their users. They provide them with a tool, a browser.
There is the browser Brave, that replaces ads on websites (and makes some profit with that), and there are some serious legal issues coming with that.
The right you seem to be claiming is “you can’t render my website in your app if I don’t like your app”, and that’s not how it works.
I think we can see whats really going on here. Any chance to drop or mention Brave, after not being active for weeks or months, suddenly congregate to push Brave browser
Dang really needs to do something about this type of astroturfing
And why are you suggesting i'm an "inactive user"?
Don't they? Google, Apple and Microsoft are all in the ads business.
They do it in some way, but not directly on the browser. More with settings sync, their search engines, ...
The thing about the law is, that some specific things are forbidden. And if you achieve the same goal, in another legal way, it is fine.
For example saving taxes: If you make a fraudulent report and save 1000$ this is illegal. But if you find a way to save 1000$ on taxes, by declaring something legal, the same 1000$ are fine. But in both cases you save exactly the same amount.
User agents are expected to be empowered to transform the data they receive to suit the rendering requirements of the end user. Having a third party perform part of the transformation by supplying supplementary code executed by the user agent doesn't change anything.
lol. and this is why companies can be hesitant to run bug bounty programs. it's not a place to complain about things you don't like. Meta/instagram has made a design decision here. just because you don't like it, doesn't mean it's a vulnerability.
Personal user browsing or communications leaking in plain text to private companies without explicit and obvious user consent puts users at risk, and is a vulnerability. It just so happens to be one arising from malicious profit seeking behavior that happens to be the status quo.
Not having https was once the status quo, and a boon for corporate spying, but we call that a vulnerability now because the abuses became too big too ignore.
Consumers have a payment-avoiding behaviour as a status quo.
Users are given the choice to accept risks that are buried on page 7 of privacy policies only a lawyer could understand the tricks in.
Services knowingly endangering unknowing users for money should be like cigarettes and be forced to say on the signup page in big bold text they can and will sell user data to anyone, including law enforcement.
Users largely think free services are like public libraries and do not default to expecting they are being exploited for money. Element, Wikipedia, and duckduckgo exist for free without selling user data so it is not a given that exploitation is always present in free services.
They were served a warrant. I'm no friend of Facebook/Meta, but any company served a warrant is going to turn over what they have.
[1]: https://support.apple.com/en-us/HT202303
Even Signal or Google/Apple could ship a bad Signal app update to targeted devices to dump convos if ordered. If you use Matrix with a client from an F-Droid build or a reproducible build from debian etc, then the Matrix developers literally could not comply with orders to obtain your plaintext content.
Technical Vuln or Business Vuln?
[0] https://www.w3.org/TR/permissions-policy-1/ [1] https://scotthelme.co.uk/enabling-coop-and-coep-reports-on-r...
Continuing to enrich them, even by your reachability via their DM messengers, makes them more attractive to your friends and family.
Delete your Facebook and Instagram accounts. Stop giving them positive feedback (via continued usage and content donations) after they make clear choices to abuse you.
> Comparing this to what happens when using a normal browser, or in this case, Telegram, which uses the recommended SFSafariViewController:
> As you can see, a regular browser, or SFSafariViewController doesn’t run any JS code. SFSafariViewController is a great way for app developers to show third party web content to the user, without them leaving your app, while still preserving the privacy and comfort for the user.
Custom Tabs always have a title bar and a small writing "Powered by <browser>" at the end of the menu.