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.
Apple „just“ need to enforce it.
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.
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.
"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.
PS: very convincing GPT-3 bot comment, exactly what a redditor on autopilot would write(according to the profile, the OP is a bot).
https://news.ycombinator.com/user?id=Traubenfuchs
I also think that the bot did a good job here.
In the case of UIWebView/WKWebView (AKA the browser within an app that can access web data), this can be implemented by Apple as any other data access prompt like location data access or App tracking access for example.
Apps like to track user data like user location too but thanks to Apple's implementation of prompting the user first, they need to have a legitimate reason to request that information.
So, I guess, apps can claim that they need to access web data to provide some service(like widget, sign in session to transfer the login into the app etc) and users who want that can accept the requests and those who don't can have peace of mind.
Edit: the confusing part was “the contents of this website”, which made me think of per-site basis.
That's a really low quality discussion, so I will leave it here. Can we please not turn HN into reddit? If you have an argument write an argument instead of trying to insult people(or don't write anything, we don't have deficiency of this type of attitude).
By the way, if you think another user is a bot (or they claim so themselves), from the guidelines:
> Please don't post insinuations about astroturfing, shilling, bots, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email [email protected] and we'll look at the data.
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.
Any change would be a huge nightmare for apps like ours, potentially impacting many other apps as well.
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.
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.
are you just making a prediction, or do you have knowledge of this?
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.
It disables JavaScript JIT compilation, which makes it slower but more secure.
It should not disable any JavaScript execution itself.
I thought lockdown mostly applied to system stuff (including Safari).
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.