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

261–270 of 330 posts

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

#261

Post by hackernewds »

paxys wrote: post #94
mark_l_watson wrote: post #88

I can’t quite figure this out: it sounds like if you click a link in someone’s TikTok content, the in app browser can read any text entered on that site using the in app browser. Does just not entering any keyboard input in the in app browser mitigate this? Does Apple Lockdown help in this situation? I thought that typical TikTok use just involved scrolling and watching video content. Are users who only view content…

They do a lot more than that. > TikTok iOS subscribes to every tap on any button, link, image or other component on websites rendered inside the TikTok app. > TikTok iOS uses a JavaScript function to get details about the element the user clicked on, like an image (document.elementFromPoint) And that's just a sample of the calls the author was able to find.

This seems perfectly reasonable btw. The extension to the in-app browser existing and logging non-tiktok browsing is troublesome.

Perhaps Apple should ban in-app browsers? But what about Safari? Apple itself collects and benefits from Safari data for its ad product

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

#262

Post by mattmanser »

mrtksn wrote: post #259
Traubenfuchs wrote: post #258

Earlier quoted context omitted.

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

Sure. The "bot" ridiculed your idea for good reason.

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

#264

Post by mrtksn »

mattmanser wrote: post #262
mrtksn wrote: post #259

Earlier quoted context omitted.

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

Sure. The "bot" ridiculed your idea for good reason.

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

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

#265

Post by elaus »

martinsuchan wrote: post #263

I'm just curious, there are plenty of 3rd party full-featured browsers based on WKWebView that are injecting tons of JavaScript into all pages and basically doing the same as in-app browsers. So what's the difference?

The article actually mentions those:

> [...] they use JavaScript to offer some of their functionality, like a password manager.

Basically a 3rd-party browser needs to use JS to offer any features or real benefit over simply using Safari. But as a TikTok user you have no benefit when all links open inside the app with tons of custom JS injected that seems to be mainly for tracking you.

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

#266

Post by leodriesch »

mark_l_watson wrote: post #213
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.

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

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

#267

Post by greggman3 »

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.

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.

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

#268

Post by jollybean »

thalassophobia wrote: post #168
jollybean wrote: post #83

Earlier quoted context omitted.

"had they not made sweeping changes to their economy and assured the world that they would compete on a fair playing field, rules that they still (mostly) have to follow today. " This is really quite false. Rules are broken all the time, they are difficult to arbitrate, and often they are not. The CCP requires foreign entities to surrender critical IP, then hand it off to a state-backed competitors, they don't allow…

>Neither would Russia. Facebook, Whatsapp and Instagram worked pretty well here, to the point where almost every teenager has an Instagram account, so I think this is proven to be false. The only reason Instagram is banned now is because of the ability to use it to spread pro-Western propaganda instead of pro-Russian one.

Yes, they banned some and restricted others, that's my point.

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

#269

Post by adrianh »

MBCook wrote: post #225
netheril96 wrote: post #159

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.

The solution here is for the company to make a proper help page explaining that, then respond to all the support emails with a link to the help page.

No need to poison the well for everybody else due to wanting to avoid a "support burden."

My own product/company has a few common issues like this, and the help page strategy works fine. Answering emails for these types of things is not a big deal as long as you have stock answers/pages prepared.

Post reply on HN