LWN.net Logo

ownCloud moves ahead

By Jake Edge
January 4, 2012

There are lots of cloud services out there these days—many of them free in the "beer" sense—but privacy-sensitive and free-software-oriented users have long been looking for alternatives. One of the few "free as in freedom" choices is ownCloud, which is the brainchild of KDE developer Frank Karlitschek. The project has been making steady progress since last we looked in on it back in June 2010, releasing ownCloud 2 in October, while preparing for ownCloud 3 in January. In addition, Karlitschek and former SUSE/Novell executive Markus Rex have formed a venture-capital-backed ownCloud company to foster the project while providing support and services.

The idea behind ownCloud is pretty straightforward: provide a way for users to replace closed source cloud services like Dropbox (or Ubuntu One) for file backup and sharing, Google Calendar and Contacts, picture sharing services like Picasa or Flickr, and so on, as well as providing storage for other web applications via the remoteStorage protocol from the Unhosted project. All of that functionality would be free software and user-installable so that the provider lock-in problems (as well as privacy concerns about what service providers do with the data they collect) can be avoided. Add in access from a variety of different kinds of devices (desktops, laptops, tablets, cell phones, ...) and it makes for a sweeping vision. There are many parts of that vision that still need to be filled out, but much progress has been made in ownCloud 2, with more to come in version 3.

ownCloud 2

[Music application]

For version 2, there are four different "applications" that come in the ownCloud web interface: Files, Music, Contacts, and Calendar. Files can be uploaded to the server from the browser, shared with other users of the ownCloud instance, or published for anyone to access via a URL. In addition, using the WebDAV protocol and the user-space davfs2 filesystem allows one to mount the ownCloud files directory locally, which allows local applications (and file managers) to access the files directly.

[Calendar application]

The Music application allows playing music files within the web application or, using the Ampache server, to stream the music to desktop players. Calendar and Contacts provide the basics of managing that kind of data in the web application, while also providing access to that data for other applications via CalDAV and CardDAV.

The server side installation of ownCloud 2 is fairly simple for anyone with root access to a Linux server. It is mostly a matter of getting the pre-requisites installed, which includes PHP, a database (MySQL, PostgreSQL, and SQLite are supported), and the appropriate PHP "connector" for the database choice. After a bit of Apache configuration, you point your browser at the site, which lands you on the installation wizard; after answering a few questions, ownCloud is up and running. WebDAV installation on the client side is also fairly straightforward (or was for Fedora 16 at least). That said, neither task is so easy that non-technical folks can be expected to handle it.

Overall, ownCloud 2 seems to work reasonably well. There are glitches and some oddities in the interface, at least in the released version. There are two other versions of the code available, including a Git repository for the latest development version. Neither of those options worked for me when I tried them in late December, but those problems are presumably solvable. The key functionality, sharing data between disparate devices, works well enough that I will be spending the time to get newer versions running in the near future—or wait for ownCloud 3, which is due at the end of January.

ownCloud 3

One of the areas lacking in ownCloud is data encryption. Connections are made to the server via HTTPS, so the network communication is encrypted, but files are stored in plaintext on the server. Encryption is listed as one of the features for version 3, but details are a little hard to come by. For users that set up their own server, encrypting and decrypting the data on the server side may be sufficient (depending on the key management) to protect against a system compromise that gives access to the stored data. That seems to be the feature planned for ownCloud 3.

But, for users that are storing their data on someone else's server (e.g. a friend or service provider), client-side encryption will be needed. That seems like a harder nut to crack because it requires code on each and every client. Without that, though, there can never be any real assurance that the data is not accessible to whoever provides the service—and possibly to attackers that compromise the server.

There are some other features listed for ownCloud 3, including a photo sharing application and a better interface for the calendar application with support for recurring events. There is also a mention of allowing external applications to integrate into the ownCloud web interface so that things like the Roundcube mail application could be added to ownCloud installations.

One area that the project could do better with is documentation. Information about ownCloud, its development, bug tracking, and so on are scattered across a number of different sites including Gitorius, Shapado, the mailing list, the ownCloud web site, and so on. It makes it a bit difficult for new users to track down the information they need—some sort of consolidation or master index would likely go a long way toward fixing that problem. The project does make it pretty easy to get a feel for what can be done with ownCloud on its live demo page.

ownCloud.com

It's also a bit hard to tell what, exactly, the plans are for the ownCloud company. It appears to have a commitment to open source and is being led by two longtime open source community members, so there is good reason to believe that the project will continue—and prosper—with some corporate backing. From the information on its web site, part of what the company is selling is the open-source nature of ownCloud, and its lack of vendor lock-in. All of that bodes well.

There are certainly some areas that need work in ownCloud, particularly in the ease of installation and configuration areas. One would guess that ownCloud.com will be putting a fair amount of effort into that, but it's not alone. The openSUSE project has also been working on ownCloud integration. From the looks of the ownCloud mailing list, there is an active community springing up around the project.

Hosting ownCloud instances for those who don't want the hassle might make a reasonable business opportunity for ownCloud.com and others. A reasonably priced per-Gigabyte subscription service could be attractive for privacy conscious users if the encryption issues can be resolved. Whether there are enough of those users to truly support that particular business model remains to be seen.

