How to Uninstall a .deb Package

I try to fill or complement what @SeanBright leaved out:

Feature                              rpm                                   deb
----------------------------------------------------------------------------------
View all installed packages          rpm -qa                               dpkg -l, dpkg-query -Wf '${Package}\n'
View package info, installed package rpm -qi packagename (1)               apt-cache show packagename
View pre/post install shell scripts  rpm -q --scripts packagename          cat /var/lib/dpkg/info/packagename.{pre,post}{inst,rm}
View changelog for a package file    rpm -qp --changelog ./packagename.rpm dpkg-deb --fsys-tarfile packagename.deb | tar -O -xvf - ./usr/share/doc/packagename/changelog.gz | gunzip
Uninstall a package                  rpm -e packagename                    apt-get remove/purge packagename
Upgrade a package from a file        rpm -Uvh ./packagename.rpm            dpkg -i packagename.deb
Find which package owns a file       rpm -qif /some/file.foo               dpkg -S /dome/file.foo
List dependencies of a package       rpm -q --requires packagename         apt-cache depends package
List dependencies of a package file  rpm -qp --requires ./packagename.rpm  (shown in package's info)

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.