Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Only Instagram? Every app maker who makes an in app browser can see what you do, that’s the point of embedding it. And why not? You arrive there because of a link in the container app you clicked on. They want to see what you do with the link they gave you. Otherwise only Google/Apple can see what you do with it. Someone can see what you do with the link no matter what.


> They want to see what you do with the link they gave you.

Except they didn't give it to me, my partner/sibling/parent/friend did, in a message sent through their app. We should expect that kind of interaction, to not be tracked; should expect, but obviously can't expect it today, these news are not surprising.

This is just one more aspect of their tracking that may be non-obvious, and that it's good to know about.


The problem is that users cannot tell if they are being spied upon or not as long as they use in-app browsers. Avoid them! Go web apps instead of native apps for better privacy in general.

Regardless, i don't consider it to be acceptable behaviour by Instagram to inject their tracking into all web pages i access through their app just because they can.


There is a UX benefit I've found, and maybe the app folks felt it as well.

Android has a nice universal "back" button which can close an opened tab and return you the app that spawned it. iOS tried a similar option with a "go back to App" link at the top left, but it doesn't fully close out browser tabs spawned by the app. Safari has gotten smarter about this, with browser "back" buttons closing spawned tabs in many cases, but not all.

So, in all those emails where I click to launch a browser to "read more" but see no reason to keep it around, the embedded browser actually plays a maintenance role: no need to get rid of those tabs that were just a funny comment I wanted to see but never need to keep.

Yes, the tracking is disappointing, but the UX of not having a zillion tabs open (and in old iOS version, hitting tab limits) makes my life easier.


Not necessarily. If they’re using a WKWebView, they can’t see what you’re doing, which is why Safari Autofill remains enabled in some but not all app-embedded web views.


This is not correct. WKWebView can be made to report back clicks and URL loads, inject JS etc. Eg here is the doc for the navigation delegate: https://developer.apple.com/documentation/webkit/wknavigatio...


Only SFSafariViewController prevents that. Devs still can inject javascript through WKWebView.


Thanks for the correction; I swapped the two in my head and you’re right.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: