Comment by deminature
4 years ago
They're going to heavily lockdown WKWebView after the Instagram and Tiktok revelations, probably in iOS16.1. They may even remove it entirely and force people to use SFSafariViewController (heavily locked down web browser, opaque to developers other than URL). Best of luck to anyone that was using javascript injection for legitimate purposes, others have ruined it for everyone by abusing user trust.
I highly doubt this will happen. There are a ton of apps that use things like Cordova or Capacitor (usually for cross-platform purposes).
What I could see them doing is making apps declare URLs that they need access to. Basically, you get full functionality on declared URLs, but if you are just using WebView for a "generic" in-app browser you lose the ability to inspect random pages.
> What I could see them doing is making apps declare URLs that they need access to. Basically, you get full functionality on declared URLs, but if you are just using WebView for a "generic" in-app browser you lose the ability to inspect random pages.
This is exactly what I'm expecting, because that's how they've handled other similar restrictions. Becoming a full on web browser with the iOS 14 web browser entitlement will probably be the only way to not be bound to a list of URLs, and they don't hand that entitlement out willy nilly.
The mechanism you are describing is already implemented and advertised: https://webkit.org/blog/10882/app-bound-domains/
Apple „just“ need to enforce it.
Couldn't you just proxy everything through a host you own?
Wouldn't a simple solution be to require apps that aren't browser to list a limited set of domains they're allowed to access? Then you could use the WkWebKit view for your app but you couldn't use it to allow the user to browse the web.
Browsers would get a pass where Apple would come up with some rule but clearly the Instagram app, the Facebook app, the TikTok app, the Gmail app, the Google app, are not browser where as Firefox, Chrome, Brave are.
iOS already has a method to associate websites with apps but I see some problems with this approach.
1) If you go with the "associated domains only" approach that requires proof of domain ownership(usually through adding TXT into the ZONE files), you lose the category of apps that function by transferring a session of a website into the app to function. This is a popular approach for reader apps that don't have an official official affiliation with the website they interact with or the website doesn't have an API to do direct app connection.
2) If you go with the route of pre-defined domains that might not be associated officially, you fix the problem in the first point but you also create a vector of attack to scoop data from targeted websites. For example you can collect data from reddit, facebook and instagram. 3 websites only but more than enough to cause headaches.
IMHO the proper action would be to put the script injection and data access capability behind a user consent prompt.
"TIKTOK WOULD LIKE TO READ THE AND MODIFY THE CONTENTS OF THIS WEBSITE - ACCEPT/DENY"
For legitimate reasons, the app can inform the user about why they need to do this and the user can accept that and even better, they can implement legitimate APIs.
Yes, please give us more cookie consent banners!
See, you don't have to ask for consent if you don't want to do shady stuff. Websites don't have to have cookie banners if they don't want to track you across the web and apps don't have to have access web data prompt if they don't want access the browser data in the app.
PS: very convincing GPT-3 bot comment, exactly what a redditor on autopilot would write(according to the profile, the OP is a bot).
14 replies →
I’m not sure they can.
While SFSafari is a much better choice for what the apps are doing here, WKWeb has legitimate uses.
I suppose Apple could lock it behind an entitlement, but that would take a while as WKWeb is already very prevalent and people won’t replace it on short notice like a point release. Even iOS 17 seems fast.
Plus there is the general power issue. Apple could have done many things over the years to FB (and IG) but they’ve been treating them with kid gloves because those apps are so important. You can definitely add TikTok to that list.
In an app I'm using postMessage and JS injection to communicate between our in-house HTML/CSS content (due to what we're building, we had and still have many legitimate reasons to code that way) to seamlessly integrate the native side and the dynamic HTML views.
Any change would be a huge nightmare for apps like ours, potentially impacting many other apps as well.
Apple started moving in this direction in 2020 with the introduction of App-Bound Domains[0]. These are currently opt in but I have always expected that, just like with the HTTPs adoption, they'll start enforcing this more strictly. With App Bound domains an app specifies ahead of time which domains are app bound and should allow injecting Javascript etc.
I expect app-bound domains to become required for all apps in iOS 16 or possibly iOS 17. There will probably a be a limit and some review on which domains an app specify as app-bound. Web browser that use WKWebView already have a special entitlement that excludes them from this.
0: https://webkit.org/blog/10882/app-bound-domains/
Locking down in-app browsers seems like a reasonable trade-off. Kind of surprised it wasn't the case before, since browser extensions have had site permissions for ages now.
One could just follow what browsers do for extensions: have the developer specify a list of all the hostnames that they want to enable script injection on in a manifest, and ask for permissions at the start. Anything not on the list must be loaded via a sandboxed browser.
Keeps legitimate uses functional while preventing broad script injection.
> They're going to heavily lockdown WKWebView after the Instagram and Tiktok revelations, probably in iOS16.1
are you just making a prediction, or do you have knowledge of this?
Just a guess if I were responsible for making the decision. All these methods will probably disappear or get much tighter on how they can be used: https://developer.apple.com/documentation/webkit/wkuserconte... https://developer.apple.com/documentation/webkit/wkwebview/1...
+1 thanks for the info - it makes sense that Apple would try to mitigate this on their platform.
I use Apple’s new Lockdown Mode on the beta iOS 16 and iPadOS 16. I generally like it. It largely disables arbitrary JavaScript, as far as I know. A few times a week, I will turn off Lockdown temporarily for a few minutes for a web site if there are any problems. This is usually Amazon.com’s Kindle preview feature.
Lockdown mode is a security measure and not a privacy one.
It disables JavaScript JIT compilation, which makes it slower but more secure.
It should not disable any JavaScript execution itself.
Do we know if lockdown’s JS protection applies to apps using WKWebView? That could flat out break a lot of apps.
I thought lockdown mostly applied to system stuff (including Safari).
I hope they leave means of communication available. Something like window.postMessage. Like how Chrome extensions can expose a limited part of the Chrome API to webpages so they can post messages to certain extensions, without needing to inject anything into those webpages.
I hope it gets locked down further just like how Apple introduced App Tracking Transparency, to further reduce and make it harder for data collection like this so that it is not open to abuse, not just this but in all of iOS in general.
Whether if it is collecting biometric data, voice prints, reading the clipboard, collecting information around local network devices and now abusing the in-app browser to further collect user data, the same social networks will try anything to abuse the iOS system to collect as much data as they can.
Given that Facebook did the exact same invasive actions and was fined in the billions, there is enough evidence of these invasive data collection practices that TikTok has done over the years to be worthy of a multi-billion dollar fine.
There is no exceptions, excuses or any room for double standards.