Qt Cloud Security / Privacy
I love the idea of the Qt Cloud Services. Makes a lot of sense.
One question though. As far as I can see, as the developer/owner of the cloud instance, I've got full access to all the data in my instance.
Depending on the application, it seems perfectly reasonable that a user will not necessarily want me, the developer, to be able to read the data that they're putting into my cloud with the app I've made for them. A diary app, say. They don't want me to know they've fallen in love with this boy or that girl.
Is there any way (short of client-side encryption) to support users' privacy in the Qt Cloud? Or is the capacity for developers to access users' data just something we have to accept, the "cost of doing business"?
I think you will get more response for this kind of questions on "the mailinglists":http://lists.qt-project.org/mailman/listinfo/development
That's where the qt developers are hanging out. This forum is more user oriented.
True, the Qt developers will have their own opinion on the question. But it's a user's question, so a user-oriented forum is an appropriate place to discuss it.
Yes, if you want to gather opinions, you're in the right place here. In my opinion, you have a good point there.
If you want something changed in the future you can fill a feature request[bugreports.qt.nokia.com] and post the link here, so others can vote for it.
The more votes you get there, the more important the feature is for the developers to implement it.
copy paste error ;-(
The thing is, I'm not entirely certain it is a bug as such. Maybe it's just a design constraint? I wanted to get some discussion flowing first to see if it really is a problem. How would or should it be resolved?
It's not enough to have the app developer to be able to set an ACL flag to prevent him or herself from reading user data. That's just the same as "promising" not to read it. They could just undo the flag later.
I guess it'd have to be done server-side, where the server, the Qt Cloud itself, sets the flag or applies encryption per user so that the app developer can't read user data.
So yeah, gathering opinions is my goal at this step. If there is consensus that it is a problem then I'll be happy to file the bug. I'll send a message to the developer's mailing list to let them know we've started this discussion.
Hello! This is interesting topic. The design philosophy is to provide virtually unlimited scalability for cloud based database.
When we are thinking about databases in general, there is always somebody with "root" privileges. In case of Enginio Data Storage, the developer has root privileges and can access all data. I don't see this as a bug as such.
If you want to make stuff private also for root users, you can consider using some encryption on client side. If you encrypt the data on client there is no way you - as a developer - can see the contents of the data. However, there might be a problem if you want to query data based on the unencrypted value. Another problem is that if you have 2 users and they can post messages to each other. They need to have shared secret stored somewhere...
Let me think what you think about this approach? Would this work as a workaround to solve your issue?
Product Manager, Qt Cloud Services
Hi Miska, I agree encryption is not a good (that is, convenient) solution here, not for simple retail-grade apps. That is, it would be easy to set-up, except you'd have deal with the drama of managing private keys  (not to mention the problem of sharing that you raised). We can already see the problem with email. PGP/GPG encrypted mail has been available for 15 years, and not so hard to use. But no one uses it.
You're right of course, at the end of the day there are always the database administrators who could see the data. And we never lose sleep over that, people happily communicate over skype, facebook, etc, or leave personal details on shopping sites, and don't worry so much that admin staff can read that information.
The app (cloud services) developer in this sense is just another database administrator who needs to be trusted. So it comes down to a question of the app's and the developer's reputation, whether they're worthy of that trust.
One difference is that the people or company responsible for a large service will have business systems in place to make sure their database administrators don't abuse the users' trust. But the app developer using Cloud services is just someone who wrote something, no checks and balances to ensure they are respecting user data. So again, it comes down to trust and reputation.
Then again what does it mean to respect user data? Google's entire business model is predicated on collecting data about people.
I don't know if the risk of rogue developers using Qt Cloud Services with the purpose of misusing user data is low. It might be low. Would scammers bother going to the trouble of setting up Qt Cloud Instances?
I could think of one midway step that could be implemented, halfway between full access to the developer and no access by encryption. There could be a category of Qt Cloud instance where the developer can not in fact read the data (though its unencrypted in the database. We trust the Qt Cloud Services admin). Search facilities and other data manipulations for the app could take place, the app will know the result but the developer cannot get it.
I suspect that's probably not worth the bother though. It's an illusion of privacy, since a malicious developer could anyway just have the app send the user data elsewhere. The developer doesn't need to be able to read it straight off the database. Mind you, the blackhat developer could do that too even if the data is encrypted on the Cloud.
Conclusion: the user has to be able to trust the developer, regardless of how the data is managed in the Cloud.
 Maybe there is something new there which Cloud services could provide, a facility to manage user keys. Like a cloud-based key-crypt.
I've the same concern for user-sensitive business data (prices for instances).
There are users who would prefer that some data are hidden from the developers.
In the context of a web app, I see a possible solution that doesn't (completely) rely on trusting the app developers (us), but only relies on trusting QCS.
The solution would be to use a JS library such as "this one":http://bitwiseshiftleft.github.io/sjcl/ and the user password. As the user password is hidden from us (you can't see it in the QCS backend), and the user can (in theory) inspect the JS client code and/or the data sent to the server, he could ensure that our support team can't see his sensitive data.
That method sounds more convenient than full-scale encryption. Simplifies keyhandling down to user password handling (but I imagine it breaks if the user changes their password?)
bq. but I imagine it breaks if the user changes their password?
Yes. To work around that issue, here's my idea:
- The first password is stored in encrypted form in another property of the user object. Let's name the first password the KPW.
- The KPW, not the current password, is used to encrypt / decrypt sensitive data.
- Each time the user changes the password, the KPW is re-encrypted with the new password in the user object.
Thanks Gadlim, that could be a decent solution.