Hacker News Reader

Comment by petters | Hacker News Reader

It's very annoying when the applications use sqlite with encryption. That is not open source, so regular language bindings can not be used.

View on HN

I'm not sure how slqite as your application file format has anything to do with open source, honestly. It's certainly super easy for open source projects to use, but a closed source proprietary application using an encrypted sqlite file sounds perfectly sensible to me?

We all win when folks decide to leave it accessible, but I'm not going to hold "encrypting a file format so that people can't easily reverse engineer it" against folks who are trying to sell software.

I guess he/she meant that the extension that encrypts the database is proprietary. I believe that was the only option for a while but now there is an open source alternative.

Is the open-source alternative bidirectionally interoperable with the closed-source version (i.e. it can decrypt the proprietary encryption and the proprietary version can decrypt the FOSS version)? If so, then that's handy.

The "officially blessed" (my wording) encryption for SQLite is SEE (proprietary):

https://www.sqlite.org/see/doc/release/www/index.wiki

There are third party encryption approaches for SQLite. One of the most popular is SQLCipher:

https://github.com/sqlcipher/sqlcipher/

Those two don't have compatible file formats. eg no interoperability

Not sure if any others do, but yeah it would be handy if there are.

It looks like the actual library to read/write an encrypted SQLite DB is licensed separately from the open source SQLite[1], so even if you have the encryption key, you can't access the encrypted format:

1: https://www.sqlite.org/see/doc/release/www/readme.wiki

> I'm not going to hold "encrypting a file format so that people can't easily reverse engineer it" against folks who are trying to sell software.

I think I'd mostly disagree. Selling an application is one thing, but the data itself is usually customers' and holding their data hostage is not a proper thing to do.

That's a tenuous argument at best, heavily relying on the application in question not offering any way to export your data, which many applications do come with. Just because the file format is locked, doesn't mean the data in it is locked. You just need the application to unlock it.

This is self contradictory.

Listen to what you're saying: the data isn't locked, you just need the... application, to... unlock it.

That's beyond tenuous, it's invalid.

You can say it's invalid but it's the fact of the matter, the reality, and since the data in question is only in the app because the owner of the data has access to the app it means that the data is not locked away from the owner, because they have access to the export function.

Almost as if different clauses can impart different context to the same word. The data is not locked, provided you have the application that manages that data. If you want to call it "locked" then "the application itself turns it into unlocked data for you".

That argument that a proprietary file format "locks" data ignores the fact that it's the pair {application, file} that determines whether your data is locked away or not. For instance: Microsoft Word data? not locked. You can trivially export it in quite a lot of ways. Can you easily get it from a traditional .doc file? Hell no, but that doesn't mean the data itself is inaccessible. Instead of using sqlite, or xslt, or PERL, or whatever, you use word.

Reply on news.ycombinator.com