6 ms·
You know, I really don't mind the idea of something like this (which is really one of the added benefits of an app store), but I really wish there was a way to
by kbenson 8y ago
You know, I really don't mind the idea of something like this (which is really one of the added benefits of an app store), but I really wish there was a way to add different trusted parties that could sign apps. Sort of like Android where you can add third party apps, but actually go the full distance and allow separate app signing authorities, and while it should be covered in numerous warnings about not adding another signing authority without complete trust and nobody should be walking you through it, it shouldn't be terribly hard to do. If I want to install Amazon App Store apps instead of Android apps (or vice versa), that shouldn't require me disabling security mechanisms on my phone and installing a separate program to manage everything.
I guess I basically want the web certificate system but much more selective, and don't ship a bunch of trusted ones by default. Of course there's basically zero chance of Apple or Android doing this without outside pressure since it's essentially them giving up the monopoly they have over their ecosystems.
- lern_too_spel 8y agoWhat you described is essentially how Android works today. You whitelist specific apps, like the Amazon App Store or F-Droid, as allowed to install other apps.
- kbenson 8y agoThat's interesting. The Android on my phone mus be old enough that it isn't using that, or it's changed since I last bothered with it. Last time I did anything with it was a couple years back with the Humble Bundle app, and I believe you still had to toggle in the settings to allow untrusted sources for that to function. Good to know there's been some progress on this.
- coffexx 8y agoThe play store and samsung store are able to install and update in the background without the user doing anything. The same is not true of any 3rd party app store you whitelist. Explicit consent is required for every apk install or update. Which is a bummer if you want to compete with the baked in store apps that "just work" and keep things up to date.
- threeseed 8y agoIt's nothing to do with monopolies. It's just that it's an unworkable idea. The worst a website can do is trick the user into downloading something. The worst an app can do is steal their data, capture video from their mic/camera, wipe their computer, turn it into a DDOS bot etc. It's night and day. And so trusting third party certificate issuers who currently don't verify websites or their owners and having them now certify apps is a pretty big leap.
- kbenson 8y agoYou misunderstood what I was suggesting. I'm not saying existing certificate authorities should sign apps, but that allowing a trusted authority to sign and distribute apps that a user could opt in to would be beneficial. Think yum/apt repo signing keys, and how if you add a third party repo you can require the public key signatures to match, except tied into the OS much closer. I used the CA analogy because vastly more people are familiar with that than the intricacies of open source package management for a few distros.
- scarface74 8y agoWe already see how slimy so called trusted businesses are like Google and Facebook are by convincing users to install privacy invasive apps using the enterprise developer program. Who are users suppose to trust? Back in the day users also trusted SourceForge....
- dwaite 8y agoEven technical users have a limited capacity to properly vet what an authority should be allowed to do. Not to mention, this becomes a very heavy-handed choice to the user (as people already see on android), like "either allow this new app version to now root your phone, or you can't use this service at all" The reason we can trust the CA certificates loaded in our browsers have proper processes and operate transparently is that the browser makers leverage those certificates being preloaded as bargaining power. Would we have the opportunity to retain that sort of power in this decentralized world? Or do we start seeing the "essential" apps move out of the store and doing things like background monitoring of the user?
- floatingatoll 8y ago99.9% of users are not capable of making an informed decision about whether to approve a third-party app store. That you are is statistically irrelevant to the security of their platform. Fortunately, Apple has to date and clearly intends to continue offering a way to disable this functionality for the "statistically irrelevant" subset of their users that have good reasons to. EDIT: Users, given a way to sideload, will always be taken advantage of. At least the enterprise program lets them be cured quickly. https://www.wired.com/story/exodus-spyware-ios/ https://www.wired.com/story/exodus-spyware-ios/
- kbenson 8y ago> 99.9% of users are not capable of making an informed decision about whether to approve a third-party app store. There's a difference between "people are stupid so let's prevent them from doing stuff that might cause problems, even if sometimes it's useful" and "people are stupid so let's discourage them from doing stuff that might cause problems." > Fortunately, Apple has to date and clearly intends to continue offering a way to disable this functionality for the "statistically irrelevant" subset of their users that have good reasons to. For their OS, yes. But the trend of locking the desktop/notebook offerings down to be more like their phone offerings is clear. Maybe there's also drift from their phones/tablets to be more open like their offerings and I'm missing it, but if not, I'm pretty sure I can see where this will eventually end (if Apple gets their way).
- floatingatoll 8y agoApple offers many ways to self-issue mobile apps, but they all have restrictions that prevent them from being used for malware attacks. That’s how they were able to globally kill that Facebook VPN scam app that used Enterprise Certificates, and that’s why all non-enterprise app distribution methods carry an expiry: either you’re a free sideload developer (one week), a TestFlight user (twelve weeks), or an enterprise user (no expiration unless your enterprise earn a revoke for distribution to the public). The scenario you describe, where my pocket brain can be enrolled in a third-party App Store, is hostile to my security requirements for my pocket device and I’m glad Apple prohibits it.
- djsumdog 8y agoLike, oh say, the package repositories on any running Linux system? Yum/Zypper, Apt .. they all allow you to add a 3rd party key and repo address. Gentoo allows overlays. There are teams like Jenkins that maintain their own repos. I maintain one myself (https://repo.bigsense.io https://repo.bigsense.io). Apple's AppStore and Google Play are bastardizations of the concept of a package repo. Instead of applications and their dependencies, Google/Apple distribute monolithic executable (duplicating shared libraries for every app) and disallow anyone else to have a trusted cert/3rd party repo. There's F-droid of course on Android.
- dwaite 8y agoThe technical problem is that to protect system and user security and privacy, third party signed apps would be very limited. This is under the assumption that most users have a limited capacity for understanding the security and privacy ramifications of unfettered access by apps. (Basically - if you can understand this, you already know how to side-load apps onto Android/iOS devices) For instance, you might have a choice to read-only access to the filesystem and user hardware, or be allowed network access. Without a static policy, the only choice that someone like Apple or Google would have to rampant abuse would be to blacklist the 3rd party key. This might mean blacklisting an entire repo if the repo owner is not properly vetting apps - which would likely be perceived as way more an abuse of power than the current gate-keeper model. The non-technical reason is that there is zero financial incentive for a company to risk breaking their security model and affect their reputation, just so that other companies have the ability to not do revenue sharing.