Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

See what JavaScript commands get injected through an in-app browser

krausefx.com

Post reply on HN
Print view View original

231–240 of 330 posts

Re: See what JavaScript commands get injected through an in-app browser

#231

Post by rvz »

deminature wrote: post #208

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

Re: See what JavaScript commands get injected through an in-app browser

#232

Post by hn_throwaway_99 »

deminature wrote: post #208

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.

Re: See what JavaScript commands get injected through an in-app browser

#233

Post by kQq9oHeAz6wLLS »

paxys wrote: post #113
kungfufrog wrote: post #65

So let me get this straight: If I click a link inside the Instagram app, that for whatever reason takes me to gmail or microsoft or wherever that requires authentication, and I decide to login on that page so I can view the link in question, Meta and TikTok are able to capture my credentials and ingest the data back in to their metrics and analytics pipelines? Is that even f*cking legal?

Everything is legal until it is explicitly made illegal. And I can assure you no US politician can understand more than 3 words in that paragraph you wrote, let alone make laws to regulate it.

Hasn't stopped them in the past, usually completely ineffectively.

Re: See what JavaScript commands get injected through an in-app browser

#234

Post by lvturner »

daniel_iversen wrote: post #185
lvturner wrote: post #167

Earlier quoted context omitted.

Amusingly, TikTok isn't available in China - only DouYin, which is similar but separate. I'm not 100% sure on this at this point, but I think if Facebook/Google/etc were willing to do the same they would be allowed in China too, but as it stands they can't/won't comply with Chinese law (I may be mistaken on this, haven't read up on the topic in quite some time)

Yeah, and both TikTok and DouYin are owned by ByteDance. In fact didn't Google on occasion create a crippled/censored version of its search for some time in mainland China or Hong Kong or something?

I think they did, but then found it too much effort to maintain (I think there was also some hacking scandal? I forget)

For what it's worth HK internet presently uncensored, though ironically TikTok pulled out of the HK market as they felt it was too expensive to comply with Hong Kong laws given the size of the available market here.

DouYin is still available in HK though -- not sure if DouYin is available in US/Euro market or not??

Re: See what JavaScript commands get injected through an in-app browser

#235

Post by systoll »

jacooper wrote: post #87

Why on earth is this even allowed in IOS in the first place ? Why do apps have the ability to control and change the browser? Instead of using the default one? Like android.

Android is in basically the same situation.

Obviously both Android & iOS let you open things in the default browser.

iOS has SFSafariViewController, which more-or-less corresponds to Chrome Custom Tabs on Android. These basically make a browser UI that is in the of the app for the purposes of multitasking/app-switching, but which is controlled by the browser. Devs can't inject code into these.

And both have WebViews, which let the dev do more-or-less whatever they want inside their own app.

Re: See what JavaScript commands get injected through an in-app browser

#236

Post by kitsunesoba »

hn_throwaway_99 wrote: post #232
deminature wrote: post #208

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.

Re: See what JavaScript commands get injected through an in-app browser

#237

Post by DecoPerson »

deminature wrote: post #208

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

Re: See what JavaScript commands get injected through an in-app browser

#238

Post by fsckboy »

deminature wrote: post #208

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.

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

Re: See what JavaScript commands get injected through an in-app browser

#239

Post by MBCook »

eyelidlessness wrote: post #230
MBCook wrote: post #225

Earlier quoted context omitted.

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.

I’m more of GP’s mindset, but I’ve often wondered how many people would become lost the way you describe if my preference was the default. I have the benefit of knowing distinctly when I’m navigating from app to web, but I can relate to being disoriented navigating between different types of views within a given app. There’s the tiny “back button” in iOS that takes you back to an app which triggered an app context sw…

I’m with both of you, but it is a real problem.

I know someone who has no problem getting back to the app they were in, but doesn’t seem to know about/use tabs on their phone. Since tabs don’t auto-close by default they often have hundreds of them by accident that opened one by one when they followed a link in another app like Messages or Mail.

I’m pretty sure they know about tabs on the desktop, though I’m not sure they use them. On the phone it seems to be just a little too “out of sight out of mind”.

Re: See what JavaScript commands get injected through an in-app browser

#240

Post by vivegi »

In-app browsers are a huge mess and security/privacy nightmare. Browsers implement a security sandbox. In-app browsers break and circumvent this threat model in nasty ways. I hope this gets the same attention as cross-site scripting (XSS) attacks and browser engines implement strict countermeasures by default locking WebViews to the equivalent of an Incognito/InPrivate tab.
Post reply on HN