Owen Taylor has been rocking recently. In the 0.3.x releases there’s an optional packagekit-plugin package that is a standard Mozilla plugin. It works in Firefox and Epiphany and looks something like this:
Test page shipped with PackageKit
It’s actually pretty easy to build a website that wants to install something new or run an application that is already installed.
The actual html you need is something like this:
<object type="application/x-packagekit-plugin" width="500" height="200" class="packagekit-plugin">
<param name="displayname" value="KStars"/>
<param name="packagenames" value="kdeedu kde4edu"/>
<param name="desktopnames" value="kstars"/>
</object>
You can omit displayname and desktopnames if you wish, as PackageKit can query the backend and fill in the blanks. The packagenames are queried until PackageKit finds one that matches on your system.
I’m also thinking about adding the application icon in the box as common applications usually have standard icons that PackageKit already uses for other stuff.
Of course, because this uses PackageKit, it’ll work on any distro. If you want to improve the look of the plugin or add some extra features, jump on the mailing list and give ideas. Feedback welcome.
Here is an alternative and more cross-browser friendly way of doing the same basic idea.
Make a new uri:// handler for something like packagekit:// and teach one of the pk* tools to understand it.
So you could make a link to “packagekit://mozilla-prism” for it to install the mozilla-prism package from the official repositories. I’m thinking of something exactly like in ubuntu’s “apt-url”. A firefox plugin might not work in epiphany or other random browsers that people might want to use where a generic protocol handler should be configurable in pretty much every browser.
The plugin looks good, but maintaining it sucks when you don’t have to.
And now, finally, packagekit becomes dramatically useful.
No more need of “1 klik install” and thousands of similar projects.
Wonderful ;)
If the web site is allowed to provide the display name, doesn’t that open a security problem in that the website could tell the user about app A but in fact then install app B ? I.e.
displayname: Cool new stuff!
packagenames: package that has known, remotely exploitable bug
So it would be better to only supply the pkg names and always query the backend for their display names, I think.
sounds like a bucket of holes from where I’m sitting… A bit of clever javascript, assuming the user has the plugin installed and you get to execute stuff on their machine…
Bit too close to active X and microsoft’s own bucket of holes for my liking, I won’t be installing that plugin, and if fedora wants to force it on me it shall be quickly removed…
-1 for the web centric desktop, on the face of it this has taken us back 5 years! The simple fact is, a web application should never be allowed to execute a program on my machine under any circumstances you can just never be sure what nefarious activities will ensue as a result of opening up the playground like that.
And please don’t insult me by giving me re-assurances that its perfectly safe, governments said the same about DDT, and microsoft said the same about active X…
Then of course, there’s the fact its simply not necessary! Installing from the web, fine, but running stuff from the web?!?!
@someone: valid concern. I’ll fix that now.
http://git.fishsoup.net/cgit/packagekit-plugin/tree/README has some discussion of the display name issue. Basically, you can probably disguise it in the web page anyways, so it’s better to deal with confirmation after the user clicks, not to try to make them avoid clicking. And a package that is in the configured repo, and opens a security hole just by running it (no arguments, no file input) seems like a rare thing. The advantage of providing the display name is making the plugin understandable on failure.
Karl: no javascript involved, it’s all HTML then C plugin. Nothing is exported into the DOM. The website can’t interact with the plugin whatsoever. It’s nothing like activex at all, as the plugin has a very narrow and well controlled one way IPC for one certain task. The HTML can never execute an exectuable on the computer, it’s up to the user to click, and then it can only open a .desktop file from a package the user already has installed.
I don’t want to insult you telling you it’s safe, but I would like you to at least look at the design and read the code and you’ll see it’s safe as houses. :-)
Is there a reason why it’s done as a plugin, and not as a protocol handler (ubuntu uses apt:, I think opensuse uses something else)
I see, so it puts some more information on the webpage, seems not that critical though as the user can find that out after clicking on it
As reported by others, it’s pretty easy to specify name=Banshee, desktop=banshee, package=buggy. A protocol handler would be more useful from the scripting point of view (select your distro and we’ll give you the right uri) – it would need a confirmation window but that’s needed anyway as it should be relatively easy to cover the plugin with custom html that sends the click through by the means of scripting (please research the very same tricks people use to style file input html widgets).
So why is this a browser plugin instead of using something like YMP and the 1-click installer (a helper application) from openSUSE? It actually uses PackageKit too… and YMP was definitely designed to be cross-distro. (A single YMP file can specify multiple distros, making it really just a couple clicks away for *any* distribution user to have software easily installed on their computer… all from one single website button without any complexity for the website author.)
If you should have to have a confirmation click anyway, then why not pass it off to an external program to handle it? Why use a browser plugin? (I don’t see any advantages.)
A protocol handler is going to give you an experience of “Click this link to run Inkscape if it’s installed, or install it if it’s not installed and it’s available for your distribution”. and if you don’t have PackageKit installed, will then give you the nice “I don’t know how to handle the url packagekit:installOrRun?package=inkscape&desktop=inkscape” experience. (With a plugin you can have fallback content for an embedded object if the plugin is missing.) A content association for YMP files seems similar. You could have a YMP plugin that uses a YMP file as input, but I don’t really see the point as compared to providing the few necessary inputs directly as parameters to the plugin.
This is awesome! People will be able to install stuff by just clicking on a link.
Owen:
The plugin is prone to phishing as stated in my previous comment. It’s possible to overlay the plugin with custom HTML and have the click event fall through to the plugin (which could cause an otherwise wary user to install a package by clicking an innocent looking link). The URI handler also has the added benefit of working everywhere, not just in a (particular) browser.
@hughsie: I don’t doubt that it looks safe, and could be, however its not how it looks, its how it looks to someone who will attack it. I mean, after buffer overflows became a null concept the heap overflow rose up, even if you think its safe, even if I think its safe, if everyone who uses it thinks its safe, there’ll still be someone out there who wants to make it unsafe! I learned early on that anything is possible when even the smallest glimmer of an attack vector is opened up.
I don’t understand why you’d actually want to do this kind of thing anyway, it just seems senseless to me! I have an application menu for starting applications, why do it from a web browser?!?!? The reality is a web browser should be used for browsing the web, not managing anything on my machine. Sure I like the idea of a click to install, but I already have that with open with – package installer. This kind of thing always makes me feel uneasy, after seeing some of the crazy stuff that goes on, on the web I feel tingles in my spine when thinking of this.
And you say that there’s no javascript, well at least that’s a sensible sandbox, but what about css and html hackery? It’s amazing what can be achieved with some css to cover up something so a user clicking on something that looks safe, can in fact be a mask for something else.
I’d say before you believe in the code 100% invite some miscreants to find holes in it, until they tire themselves out, offer a cool prize for it and I’m sure you’ll find things in there you wouldn’t expect…