Shipping plugins as Click packages

Registered by Loïc Minier on 2013-11-14

Discuss how to deliver plugins over Click packages

Colin has hashed out the Click requirements already, and it should all be doable with the current system-level and user-level hooks.

There's a detailed plan for Unity scopes at:
https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement

But there are other plugin types we want to consider:
* GStreamer codecs
* location-service plugins
* any other?

These would most likely be system-wide (per device rather than per user)

Security? What kind of confinment?

Appstore integration? How do we search / hide specific Click types? How do we review these?

End-user experience? how is installation triggered? how do users manage installed plugins? Do we provide a specific API for this?

===
Notes from vUDS

https://blueprints.launchpad.net/ubuntu/+spec/core-1311-shipping-plugins-as-click:
Discuss how to deliver plugins over Click packages

Colin has hashed out the Click requirements already, and it should all be doable with the current system-level and user-level hooks.

There's a detailed plan for Unity scopes at:
https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement

But there are other plugin types we want to consider:
* GStreamer codecs
* location-service plugins
* online-accounts accounts
* Friends plugins
* desktop webapps in Unity7 (this is in another session)
* greeter visualizations (in discussion)
* app themes?
* sound themes? other themes? -- not really plugins
* any other?

These would most likely be system-wide (per device rather than per user)
Security? What kind of confinement?

Appstore integration? How do we search / hide specific Click types? How do we review these?

End-user experience? how is installation triggered? how do users manage installed plugins? Do we provide a specific API for this?

Current Click profiles:
* unconfined
* webapps
* regular apps

Upcoming profiles:
* local scopes
* network-using scopes

Unity scopes would be user-level, it would be possible to install for all users or not

For certain use cases, the effect might be system-wide all the time -- always visible to all users

As much as possible, we should design services to be extensible on a per-user basis
TODO: Loic check whether location-service is system-wide or per-user

How do we confine location-service?
- do we need to confine them at all, or do we rely on partner engagement?
- not that many plugins to review

* To implement codecs or location-service, we could offer a search feature to apps, but apps would just point the user to the right package(s) to install from the store

* Might need search API from the store

* For codecs specifically, we need to review the codecs because they are available to all apps

* For codecs, we'd likely start from .deb and wrap them into Clicks

* Security-wise, we should look at each use case independently and decide how we confine things

Adding metadata to packages might need a specific extension to click's PackageKit plugin in order to be able to search for it; "what_provides" should be the interface name

For themes, we probably only need to extend review scripts to check/validate the data, or reconvert the data, but nothing more

Online accounts: confinement not implemented right now, so would have to be manually reviewed, or specific agreement
There's a plan to move online accounts plugins to run in a separate process so we'll be able to confine them individually (and therefore not require manual review or specific agreement)

Blueprint information

Status:
Not started
Approver:
Steve Langasek
Priority:
Undefined
Drafter:
Loïc Minier
Direction:
Needs approval
Assignee:
Loïc Minier
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items