3 ms·

I have been using social media strictly through mobile Safari for a month now and my ads have gotten so insanely irrelevant. It made me wonder what data they we

by kristo 3y ago

I have been using social media strictly through mobile Safari for a month now and my ads have gotten so insanely irrelevant. It made me wonder what data they were getting from the app that they don’t have access to any more

chatmasta 3y ago
The divergence between mobile Safari and in-app browsers is really frustrating. As far as I know, it's not possible to install content blockers that work within in-app browsers, which means that every Social Media or Newsreader app with an in-app browser is its own separate cookie sandbox exposing me to tracking scripts that I'd have otherwise avoided with content blockers in Safari. Not to mention the app itself has full access to the DOM of every page in its in-app browser. I know I can use PiHole or similar, but it feels like like a deceptive move from Apple, possibly with the motive of creating an incentive for developers to build for the app store where it's harder to block ads. Some apps are friendly about it. I appreciate that Apollo gives me the option of which browser to use for opening links, and that it distinguishes between "in-app browser" just as it does between Chrome, Firefox and Safari. For a long time I've had an idea for an app that can take advantage of this, but for the user's benefit. Imagine a newsreader app with modular news sources, where each "source" is a client side script that runs within the in-app browser, to navigate to a URL and then "parse the content" by getting rid of ads, paywalls, etc. So unlike a typical RSS feed reader app that makes you rawdog ten articles in an in-app browser before you hit a paywall, it would inject user-defined scripts into the in-app browser to make sure you never see the paywall in the first place. Philosophically, it's still a web browser, but with a more rigid interface for browsing between websites. The client is in control. It would be like Gopher for the modern age.
- scarface74 3y ago
  > The divergence between mobile Safari and in-app browsers is really frustrating There are two separate web views that apps can use. SFSafariViewController - content blockers will work with this. It’s an out of process web view that the host app has very little control over. WKWebView gives the developers a lot more control over the web view and it runs in process. Content blockers don’t work in these views.

by kristo 3y ago

chatmasta 3y ago

The divergence between mobile Safari and in-app browsers is really frustrating. As far as I know, it's not possible to install content blockers that work within in-app browsers, which means that every Social Media or Newsreader app with an in-app browser is its own separate cookie sandbox exposing me to tracking scripts that I'd have otherwise avoided with content blockers in Safari. Not to mention the app itself has full access to the DOM of every page in its in-app browser. I know I can use PiHole or similar, but it feels like like a deceptive move from Apple, possibly with the motive of creating an incentive for developers to build for the app store where it's harder to block ads. Some apps are friendly about it. I appreciate that Apollo gives me the option of which browser to use for opening links, and that it distinguishes between "in-app browser" just as it does between Chrome, Firefox and Safari. For a long time I've had an idea for an app that can take advantage of this, but for the user's benefit. Imagine a newsreader app with modular news sources, where each "source" is a client side script that runs within the in-app browser, to navigate to a URL and then "parse the content" by getting rid of ads, paywalls, etc. So unlike a typical RSS feed reader app that makes you rawdog ten articles in an in-app browser before you hit a paywall, it would inject user-defined scripts into the in-app browser to make sure you never see the paywall in the first place. Philosophically, it's still a web browser, but with a more rigid interface for browsing between websites. The client is in control. It would be like Gopher for the modern age.

scarface74 3y ago
> The divergence between mobile Safari and in-app browsers is really frustrating There are two separate web views that apps can use. SFSafariViewController - content blockers will work with this. It’s an out of process web view that the host app has very little control over. WKWebView gives the developers a lot more control over the web view and it runs in process. Content blockers don’t work in these views.