The ownCloud project shows a lot of promise. It is certainly usable today and will only get better in the near (and hopefully, long) term. It may only be interesting to a subset of internet users, since many are willing to trade their privacy and security for "free" services, but for the other folks, it will be real boon. Companies may also find that hosting their own instances of ownCloud (possibly with a support contract from ownCloud.com or someone else) makes a lot more sense than relying on Dropbox, Facebook, or even Ubuntu One. In any case, ownCloud seems to have a bright future and is well worth checking out.


(Log in to post comments)

Nice, but no so "cloudy"

Posted Jan 5, 2012 7:02 UTC (Thu) by eyal (subscriber, #949) [Link]

A "cloud" service implies high availability and high reliability, as behind the scenes the cloud is based on multiple servers, storage devices, network connections, etc.

My understanding is that ownCloud is simply a file sharing web application. It appears to be good, relies on accepted open standards, open source and fast evolving. But I don't see a "cloud" element.

To make ownCloud a true cloud, it should provide means to make the data distributed and synchronized over several instances.

For example, have a "main" instance installed on a premium web hosting or VPS provider, a backup instance on a cheap hosting provider, and another on a home PC.

Eyal.

Nice, but no so "cloudy"

Posted Jan 5, 2012 14:54 UTC (Thu) by iq-0 (subscriber, #36655) [Link]

"Cloud" really is just a marketing term for virtual networked services, something that almost everybody has been doing for years but which now have been defined as a concept.

And you are correct that the term "cloud" often implies things like redundancy, high availability, clustering and such, but just the possibility of those is all you need to declare something a "cloud". In this case you could just make sure this thing is hosted on a system that provides these things and your done.
You can do even better and host the separate parts (database, webfrontend, ..) in different parts of a "cloud". You can run multiple frontends for loadbalancing. I haven't looked at the internals, but with a little twist multiple installs would be easily splittable over multiple database instances for added scalability through partitioning. That's just one indirection away. You only have to do it on a system basis, but "cloud" terminology doesn't really signify on which level you provide these possibly implied perks.

ownCloud moves ahead

Posted Jan 5, 2012 14:36 UTC (Thu) by njwhite (subscriber, #51848) [Link]

But, for users that are storing their data on someone else's server (e.g. a friend or service provider), client-side encryption will be needed. That seems like a harder nut to crack because it requires code on each and every client. Without that, though, there can never be any real assurance that the data is not accessible to whoever provides the service—and possibly to attackers that compromise the server.

Couldn't you have some scheme along the lines of using the password from HTTP digest to read an encrypted file on the server? I presume I'm overlooking something, but that seems like it should work, and would only require server-side support.

ownCloud moves ahead

Posted Jan 5, 2012 16:52 UTC (Thu) by amarjan (guest, #25108) [Link]

Where would the decryption take place (i.e. what do you mean by "read")?

I assume you mean that decryption happens on the server and you provide the server with the password each time you need to access something. In that case the server provider has your data the instant you submit the password to the server. The password will exist at least in server memory, and your unencrypted files will also exist at least in server memory.

The only way to guard against a malicious server (whether intentional or compromised) is to encrypt files on the client and provide only encrypted blobs to the server.

ownCloud moves ahead

Posted Jan 5, 2012 17:06 UTC (Thu) by njwhite (subscriber, #51848) [Link]

> I assume you mean that decryption happens on the server and you provide the server with the password each time you need to access something.

Yes, this is what I meant.

> In that case the server provider has your data the instant you submit the password to the server. The password will exist at least in server memory, and your unencrypted files will also exist at least in server memory.

Yes, that's true. So the unencrypted data only exists in server memory, while you're logged in. Not perfect, for sure, but perhaps good enough. Protects against e.g. server theft. Doesn't protect against hostile server operators at all, of course.

ownCloud moves ahead

Posted Jan 18, 2012 3:17 UTC (Wed) by Duncan (guest, #6647) [Link]

... And in not protecting against server operators (hostile or not), it doesn't protect against government or even foreign government (see US and even foreign corps required to gather SWIFT data by US law enforced on other nations, despite European data directives, etc).

The ONLY way to protect even customer /friendly/ server ops against such government intrusion is if there's simply no way for them to get at the data, period, meaning they must only have access to the encrypted blobs, period, and if they're friendly, they don't even WANT the chance of seeing the unencrypted data, since then they could be ordered to provide it.

Client-side encryption and audited open source code to ensure no backdoors is the only way for a service provider to protect /itself/ against such forced government, even foreign government, cooperation. If all they get is the blob, they can happily turn over the blob, but that and possibly account info is all they have to turn over, which is exactly how a good company will want it!

Duncan

ownCloud moves ahead

Posted Jan 25, 2012 19:47 UTC (Wed) by JanC_ (guest, #34940) [Link]

> Yes, that's true. So the unencrypted data only exists in server memory,
> while you're logged in. Not perfect, for sure, but perhaps good enough.
> Protects against e.g. server theft.

Actually, it does not even protect against server theft in all cases (remember this unencrypted data might get swapped out to disk, and the fact that RAM isn't erased on reboot).

ownCloud moves ahead

Posted Jan 28, 2012 7:25 UTC (Sat) by tanghus (guest, #82609) [Link]

Oh, comon, seriously. Do you expect a system meant for "everyday persons" who may have a hosted web space or use their own PC with ownCloud to have enterprise encryption? Go look at owncloud.com and they will probably give you an estimate on the cost. ownCloud is supposed to be able to run on the minimum requirenment of both hw and sw with the maximum protection.If you want more than that you have to get out the mole skin.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds