4 ms·
With the exception of either investing time into targeted request black-holing or disallowing apps from contacting the outside world entirely (which would produ
by munk-a 5y ago
With the exception of either investing time into targeted request black-holing or disallowing apps from contacting the outside world entirely (which would produce a pretty crappy AirBnB experience) I don't think this is really reasonable. Most useful apps have some legitimate reasons to talk to servers so blocking access before the app can get it (similar to how browsers block access before the site can get it) seems like the most reasonable approach. And websites don't need to inherently communicate with a remote server - there are a bunch of web tools out there that download a bunch of JS and then essentially run in local mode without ever sending that data home... yes the original stuff is coming from a foreign source but that's the same as Apps - the acquisition method is just different (and a lot more prone to abuse I'll grant you).
However, pretty much every useful app you're using is calling home for some moderately legitimate reason - so I don't think it's helpful to differentiate the two classes of executables based on remote asset usage.
- Retric 5y agoThe majority of Apps on my phone have zero reason to communicate to the outside world. A calculator, standalone game, etc should function without network access and if it doesn’t then delete the app and get something useful when the network is down. Honestly, if I can’t block network access I don’t see the value in downloading a AirBnB app or just about any other app companies want me to install.
- sneak 5y agoPeople prefer native user interfaces to APIs over the UI of web apps accessing those same APIs. A few years ago when phones were slower the difference was much more stark. It's straight amazing what can be done in a webview now.