6 ms·

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 t

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.

fsckboy 4y ago
> 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?
- deminature 4y ago
  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/wkusercontentcontroller/1537448-adduserscript https://developer.apple.com/documentation/webkit/wkuserconte... https://developer.apple.com/documentation/webkit/wkwebview/1415017-evaluatejavascript https://developer.apple.com/documentation/webkit/wkwebview/1...
DecoPerson 4y ago
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.
mark_l_watson 4y ago
+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.
- MBCook 4y ago
  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).
- leodriesch 4y ago
  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.
MBCook 4y ago
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.
rvz 4y ago
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.
hn_throwaway_99 4y ago
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.
- kitsunesoba 4y ago
  > 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.
- deleted 4y ago
  [deleted]
- rawling 4y ago
  Couldn't you just proxy everything through a host you own?
- manmal 4y ago
  The mechanism you are describing is already implemented and advertised: https://webkit.org/blog/10882/app-bound-domains/ https://webkit.org/blog/10882/app-bound-domains/ Apple „just“ need to enforce it.
pid_0 4y ago
jabbany 4y ago
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.
mrtksn 4y ago
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.
- Traubenfuchs 4y ago
  Yes, please give us more cookie consent banners!
  - mrtksn 4y ago
    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).
    - mattmanser 4y ago
      Sure. The "bot" ridiculed your idea for good reason.
      - mrtksn 4y ago
        Check the profile, I'm not claiming that OP is a bot - the OP describes the profile as a bot. 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).
    - wruza 4y ago
      I understand “us” as users in this discussion, not as site owners. Your idea is cool, but we have no control over who wants what, so we’ll have yet another consent annoyance as a result.
greggman3 4y ago
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.
- mrtksn 4y ago
  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.
deleted 4y ago
[deleted]
can16358p 4y ago
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.
K0nserv 4y ago
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/ https://webkit.org/blog/10882/app-bound-domains/

fsckboy 4y ago

> 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?

deminature 4y ago
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/wkusercontentcontroller/1537448-adduserscript https://developer.apple.com/documentation/webkit/wkuserconte... https://developer.apple.com/documentation/webkit/wkwebview/1415017-evaluatejavascript https://developer.apple.com/documentation/webkit/wkwebview/1...

DecoPerson 4y ago

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.

mark_l_watson 4y ago

+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.

MBCook 4y ago
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).
leodriesch 4y ago
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.

MBCook 4y ago

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.

rvz 4y ago

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.

hn_throwaway_99 4y ago

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.

kitsunesoba 4y ago
> 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.
deleted 4y ago
[deleted]
rawling 4y ago
Couldn't you just proxy everything through a host you own?
manmal 4y ago
The mechanism you are describing is already implemented and advertised: https://webkit.org/blog/10882/app-bound-domains/ https://webkit.org/blog/10882/app-bound-domains/ Apple „just“ need to enforce it.

pid_0 4y ago

jabbany 4y ago

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.

mrtksn 4y ago

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.

Traubenfuchs 4y ago
Yes, please give us more cookie consent banners!
- mrtksn 4y ago
  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).
  - mattmanser 4y ago
    Sure. The "bot" ridiculed your idea for good reason.
    - mrtksn 4y ago
      Check the profile, I'm not claiming that OP is a bot - the OP describes the profile as a bot. 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).
  - wruza 4y ago
    I understand “us” as users in this discussion, not as site owners. Your idea is cool, but we have no control over who wants what, so we’ll have yet another consent annoyance as a result.

greggman3 4y ago

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.

mrtksn 4y ago
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.

deleted 4y ago

[deleted]

can16358p 4y ago

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.

K0nserv 4y ago

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/ https://webkit.org/blog/10882/app-bound-domains/