Installing a random (nasty?) .deb can be dangerous because it will grant all privilege to the apps and daemon installed because the .deb has some configs asking to applied if the user valid his password at the installation process.

Click package doesn't need a password (as far I have tested).

Will click package be safer to the system/userdata or will it be the same? why?

Some aspects that would be great to be answered:

  • are click and deb based on the same system (dpkg)?
  • can apparmor provide a root access to apps without password or something?
  • will the user be prompted to accept the access rights of the apps when installing (android-like example: this apps will be able to scan your /home and access network) or on the run at the need of a right (browser-like example asking the right to use the cam)?
  • close to this question: does .apk and click will word the same (about policies and user story)?
  • mainly: can an app send all my private data on the network with click without let me know it explicitly or will it have at least the right validated by users to do so or will it be blocked in a sandbox anyway?
  • It is true to say: click package are less powerful (restrict more things), but more safer?
  • I wanted to add the tag "click" but not enought reputation to do so. The last sentence was suposed to be italic.
    – cm-t
    Jun 19, 2014 at 8:35
  • tag click-packages is already available.
    – Pandya
    Jun 19, 2014 at 8:49
  • NB: click packages are under development, I wish have answer for the target of the next stable click package.
    – cm-t
    Jun 19, 2014 at 10:51

2 Answers 2


Note: I work on the Ubuntu security team and helped design the application confinement story for Ubuntu. I reworded the questions for clarity.

Q: "Will click packages be safer with regard to the system and user data or will it be the same?"

A: In general, click packages are safer than debs with regard to system and user data.

Click packages do not include maintainer scripts that run as root at installation like deb packages do. Click packages are simply unpacked and then hooks provided by the system are used if declared by the click. For example, the click might declare to use a desktop hook to generate a desktop file or an AppArmor hook to generate an AppArmor profile for the app. Because deb packaging has the concept of maintainer scripts that are designed to allow for extensive customization of the software or the system, deb packages should only be installed from a trusted source, eg a signed archive from a distribution like Ubuntu. Click packages may be installed directly and you can be reasonably sure the package installation won't ruin your system. However, that is only part of the story-- if you install a click package from an untrusted source, there are no guarantees that it will declare in its manifest that it is properly confined, so while installing it is ok, running it may not be (ie, the software may run without confinement and therefore be able to steal your data or run programs as your user).

The real power of click is when it is used in combination with a software repository with strong policies. For example, the security of a click package installed from the Ubuntu App Store is typically higher than that of a deb installed from a trusted archive. This is because in the Ubuntu App Store, the trust model is apps are considered untrusted* and policies and checks are in place to ensure that click packages in the store have a proper security manifest and therefore run under very strict confinement. Contrast that to deb packages in the Ubuntu archive-- the trust model is that the software and deb packaging are considered trusted and in general the software does not run under confinement (though there are plenty of exceptions where an AppArmor profile is shipped with the software to guard against security bugs).

  • Trusted packages may also be delivered via the Ubuntu App Store. While uncommon, they are typically developed by Canonical and may or may not run under confinement.

To answer your specific questions:

Q: Is click based on the same system as deb?

A: The low level package format for click is deb. However, click packaging is much simpler in that it uses a declarative manifest and hooks rather than traditional packaging files and maintainer scripts.

Q: Can AppArmor provide privileged access to apps without user interaction?

