7 ms·
Sorry but I'm not sure you understand how sideloading works on Android. You have to enable it explicitly for any app you want to sideload from (eg. your browser
by aweb 6y ago
Sorry but I'm not sure you understand how sideloading works on Android. You have to enable it explicitly for any app you want to sideload from (eg. your browser for a downloaded app, or an alternative app store like F-Droid). Afterwards, every app installation still needs to be manually approved and thus cannot be done hidden in the background. Seems pretty safe to me while still allowing more freedom to power users.
- JumpCrisscross 6y ago> You have to enable it explicitly for any app you want to sideload from Problem is e.g. Facebook will immediately require side loading so they can install all manner of spyware that wouldn’t make it through the App Store’s vetting process.
- Wowfunhappy 6y agoNo they won't. Facebook is in the Play Store on Android, and they used the Windows 10 Store up until they abandoned their desktop client. They want the largest user-base possible, which means they want finding and installing their app to be as frictionless as possible.
- dfee 6y agoHere’s a link to the Onavo app from Facebook https://en.m.wikipedia.org/wiki/Onavo#Privacy_concerns https://en.m.wikipedia.org/wiki/Onavo#Privacy_concerns
- onli 6y agoNo mention of sideloading in that link, instead it mentions a Play Store and an App Store listing. It's almost as if there is a lot of dangerous crap in those stores as well...
- ipython 6y agoExpand the “Facebook research” section.
- Wowfunhappy 6y agoI have conflicted feelings about "Facebook Research", but where I always end up is this: if citizens of a free society want to give away their data in exchange for a couple extra dollars a month, they should have that ability in a free society. People can and should be educated of the risks so they can make informed decisions, but trying to stop it is ultimately a fruitless errand (Even as Facebook is a pile a scum, don't misunderstand me.) And it's all somewhat beside the point, isn't it? Facebook Research was usable on iOS. By the time Apple put an end to it, the backlash had become so significant that Facebook pulled the program from Android anyway.
- saagarjha 6y agoThe real problem I think is that it is extremely hard to get users to understand what exactly they are signing up for when they do that…
- MarkSweep 6y agoThis assumes that side-loaded applications have less restrictions than store apps. The same sandbox restrictions and permission prompts could be applied to a side-loaded app as a store app.
- dogma1138 6y agoI have android devices too I know that all you need to do is tick a box, and there are apps on the Google Play Store that literally direct you to do that. Not to mention once that is a possibility the system is less secure, you btw can also side load apps without that tick box if you know what you are doing especially if developer options have been enabled.
- danudey 6y ago...and then a ton of apps decide "screw the app store, I'm going solo!" and people start enabling sideloading so they can try those apps, then sideloading becomes normalized and malware starts to spread without Apple having the ability to prevent it. Users who have issues with apps start hitting up Apple's support lines, and they start getting pissed off when Apple says "Sorry we can't help you, go talk to the developer. Not that we know who they are, and maybe you actually don't either, but either way you're on your own." Plus, developers lose access to a lot of Apple's functionality, like the fact that XCode can upload LLVM bytecode so that Apple can re-optimize through new or updated LLVM backends to deliver optimized versions for new platforms, etc. Suddenly, all the goodness that's "baked in" to the iPhone experience is gone, and the whole system starts looking like an inconsistent mess compared to the way it was before. I wonder if some kind of hybrid approach would work; for example, a workflow like this: 1. Developers develop locally as usual 2. Developers upload to Apple via XCode as usual 3. Apple does its standard automated checks (private APIs, etc) 4. The developer can file for that app to be held "off the store"; this is rejected by Apple for some reasons (like private API usage, malware, etc.) but generally approved. Apps which do this likely lose access to some system APIs (e.g. iCloud storage, IAP) but it's a tradeoff. 5. The developer can now get an App Store link which they can give to users to find their app on the store. This is the only way to find the app; it doesn't appear in lists, search, "top paid", features, or anything of the sort. 6. Users get an app that isn't (overtly) malicious and won't definitely break in future OS updates, developers get the infrastructure benefits and automatic updates, Apple can wash their hands of any downstream issues because they know for certain that the user arrived via the developer and can make that clear to the user ("if you have problems, go talk to them. If they're misbehaving, come talk to us.") This would make the value proposition for most developers pretty clear, but for huge entities like Epic or Microsoft, they can just bypass the system because people can come to them directly.
- easton 6y agoI mean, that hasn’t been a terrible problem on macOS. Require doing a csrutil style procedure to disable code signing requirements, and that’d be enough to scare off 99 percent of people. By default, only allow App Store and Apple registered developers (or even just the App Store).