- Journal
- Taking a Look at App Installation
Taking a Look at App Installation
Submitted by cassidyjames on Wed, 10/12/2011 - 01:22The lovely act of balancing security with convenience; it's something that must be done every day by many different people. Security companies try to figure out how to keep their clients secure while not causing major inconveniences. Airports (should) want to keep passengers secure while preventing inconvenient and embarrassing searches of every single person. Software developers must keep their users safe while not making their lives hell. But who decides what's an acceptable trade-off, and how?
Last week, we published the elementary Council meeting notes, as we do every week. However, something was different; a single item sparked a massive amount of chatter, debate, and healthy discussion in the comments. It was the "Disable Installing Debs by Default" item, which is marked as "hold off" on a final decision due to the necessary discussion regarding AppCenter and how exactly it will work.
Opinions around the issue are definitely mixed. Some commenters seemed to be indifferent; they support it so long as there's still a way for the more technical users to install potentially insecure and untrusted .deb files. Others pointed out that they think users will need to install .deb files all the time, and that not providing a way to do so out of the box was inconvenient. Some think users who need to use .debs should simply use the command line, others think they shouldn't ever need to use .deb files. In short, different commentors have different visions.
In general, the Council is leaning towards the affirmative side of the idea; that is, we believe it provides increased security for everyone with an necessary trade off of "inconveniencing" a minority of users. However, keep in mind that no final decision has been made and that the Council is waiting to make a final decision until the greater vision of AppCenter begins to play out. We are also reading through all of the comments made on the Journal to figure out the best decision. Many of the Council members are replying to the thoughts of our readers and spurring discussion while sharing our views and addressing any concerns commenters have.
Arguments For and Against
In the interest of increased thoughtful discussion from both sides, I'll try and cover the main pros and cons here. If you have a pro or con that you feel is very important and should be on this list, drop a comment with either "PRO:" or "CON:" at the beginning of it. If there are some I feel are worthy of adding to the list, I'll do so.
Pros
The primary pro for disabling .deb file installation by default is that it prevents users from installing random, untrusted, and potentially malicious apps. Any website can offer up a malicious .deb claiming it's the user's favorite application. By allowing the user to easily install this file out of the box, we'd be allowing them to install malicious software. Since they think it's a different app, they'll have no problem providing their administrator password to install it, giving it full access to their system. Worse, the .deb could actually also contain the real app, making detecting the malicious software more difficult. Even if the app is coming from a trusted website, the website's downloads could potentially have been compromised, giving the user absolutely no indication that the app is malicious.
An additional argument for disabling .deb installs by default is that it encourages users to use AppCenter, the official channel for high quality and trusted software that follows the elementary human interface guidelines. This means the software they get is consistent, works well, and interfaces perfectly with the rest of elementary. In addition, it means they no longer have to use Google as their app store, somehow just know that a .deb means it'll install on elementary, and figure out which version of an application they need based on which Debian, Ubuntu, or elementary version it was made for.
Finally, disabling graphical .deb installation by default means that power users can still use the command line or a dedicated tool to install .deb files. Much like disabling running the default session as root, this is great since it both protects non-power users while still allowing the power users to get work done.
Update: shnatsel mentioned this in the comments and I think it warrants sharing:
[An] app installed as .deb never receives security updates. Keep in mind that everything has vulnerabilities, but in new versions they are not yet discovered. So by installing an app that doesn't receive security updates you're basically putting a tinderbox waiting to explode in your system.
Cons
The primary argument against disabling .deb installation by default is that it prevents users from easily installing popular trusted software from outside the AppCenter. This makes it more difficult for a user to install an application like Google Chrome, some commercial games, or government-provided software for tasks such as taxes. While ideally these apps would be available in the AppCenter, it's not the case at this point in time.
An additional common argument against disabling .deb installs by default is that it adds a step for power users. Instead of allowing developers and power users to install libraries, apps, or tools not available from the AppCenter with a single click, it would require them to install a dedicated .deb installation tool like Gdebi or to use a command in the terminal.
And finally, a common complaint with the disabling of .deb installation by default is that it's different. Users who have gotten used to using other open platforms such as Debian or Ubuntu may be used to being able to install .deb files graphically, and by not providing this capability out of the box, elementary is not what they're used to.
Looking Back
The issue of security versus convenience has been one that every platform has had to tackle at some point; you want to make everything easy for your users while maintaining a secure environment. Let's take a look at how the issue has been tackled in recent history.
Ubuntu
One platform that elementary is often compared to is Ubuntu; we share much of our underlying technologies in addition to having a similar goal: making the best open platform. Because of this, it's easy to look at how Ubuntu has tackled the security versus convenience issue with regards to app installation.
In the past, Ubuntu came with a preinstalled dedicated .deb installation app, Gdebi (referred to as "Package Installer" within the interface, as pictured above). When you clicked a .deb, this app popped up with a description provided by the file, asked you to type in your password, and installed the app as root. It was relatively simple, but didn't communicate any potential security implications, nor was it obvious that you were in fact giving this app's installer root privileges (meaning it could really do anything to your system it wanted).
With Ubuntu's updated Ubuntu Software Center, they've replaced Gdebi and have their one-stop software center display and install .deb files (displayed above). There is a message encouraging you to only install the file if you trust its origin, but otherwise it looks just like screen where you install an app available from within the software center (with the description again coming from the .deb file itself). This makes Ubuntu Software Center the one and only place to install software in Ubuntu, no matter its actual origin. However, it does potentially leave users at risk if they aren't paying close attention to the text on the page.
Mac OS X
Apple's Mac OS X is regarded by many as easy to use and very user-focused. With their latest releases, they've been working at bringing some of the successful aspects of mobile devices back to their desktop OS. As such, they also have their Apple App Store for desktop apps.
Before their app store, users were required to use third-party websites to find and download software. After downloading the app (which could be in a variety of types of packages), the user would either run it in place (without installing it), or manually copy it to their Applications folder. In many cases, apps were provided as a virtual disk image, requiring mounting it virtually then dragging the contents to the user's Applications folder (often with a gimmicky custom Finder window that contained the application and a link to the user's Applications folder, shown above). In other cases, large or involved apps came in an installer package similar to a .deb that only required double-clicking to install. None of these methods ensured the origin was trusted, nor did they explain the risks of installing untrusted software.
More recently, Apple introduced its Mac App Store (pictured above). Similar in many ways to the Ubuntu Software Center, their app store allows installation of trusted and quality apps. However, unlike the Ubuntu Software Center, Apple does not manage installing other software through the App Store; instead, all software from Apple comes through the App Store, and Apple encourages everyone else to use it to distribute their apps as well. Other installation methods (as mentioned previously) are still available, but they're being downplayed heavily. Some even think Apple may drop them all together in future versions of OS X.
iOS
iOS is Apple's operating system found on the iPhone, iPod touch, iPad, and Apple TV. Originally, the iPhone had no third-party app capabilities whatsoever; instead Apple encouraged developers to create mobile websites or "web apps."
After seeing the potential of third-party apps on their iPhone, Apple provided an official app store (obviously capitalizing on it heavily). The iOS App Store (pictured above) quickly became the most successful app catalog with millions of downloads. With an in-depth, strict, and lengthy review process, iOS apps are generally expected to be completely bug-free and non-malicious.
Prior to the iOS App Store, hackers had found a way to circumvent the built-in security that prevented third-party apps to run on the iPhone. Known as jailbreaking, this process is still used today as the only way to allow third-party apps to be installed from outside the App Store, often through an alternative app catalog called Cydia (pictured above). Jailbreaking carries the risks accepted by many power users of lessening security to enable more apps to be installed, however it is heavily frowned upon by Apple, and new exploits must be found whenever an iOS update is made.
Android
Android is a popular open platform for mobile devices including phones, media players, tablets, and televisions. It came out of beta (and became available commercially on a mobile handset) with the Android Market. At first, their market only contained free applications developed by both Google and third parties.
However, Google soon added checkout support, allowing apps to be free or paid. The Android Market (shown above) is very successful with hundreds of thousands of apps and a post-publish review rule where malicious apps can be reported and quickly removed both from the market and users' devices. This means less (in fact, almost no) time from submitting the app until it's available for users, but occasionally allows malicious apps in before they're removed.
In addition to the Android Market, Android also supports the installation of .apk files, packages similar to .deb files. However, before installing one, the user must dive into their phone's developer settings and enable installation from unknown sources (shown above), which can only be done after reading and agreeing to a lengthy and dangerous-sounding disclaimer.
How We Could Do It
You've read the pros and cons. You've seen how it's been done elsewhere. So how, exactly, will elementary tackle app installation? We're still figuring that all out. What I do know, however, is what we've been talking about and how I'd like to see it done. With that said (and keeping the above pros and cons in mind), here is my purely speculative or proposed way of handling app installation in elementary OS.
AppCenter, Front and Center
Looking at trends on the desktop and mobile fronts shows a very obvious fact: app stores are both popular and effective. With this information in mind, I believe it's important for elementary to create an AppCenter where popular, trusted, well-made, and HIG-compliant apps can be downloaded. It should be the go-to place to get apps for elementary.
Existing Apps
However, being built on existing open technologies makes countless more apps available that may not fall into the above category. I feel it's important to keep these available through existing repositories, but to downplay them compared to the apps that were made to fit into elementary from the start. This is where I'm not sure what the best way of displaying or organizing things is (and one of the things that must be discussed before creating AppCenter). Perhaps they could be available inside of AppCenter, but not advertised as heavily as the other apps.
Third-party and commercial apps that are available for Linux-based desktop operating systems could be made available somehow as well, providing an easy and trusted way of installing them from right on the desktop. We'd have to work with these third parties to get them in AppCenter, perhaps standing on the shoulders of Canonical who currently has more leverage with them.
Power Users and Devs
For most users, AppCenter should be the one and only place to look for elementary apps. However, there may be power users and developers who wish to manually install apps from outside the AppCenter. For these users, I feel that we need to provide an approach similar to that of Android. Instead of actively blocking the installation of untrusted apps, we would do so passively by simply not providing a way of installing them by default. We would still allow users to install them manually via the command line or by using a dedicated tool.
Your Thoughts
I've said nearly everything I have to say about app installation; it's time to hear from you. Can you think of additional pros or cons that don't fall into the ones listed above? Do you have other examples of app installations that weren't mentioned? And finally, what's your proposed way of handling app installations? Let us know in the comments; we're all ears.
Cons: There is no way to protect people from doing stupid things other them educating them. As the AVG example, if you do not provide a GUI to install deb packages, a malicious site would provide a terminal instruction on how to install the malicious code with a "single copy pasted line".
The best alternative IMHO is to warn users everytime they open a deb package about the risk of doing that. I really like the idea of a big red window warning him about a potential security risk (the same way chrome does whenever you try to access a https website with an invalid certificate).
There shall be a big red backgrounded warning when that application ins't found on the repository, and a (orange?!) one whenever there already one version on repository, asking the user if he would like to use that version instead, as it will be more secure.
MacOS also have a feature that is related to the metadata on HFS that "tags" files downloaded from the internet with the location where it has been downloaded and warns user on first time they try to open the file as it can be potentially insecure as have been downloaded from the internet.
First of all i want to say a huge thanks to all the developers and people that are helping elementary to be one of the best Linux distros out there.
Now, my opinion about the installation of untrusted packages.
I think the elementary team should do a mix of the pros and cons, as well as learn with the examples, but still be different and better!
So, i think 3rd party package installation should not be restricted by default. I think people should be allowed to do that the same way as today, but a little different.
First of all, installation of packages outside of the AppCenter should not require opening AppCenter itself, given it will be a little heavy-software, and when people (specially power users) want to install things, they want it to be fast! So make or fork a nifty-light package installer, and use it only to install .deb packages outside of the AppCenter. Add the wonderful user interface you already developed as well as all the warnings about security.
Now the AppCenter. No warnings, no root password. Just a nice way to install trusted packages! But i think AppCenter should not be an Application Store only, much like OSX and iOS / Android. AppCenter can and should be "the defacto place" to manage the software you already have installed, no matter the source. So, installation of trusted applications, and management of all of them, separated by third parties (Installed by a .deb, compiled, whatever...) and installed by AppCenter.
I think this is the best way to do things! Don't restrict nothing, that's like a parent prohibiting a teenager to go out on a Friday night! :) But separate things! Every son know their parents are perfectly okay when they go do something perfectly legit and safe (Study to the library, go to school, go to some friend house during the day, etc), but not so good when it comes to do things that can put you in danger somehow. But they allow it anyway. Same thing for elementary application installation problem! :)
CON:
Just take a look at the Ubuntu repositories... Most of the software in there hasn't been updated in years, while still there are newer versions available! Adding a PPA can be just as dangerous, or even more so, than installing a deb package! First they make a good app, everyone adds the PPA and uses the applications. Then, after hundreds of people have added the PPA, they release a malicious update. Bam! Everyone's infected. There are millions of apps out there, and most of them are not available in the Software/App Centre.
If a normal user wants Google Chrome (not Chromium!), and they find that they can't simply install it anymore... What are they going to do you think? Weedle through the command line and learn how to work with DPKG etc., or simply install another OS? This will cause the OS installation to be easier than installing software on it, so that's what I'd do (even though I already know how to do it the other way).
Just look at the Humble Bundle or any other commercial Linux game! Not every dev is going to go through the effort to get their games into the Software/App Centre. If I buy the Humble Bundle (wich I'm going to do today), I want to be able to install those games right out of the box.
Security should never clash with usability!
If you're going to make the Software/App Centre the only place where you can get software from, then people could just as well use some 10-year-old mobile phone where they can choose out of 5 preinstalled apps/games and nothing more than that.
There's another option, why not implement it but in another way? I postes in deviantart an idea coming from Job's last idea. Basically it's a button which the user have to hold down the click by 1.5 seconds (more or less). This gives users some time to think if they want to do that. Here's the link if someone wants to take a look (sorry that mockup it's terrible but I couldn't made it better): http://sheosi.deviantart.com/art/Secure-Button-262892980?q=gallery%3Ashe...
OS X allows non app store executables, Android allows non app store executables, Why? Because ease of use and simplicity, something I thought elementary valued. I honestly see no need to burden the end user for a problem that doesn't even exist in the GNU/Linux community. A simple I understand the risk, Continue window will suffice for inept users.
Let the end user decide. It's up to the designers to make the app store the preferred alternative by choice, not by force.
They both allow it, and so would we! However, Android takes a more secure route and lets the user explicitly decide to install things from outside the trusted sources, which is precisely what we'd be doing.
I think app center would be on priority to make it safe for user but .deb installer should be there to give more freedom to user it can be done by simply putting an option on deb installer which ask user to examine clicking on it will check dependencies and scan that if there is any malicious package in it. If not found than ask for install by doing this user allowed freedom and safety can be maintened
Great article on App Stores:
http://arstechnica.com/tech-policy/news/2011/10/the-iconstitution-how-to...
How about an automatic search for the application in AppCenter when a user tries to run a .deb file? This way the user is prevented from running a potentially insecure app and is guided to a more trusted source for the app if available in the AppCenter. Additionally, alternative apps may be suggested from AppCenter if the same app is not present
really cool idea.but takes some work to take in action
The first suggestions is fantastic! This should be implemented not only in elementary, but in others distros too!
The second suggestion would be pretty hard to implement, but I really like the sounds of the first one!
I strongly support the App installation proposal @ the end of the article! I love the tiers of
1. AppCenter first then
2. larger repos if necessary then
3. CLI .deb / graphical install disabled by default.
IF someone absolutely knows that they need a piece of software that is not in #1 above, and have done the research, and know which software they need, or what version of it, THEN they will also (for the most part) know how to find and install safely from trusted or untrusted sources.
Ironically, it seems like the people who are complaining about untrusted .deb installs (via GUI!!) disabled by default are the same people who can easily accomplish the install via CLI.
I run a technology education program for older adults -- to generalize...They want something that is stable, reliable, predictable, functional, responsive. They want something they can *trust.* When it's finished, elementary OS will be on my parents' computers. I don't want to have to explain to them, "Well, please don't do X or be cautious because you have to do a bit of research and bla bla bla" b/c it starts sounding like the Windows environ they gladly left behind!
Hi all, someone proposed to create a website and the android market (dany boi I think it was), but that already exists .. Take a look at this: http://www.appnr.com. My money is on a eAppCenter with: official repositories (elementary certified apps) repositories of the community and third parties separated into those categories so the user would have more clear that installs .. and also a section of unstable applications (in case someone wants to test a new version) to be executed automatically on Glimpse to avoid damaging the system :) and use the appimages in case the need for a library aplication new or conflict with an already installed (for ex.) and we want to have more than one version of the same program, two different versions of Firefox for example. Another possibility would be for appimages to download to the folder "Applications" (yes, like in mac os xD) are adding their own repository automagically for future updates (of course before all would have to go through an approval or review, or simply put .. a giant icon DANGER!! is flashing on the side xD) ask forgiveness for things so complicated xD and if you do not understand too .. English is not my native language (yep, this is translated with google translator..). And thanks for having such into account the views of users some projects should learn more from you ... :D
I'm really looking forward to Luna and whether .deb's can be installed by default does not really concern me because I rarely use .deb's. Most of the standard applications needed can be installed from the appcenter and if I did need to install a .deb I know what to do
New to forum, so correct me if I am mistaken. Wasn't elementary OS at one time interested in portable app images (http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf)?
The advantages of appimages are:
1. Root privileges are not required, hence improving security
2. Apps can be placed anywhere, which might be helpful if the elementary OS file system is to be reorganized
3. A new "app store" would not be necessary--instead, collaboration with already existing project, perhaps to create a more attractive "front end"
4. Appimages are simple to use-no command line, .deb installer, etc.--making them attractive for the new user
5. Unlike PCBSD PBI system, the are "distro agnostic"--knowledge of debs, rpm's, tarballs, etc is not needed for the end user
That's a good point. I heard something about AppImages once, but I never took it as serious. Hmm... Isn't that something like Zero Install? Nevermind, AppImages seem to be a good choice, and the AppStore should be based on them then.
We were looking at that. However, I believe the disadvantages (and the advantages of having an AppCenter) outweighed it.
Appimages and an "AppCenter" are perfectly compatible. Additional advantages of Appimages vs. deb packages include: 1. a never changing standard core system, so developers, oem's, etc. always have a fixed base to develop against; 2. The "package manager/appcenter" can never break the system 3. the ability of run different versions of the same application simultaneously; 4. No security risks, as appimages run sandboxed; 5. "recommended" appimages could be required to conform to elementary OS interface design, important as elementary OS evolves from a sort of Ubuntu re-spin toward independence
I think the Android approach is the best. elementary OS should have a way to install additional packages graphically, but disabled by default. Only after the user disables the security feature from Switchboard the installation is allowed. But users should have freedom, that is an important part of Linux's spirit. If users want to install unsecure packages or to damage thier systems, let them do it, but obviously warning them.
Idea: how about a setting in switchboard that allows the installation only once? That is, each time you want to install a .deb you should go to switchboard and then requesting an exception (+password). The next installation of a .deb requires the same process. Hopefully this may discourage users to install .debs and use AppCenter. Also, a list of .debs installed should be kept in somewhere, accessible to the user, and also an obvious method to uninstall the package.
Anybody who is following the development of elementary OS or is involved in this debate already knows the risks of installing software from an unknown source. How many people using elementary do NOT understand the risk?
Why worry about a demographic of your user base that does not yet exist? You are trying to protect an extremely small % of beginner users meanwhile you will be pissing off the majority of your users (power users).
On top of that, how many .debs have you come across that are malicious? This isn't Windows, there are NOT alot out there. I don't know this to be an issue on any other Linux based OS.
If you are worried about malicious software why not ship elementary with virus protection like AVG? Cause it will be hard to install AVG if you disable .debs
You should also realize that all those 'app stores' on other systems were developed for other reason than protecting users. They were developed to attract developers to their platforms by providing them with an easy way to distribute their products to users. It also allows users to find apps in one spot instead of searching the web. The only reason .apk installs are disabled on Android is to attract users to use the marketplace. So using 'app stores' as an argument to disabling .debs in order to protect users is not valid. If you want to disable .debs to drive users to the AppCenter then you have a valid argument.
P.S. Love everything you are doing with the OS besides this deb-debacle
"Anybody who is following the development of elementary OS or is involved in this debate already knows the risks of installing software from an unknown source."
Awesome, so they all know how easy it is to install something like Gdebi so they can install these potentially risky .debs.
"How many people using elementary do NOT understand the risk?"
That's anyone's guess, but we have thousands of users and only a handful of people who engage in these discussions. So there's a potentially huge percentage of people that don't.
"Why worry about a demographic of your user base that does not yet exist?"
If developers always targeted at their early adopters, nobody would be innovative. Furthermore, we're targeted at newer users because *that's our audience*. We're aiming to be easy to use for new users. That's not to say we're abandoning our current users, of course. But keep in mind that elementary is very, very, very young. We have a lot of growing to come.
"You are trying to protect an extremely small % of beginner users meanwhile you will be pissing off the majority of your users (power users)."
Again, I believe you underestimate the number of beginner users that are on elementary and will continue to come to elementary. And if our extremely supportive and vocal community of power users gets pissed at us for protecting new users, there's something else wrong.
"On top of that, how many .debs have you come across that are malicious? This isn't Windows, there are NOT alot out there. I don't know this to be an issue on any other Linux based OS."
So first of all "security by obscurity" is now a valid security model? We don't need to be secure because this isn't Windows? And second of all, just because it isn't an issue (yet) on Linux-based operating systems doesn't mean it won't become one. As Linux-based desktop operating systems become more and more of a common platform, they become a bigger and bigger target.
"If you are worried about malicious software why not ship elementary with virus protection like AVG? Cause it will be hard to install AVG if you disable .debs"
There are multiple issues with this line of thought. First of all, it's a reactive approach; it'd let the OS be insecure only to clean it up after the fact. Second of all, REALLY? Design an OS to come with a giant resource-sucking bandaid? Third of all, I'm fairly certain that AVG isn't even made for Linux.
"P.S. Love everything you are doing with the OS besides this moot point regarding the .debs"
Haha, that's great to hear! No matter what decision is made regarding .deb installation, we're still elementary. Thanks so much for sharing your thoughts!
"But keep in mind that elementary is very, very, very young. We have a lot of growing to come."
Exactly why this .deb discussion is a moot point at this time. There are far more important discussions to be had regarding an OS in its infancy. There has been 2 weeks of discussion on this already.
"As Linux-based desktop operating systems become more and more of a common platform, they become a bigger and bigger target."
I agree with this. Time will tell.
"Third of all, I'm fairly certain that AVG isn't even made for Linux."
http://free.avg.com/us-en/download.prd-alf - do a quick Google before being 'fairly certain'.
My comment about AVG was to point out the irony. A user wants to install AVG to protect their system, but the user cannot install the .deb because you are trying to protect the user.
I'm not trying to be rude here but I think you guys are worrying about a problem that isn't a problem. Have you had a plethora of beginner users emailing you and describing their woes about installing a malicious .deb? I'm guessing not. You are over-thinking this whole topic.
Also, your above reply was a little self-righteous. If you are going to facilitate an open discussion try to keep a neutral opinion. Otherwise you may as well just develop the OS the way you want if you have already made up your mind.
I apologize; I was mistaken regarding AVG for Linux. However, I'd like to note that their installation instructions read, "For installation from the deb file (Linux only), use the following command in your shell (accessible for example using the xterm application within your X window system): dpkg –i avg-8.0.{release}-{version}.{platform}.deb". Those directions would still work exactly as stated.
"If you are going to facilitate an open discussion try to keep a neutral opinion. "
I've never pretended to have a neutral opinion; I was fairly clear about stating my thoughts in the Journal entry. However, open discussion can still happen regardless of one Council member's opinion.
I'm not sure the point of this write up was to arrive at a consensus from the community. If you were under that impression, I'm sorry but you are mistaken. The purpose of this writeup is more about gathering thoughts and expanding on something that our community apparently is very vocal about. I think it would be a very sad day if elementary ever starts to design by comity.
I really like elementary. Since Ubuntu went unity it has been utter junk. I just tried 11.10 and found that not only does my wireless (which has worked for the last 4 versions of ubuntu) not work, but there are serious power drain issues. The ubuntu focus on flashiness over usefulness is why I switched to elementary.
That being said...
I know you say you don't design by committee, but you do, the committee is your design group. If your intention is to make a decision regardless of community feedback then what is the point in these posts at all? If you don't want to users to have any say in your design, posts like these should not be made until a decision is finalized. It seems like whenever someone takes issue with one minor change the response is instantly "we didn't make this OS for anyone but ourselves so if you don't like it move along". If that is how you feel about it, fine. But don't you think it's a bit contradictory to try to include the community through these posts and this website, only to tell them they have no say or that they should just use something else?
It's your project Dan, do with it what you will. If you want to attract developers and build a strong community of users maybe you need to reconsider your approach. We are here because you have made something amazing, but please remember that users are just as important as developers when it comes to keeping a project alive.
IDEA: provide a fully graphical means of installing PPA's. Preferably from a webbrowser. A list of trusted repositories (such as firefox aurora, virtualbox) *including a one-click + security warning installation* could be included either as a website, or as part of the AppCenter.
And sometimes, old versions just have so annoying bugs, that you have to update through a .deb to make your app usable for you. So what do you want, maximum security or a working system? I would say a working system first. It's difficult. But if I have to install a deb, then it is to at least 50% because the app in the repos is missing functionality or has bugs which make it not usable for me.
Hm, this is very true; I hadn't thought of that personally. Though the better installations add a PPA to give you updates (like Chrome and some others). But yeah, straight up .debs don't automatically get updates with the rest of your system.
"The primary pro for disabling .deb file installation by default is that it prevents users from installing random, untrusted, and potentially malicious apps. Any website can offer up a malicious .deb claiming it's the user's favorite application."
Great! I would go deeper. You should stop providing an internet browser! It would prevents users from browsing random, untrusted, and potentially malicious web pages! Any website can be a scam claiming it's the user's favorite web page.' Just provide a downloader which eneables us to download a browser.
Pls, DO NOT do that. Do not disable installing deb files which are as you dont want to disable watching web pages.
Yeah, he's right. And when you're at it, why not disable the use of CD's and DVD's as well? They could contain malicious software!
This is where the whole balancing act comes into play; we must balance convenience with security. In your sarcastic example, you've ignored all convenience while maximizing security. In some environments, that'd make sense (which is why some environments don't include a web browser).
The issue we're looking at is how the "inconvenience" of not being able to install .deb files compares to the increase in security and simplicity.
I think one way to balance things out would be to make AppCenter extraordinarily convenient. If that's the case, people won't ever want to install a .deb in the first place. So that's the route I feel we should take.
As most people I think I have something to add, but the first part of this post already voices my opinion; I will add that I agree.
Thank you for taking the concerns of the community seriously. I too was skeptic, but this journal showed me how this might be possible if it's done right.
'Cause I want to add something of my own: I think a link to manuals is confusing. Showing a clear warning using colors and a link to settings on switchboard is more informative. If you do this right the risk are obvious and it doesn't ruin the user experience.
I agree that providing a link to a manual would just be annoying and confusing. However, I really think it should be an all or nothing ordeal; either we support installing .debs, or we don't. By compromising and saying, "Hey, we blocked .debs but you can install them by checking a box," we're telling the users that we're not sure if we want to support it or not.
While that's okay for a discussion like this, in the actual OS I feel that needs to die. It should just be a seamless install, or an "I don't know what to do with this file." Not something in between.
Of course, that's just my personal opinion, and one not shared by everyone.
If you want an all or nothing situation: keep .deb installation. While 'most people' won't need anything outside of the repositories, nobody is like 'most people'. We all differ somewhere and need that one application that nobody uses; if it's that '90s game I would like to play or some kids home written doll animation project. It's impossible for open source to cover everything.
And while I would want to see that, just be sure we understand the risk when installing our doll creator. I'm confident you can make this as nice and seamless as it should be.
p.s. I think pointing to Gdebi for so called 'power users' is unworthy as an answer. Installing third party apps for installing third party apps is simply rubbish.
A link isn't useful in my opinion. That would lead to a "click-through" thing and nobody would read the warnings or think about the security issue. If you provide a link that says "Activate this option HERE", users won't even think about the security risk and will simply activate the option. It's too easy. And if you do that, you don't have to deactivate deb installation at all, as it wouldn't resolute in any significant security improvement.
I think a warning describing what is happening and what you should do (go to switchboard and activate the option to install .debs), with nothing else but a dismiss button would be the best option. that will force people to read if they want something to happen.
once in switchboard, it should work like I mentioned earlier, checking that option opens a dialog asking if you want it for the next install ONLY, or for all installs from now on, to prevent unwanted changes to the default security settings. people always forget to change it back.
"I think a warning describing what is happening and what you should do with nothing else but a dismiss button would be the best option. that will force people to read if they want something to happen."
While it will force people to read if they want something to happen. It will leave them utterly confused if they don't read anything at all.
then they will try again and read it the second time it shows up, to understand what just happened.
beyond that point, we can't expect monkeys to run computers.
I think its a great idea for the purpose of offering more security...
but I disagree with it because I use a .deb file for my most important app... My web browser D:
I think that it would be nice to have this feature but only and only if there is a way to install apps from a .deb without using the command line (which I hate doing)
One way to address this problem would to have a setting in Switchboard that turns on graphical installation of .deb files
I'm not sure where everyone keeps getting this command line thing. Gdebi is available to install from the repos and graphically handles the installation of deb files. It's what Ubuntu used up until USC starting handling debs.
I think it's the fact that you can install them from the terminal with a command, OR you can use a dedicated tool, but the command line method is inherently "supported" out of the box.
I don't agree with comparing desktop systems to smartphone systems, but I can see your point: Android and iOS are growing each day.
Anyway, I read some comments saying that a user should recive a warning when trying to install a .deb, telling the user to alow deb installation in switchboard.
I can't see this as a solution. I help plenty of people that freaks every time they see a Windows alert with instructions. They simply don't like to change system's settings.
Sure, by restricting .deb installation you're preventing the user fram damaging their own computer, but is this necessary for the moment?
Non-geek expect to install anything they need, without changing any preferences and the only way of making this possible for the moment is allowing .deb instalation without restrictions. This could be done as in USC, with a red warning.
As I said in the other post and Cassidy wrote in this one, there are some situations that the user NEED to install debs in order to do certain things, like the government application example. And there's the case of not having any internet connection too.
That's my opinion. Maybe it's too soon (or it will always be) to cut off .deb instalation by default. This is why OSX is keeping .dmg instalation.
First off, iOS and Android aren't solely smartphone operating systems. As noted in the article, both iOS and Android power phones, media players, tablets, and TVs.
With tablet computing becoming more and more prominent, the lines between the operating systems are being blurred more and more each day. Windows 8 is shaping up to be very much a tablet-friendly operating system and has adopted many of those ideas while still being a desktop OS.
Also, as phones, media players, and tablets become more and more popular and powerful, users start expecting to see similar things back on their desktops.
Well, I cam see your point. Anyway, you can still install exe's in windows. For the other OS, they are far away from completly substitute the desktop experience, there's no way of doing this right now, it's impossible to have everything an user may want in a app shop.
Is the security really a problem right now? Does anybody ever complained to the elementary team of installing a malicious deb?
I think that knowing i wll not be able to ensure that elementaryOS will install everything the use may need is the bigger problem.
I think the thing people need to remember is that we haven't done any of the stuff we've done by being reactive and saying "has anyone ever complained about x before?". We push innovation and create value in our products by being proactive.
First of all, I really think that all the ubuntu apps should be available in the eAppCentre, with a strong emphasis on elementary apps ( I leave that to DanRabbit and our other god-like designers :D) I don't think Devs' inconvenience should be a consideration at all (no offence...read on).
The whole elementary philosophy is based on the user experience for normal everyday users. I would really expect devs to be quickly able to download gDebi or whatever and enable open by default (maybe through the use of a file type plug?). A simple two-step process. problem solved. In the past the team has taken bold moves and locked up the desktop (something users of most if not all OSes are used to customizing) and the panel (which is marketed by its developers as "highly extensible") to shape and improve overall user experience. We tackled the problem of those who wanted to customize their desktop and panel by providing easy guides to enable configuration. We can do the same again. A valid point might be that these guides aren't immediately reachable from within the OS, this can be easily changed (think: Linux Mint User Guide and Welcome screen)
I think a good solution would be to use basically the approach that Ubuntu is using atm, that is to open .deb files in the software center or whatever you call it. however, there should be much a more strong indication to the user that this is not the typical or recommended way of installing software. Again, I think that this problem can be solved by more thoughtful design of the software center.
An interesting idea I'd like to share is having a prominent button in the software center for installing from a local .deb file called "Install from file" or "Install from disk". When this button is clicked, a file picker is shown to select the .deb file. When a .deb file is clicked from Marlin, it will launch the software center to the home screen, the "Install from file" button would throb/flash/depress or anything to indicate the button being pressed automatically this time and then continue to the page for installing the package, with a clear warning of course. This would encourage the user to open the software center for all app installation needs and greatly supports the idea of using apps offered by default, while integrating the processes of repository and offline installation. Lastly, thank you for setting the standard for user communication and community participation. Hope you will always be this involved with your fans. Keep up the good work and never let trolls get you down. You are doing a wonderful thing and leading elementary into a brilliant future.
If malicious software is such a worry, why not require that the package be scanned by some anti-"virus" method? (I'd rather say malware, but that would technically be trademarked there)
First, that'd require having a maintained database of all potentially dangerous apps. Second, anyone can make an app that seems legit that also does bad things.