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

271–280 of 330 posts

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

#271

Post by wruza »

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

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.

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

#272

Post by wruza »

soheil wrote: post #207
mr_toad wrote: post #148

Earlier quoted context omitted.

If you sold a phone that sent call details back to the manufacturer you’d likely get locked up. Tik tok are not a party to these communications, and they’re not a carrier or service provider. What they’re doing is wire tapping.

What happens in tiktok app is very much tiktok's business and their IP. Are you possibly conflating tiktok tracking its own users within its app with somehow it gaining access to the OS itself and tracking users at that level? That is clearly not happening as far as what is publicly known as much as stories like this want you to believe for it to be the case.

It makes sense when you’re a slick lawyer appealing to technicalities, but in reality users don’t know how their devices work and where borders of an app are. If tiktok was a restaurant, we would talk about its restroom surveillance here. It may not collect too private information like passwords or messages, but the doubt is reasonable.

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

#273

Post by mrtksn »

wruza wrote: post #271
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).

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.

The cookie law is not implemented as a browser function but something that operators need to implement if they want to legally track users. It's an annoyance because each implementation is different and every website wants to track users. If EU went after Web browsers and made them implement the legislation as an API, we would have had tracking prompts like location or camera access prompts and probably kill the tracking industry in a similar way Apple killed App tracking with their tracking prompt.

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.

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

#274

Post by chrischen »

PraetorianGourd wrote: post #247
chrischen wrote: post #198

Earlier quoted context omitted.

Who are you, Xi Jinping? You basically word for word translated their foreign social media policy. Luckily we live in a capitalist free market, free competition ideology and not a heavy protectionist centrally influenced market economy here in the US.

Just because it is a policy of China, and as I am _not_ Mr. Jinping, I will take your word for it, doesn't mean it is incorrect. Some things work well in free markets, some don't. Maybe the ability to influence millions of people is a thing that isn't so great in an unregulated market.

> Maybe the ability to influence millions of people is a thing that isn't so great in an unregulated market.

This is actually the underpinnings of the free market and free speech. It's the ability for everyone to influence everyone else. What do you think speech is? It's the ability to say things that may influence others... and we let people think for themselves whether they should get influenced or not. Once we decide to think for others and choose what's best for other's, we'll have become the authoritarians.

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

#275

Post by wruza »

mrtksn wrote: post #273
wruza wrote: post #271

Earlier quoted context omitted.

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.

The cookie law is not implemented as a browser function but something that operators need to implement if they want to legally track users. It's an annoyance because each implementation is different and every website wants to track users. If EU went after Web browsers and made them implement the legislation as an API, we would have had tracking prompts like location or camera access prompts and probably kill the trac…

I agree and should have thought about it this way, my bad. If there will be a way to deny that system-wide or at most once per app, no issue then.

Edit: the confusing part was “the contents of this website”, which made me think of per-site basis.

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

#276

Post by mrtksn »

greggman3 wrote: post #267
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 wher…

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.

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

#277

Post by latexr »

hackernewds wrote: post #131
bilalnpe wrote: post #108

Apple and Google have guidelines about what apps are/aren't allowed to if they want to be on their app store. "Protecting the user" is supposed to be one reasons they take a 30% cut of all in app purchases. Apple even uses this as an excuse to not allow side loading apps. How are they not blocking this?

Thought Apple was the bastion of consumer privacy. Apparently removing TikTok though is not commercially beneficial for them not to mention the elephant in the room: Apple Finds Its Next Big Business: Showing Ads on Your iPhone https://www.bloomberg.com/news/newsletters/2022-08-14/apple-...

Ads and tracking aren’t inherently linked, it is possible to have one without the other. That’s allegedly what Apple is doing, so it doesn’t clash with the privacy commitment.

Even so, I disapprove of Apple’s forays into ads and wish them swift and hard failures in the area.

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

#278

Post by tinus_hn »

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

Shady stuff like highlighting terms the user searched for. Don’t forget there are of course legitimate use cases.

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 hn@ycombinator.com and we'll look at the data.

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

#279

Post by tinus_hn »

soheil wrote: post #207
mr_toad wrote: post #148

Earlier quoted context omitted.

If you sold a phone that sent call details back to the manufacturer you’d likely get locked up. Tik tok are not a party to these communications, and they’re not a carrier or service provider. What they’re doing is wire tapping.

What happens in tiktok app is very much tiktok's business and their IP. Are you possibly conflating tiktok tracking its own users within its app with somehow it gaining access to the OS itself and tracking users at that level? That is clearly not happening as far as what is publicly known as much as stories like this want you to believe for it to be the case.

Would consider it right for a browser to snoop on every page opened, every link clicked, every character typed and send it to the cloud without informing the user?

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

#280

Post by mrtksn »

tinus_hn wrote: post #278
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).

Shady stuff like highlighting terms the user searched for. Don’t forget there are of course legitimate use cases. 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 hn@ycombinato…

I don't think that another user is a bot, another user has stated in their profile description that they are a bot account randomly posting GPT-3 generated comments. I made no claims but comment on the quality of the bot.
Post reply on HN