221–230 of 330 posts
I always hate in app browsers and always reopen them in Safari, for UX reasons. Now I hate them even more, with even stronger reasons.
It’s quite clearly a user hostile decision, but they presumably did it for all that activity tracking they can do.
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.
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.
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.
+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.
I thought lockdown mostly applied to system stuff (including Safari).
I always hate in app browsers and always reopen them in Safari, for UX reasons. Now I hate them even more, with even stronger reasons.
I’ve heard of developers adding the in-app thing despite hating it personally just to reduce the support burden.
Can websites protect against this through the use of Content Security Policy (CSP) [0]? [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
It might make it much harder to inject stuff, but since the apps control all aspects of the embedded browser and CSPs are enforced by the browser, they could feasibly just disable CSP enforcement and have the embedded browser ignore the CSP.
Now you could go really far to get around it. Request resources yourself and hand them to WKWebView directly so no CSP is served but that’s not going to be easy. You’d have to scan for any other resources that might get loaded, pull those, inject them correctly, etc.
Seems like it would be very fragile.
Can websites protect against this through the use of Content Security Policy (CSP) [0]? [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
CSP protects against an XSS threat model, but once the attacker has control of the browser itself, defeating CSP is trivial since you can just decorate scripts with the nonce string (or equivalent).
I feel like there is a litany of the internet: "that which can be collected will be." That's been true since the beginning. What continues to surprise me is that people think only "bad guys" do it. This is why we continue to lock down browsers and provide ever narrower permission classes.
What surprises me is that this is technically possible on iOS.
But as we know, that which can be used by advertising/tracking people will be used by them.
Is there anything website owners can do about this? I've been many web games, including my own, embedded and surrounded by adverts (see dordle,io, wordle-unlimited,io). Simple permissions like x-frame-options won't work since they're proxying everything onto the same origin. I've thought about checking after a few minutes if the user is on an embeded DOM then asking them to head over to the real site.
No, the browser is the "user agent" and decides what to do. The problem is that in this case TikTok is the browser and does what they want, not what is good for the user. It is actually quite a hard problem. The App Store does ban third-party browser engines so maybe they can add a restriction that apps can only inject code into verified domains. Surely a few legitimate use cases would be lost (IDK apps that let you…
It makes it so I can easily select and refine which HTML element I want to add to a custom blocking list.
I think that would be impossible without this.
I always hate in app browsers and always reopen them in Safari, for UX reasons. Now I hate them even more, with even stronger reasons.
Unfortunately I think they’re very popular with unsophisticated users. I’ve heard stories about companies getting a ton of support emails because someone clicked on an article link shown in $someApp, the user was booted to Safari, and didn’t know how to get back to where they were before. I’ve heard of developers adding the in-app thing despite hating it personally just to reduce the support burden.
There’s the tiny “back button” in iOS that takes you back to an app which triggered an app context switch, but it’s barely noticeable and barely reachable on most current iPhones. I swipe between apps even when I do notice that. But I’m not sure how widely it’s even known you can swipe between apps.
(For anyone reading who doesn’t know, if you have an iPhone without a home button, you can swipe left/right on the space right at the bottom of your screen, where you normally would swipe up, and it’s like the cmd/alt+tab default. You can also do this on the URL bar in Safari to switch tabs, if you stick with the default bottom URL bar.)