A: AppArmor is root strong and can allow or deny access to system resources (files, DBus, networking, etc) based on the defined security policy. A click package on its own is not required to ship an AppArmor security manifest or to ship an AppArmor security manifest that is 'safe'. What makes the system secure is the combination of click and the policies of the store that delivers click packages. Click packages delivered via the Ubuntu App Store will use AppArmor policy that is very restrictive and does not allow privileged actions behind the scenes (eg, an app running under this policy can't execute programs on the system behind the scenes, access your facebook account, steal your gpg or ssh keys, manipulate networking, etc)

Q: Will the user be prompted at install time to grant access rights to the app like on Android? (eg, "this app is able to scan your /home and access network")

A: No. A click package itself may be installed with no prompting using lowlevel tools. On Ubuntu, click packages should be installed via the Ubuntu App store (see the above) and because of the Ubuntu App store policies combined with click capabilities and the Ubuntu system, there is no need for click-through, context-less installation prompts. Ubuntu can do this because apps installed from the Ubuntu App store run under restrictive confinement (ie they can't do bad things behind the scenes) and when an app needs additional access it does so using controlled APIs which may include prompting.

In the case of privileged APIs, we have the concept of trusted helpers such that the user will have a contextual prompt to allow or deny the access (with (optional) revokable caching so the user isn't asked each time). For example, if the app needs to access the location-service (a trusted helper), the user will be prompted to allow the access at the time the app tries to use the location-service, which gives context so the user can make an informed decision. The same will happen for video and audio recording. Often, we don't need to have a security prompt at all and we can allow access based on user-driven interactions with the app. Eg, if an app wants to upload an picture there will be a dialog to select the picture. Behind the scenes, because the app isn't allowed to access the ~/Pictures directory, it will use the content-hub API which will launch the gallery file selector for the user to choose a picture to upload. The content-hub then takes the picture from the gallery and gives it to the app. In this manner, there is no security dialog, there is only a natural interaction for the user, but behind the scenes, there is an implied trust decision.

Q: Related to this question: will .apk and click have similar language with regard to policies and user experiences?

A: No, there is no installation prompting for the reasons stated above. Android permissions and security permissions for click packages as defined for Ubuntu have some similarities, but are different and implemented differently.

Q: Specifically, with click, can an app send all my private data over the network without me knowing or will it be confined in some way to prevent this?

A: If you install a click from an untrusted source, yes, it can do anything. If you install a click from the Ubuntu App Store, no, an app can't send all your data off over the network because it does not have access to it. Of course, an app can appear to do one thing and do another so if a user grants access to the location-service or gives the app access to a picture, then the app can be evil with that data-- but that is where ratings/reviews and App Store security policies come in to effect. If an app like this is reported, it will be investigated. If appropriate, the app will be removed from the store, the app will be removed from any devices where it is installed and the developer's App Store access will be revoked.

Q: Can it be said that click packages are safer than debs, but less powerful because they are more restricted?

A: As can be seen from the above, the answer is not that simple. A click by itself may ship software that can do anything. The click packaging format is intentionally general purpose and can be used in any number of ways and is not at all specific to Ubuntu. For Ubuntu, the combination of click, Ubuntu APIs, AppArmor and App Store policies provides a very powerful environment for developers to deliver applications to users in a way that is safe and easy for people to use. The utility of the applications themselves is dependent on the APIs offered to the applications by the underlying system. The initial set of APIs that will be offered on Ubuntu's first shipping phones will allow developers to create all kinds of fun and useful applications using a rich API and SDK. These APIs will expand in their breadth and utility as we move forward to better support developers and users.

  • 1
    "the app will be removed from any devices where it is installed" - that seems concerning. Does this mean that Canonical will be able to remotely uninstall apps from the users' devices without their permission?
    – user180409
    Jul 11, 2014 at 9:22
  • The Ubuntu App Store will have this capability. Exercising this capability will likely only be done when there is actively malicious code involved. I don't want to dictate policy here since there are a number of considerations that must still be looked at, but the bottom line is this shouldn't be something that happens without a very good reason.
    – jdstrand
    Jul 17, 2014 at 17:11
  • 2
    I understand this is for users security (other app stores do this as well), but some users don't like these sort of "kill switches", because this means that a company can remotely uninstall apps (or more), even if it's for security reasons. I think the developers should consider carefully how to implement this, to avoid a controversy. Maybe disable the app instead of removing it, allowing the user to uninstall or re-enable it by himself, and show very prominent warnings... as a suggestion.
    – user180409
    Jul 17, 2014 at 18:54
  • If Click packages its own dependencies, what about security updates of a dependency? If bash deb is updated all other packages using bash naturally uses the new version. However if a Click app packages bash then unless the app developer takes care to include an updated bash the bug is still there, and that assuming the app developer often updates the package. Note this in this scenario imagine that bash isn't a base package. Nov 6, 2014 at 15:52
  • This sounds so cool! Even better than the android system! Android permissions has become something like the EULA, just click "yes" without reading... Dec 7, 2014 at 17:11

I will try to answer some of the most important questions regarding security and click packages.

  • Can an app send all my private data on the network with one click without letting me know it explicitly?

    • Click apps will run under confinement. What this means is that the app is prevented from doing bad things: it can only access its own private directory.
  • Can apps be installed and then have root rights? without password or specific prompt?

    • ...
  • Will the user be prompted to accept the right of the apps? when?

    • Click apps will access features that the user allows the app to use (NB: prompt not yet on the current/daily Ubuntu Touch release).
  • Is it based on the same system for both click and deb?

    • Debian (.deb) packaging is completely different. However, if your app is made with the Ubuntu SDK, you don't need to use Debian packaging and can instead use Click packaging, which is much easier to use and much safer for the end user.
  • Similar as above, to compare: Do .apk (Android) and click work in the same way?

    • Android packages and Ubuntu Click packages will work in a similar way, in that each application will have its own space to store data and that it's (ideally) prohibited from accessing data of other applications directly. Currently, Android packages can also read data from the SD card or internal storage, where there are no access restrictions. Ubuntu Click packages will also have to request permissions for specific features.
  • It is true to say: click packages are less powerful (restrict more things), but safer?

    • ...

For these reasons, Click packages are very safe and the review process for publishing them is much simpler.


  • Please complete this answer as you think it is the best
    – cm-t
    Jun 19, 2014 at 12:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.