[Request] Open-source Backend

Feature: It appears that only Cryptee's front end is open source. Please consider opening up the back-end as well. This would greatly improve transparency.

Hey there @gjhklfdsa! 👋🏻 Thanks a lot for stopping by!

I actually get this request quite often. There are multiple reasons why Cryptee's backend isn't open sourced.

1) The main reason why Cryptee, and most other privacy companies are hesitant on open sourcing their backend I think is because it risks exposing the tightly integrated abuse-prevention systems. It could quickly lead to all sorts of sign-up abuse, which isn't sustainable for a small company / startup like Cryptee. (financially or technically)

2) There really isn't a trust benefit to open sourcing the backend. Because: a) It isn't possible to verify the code that is actually running on the backend. b) This is also the reason why all the encryption happens on the front-end. So that you don't have to trust black-box servers running unverifiable code. Once you read the front-end source code, you can verify that your data never leaves your device unencrypted.

The second most common reason why I hear a request to open source the backend code is so that some users can run it on their own servers.

Cryptee is a project built for everyone to have a secure home for their files. And the largest majority of the internet users aren't tech-savvy, they can't (and shouldn't have to) set up their own servers, and perhaps don't even know the meaning of the word "backend" (and shouldn't have to). But they need a secure and private place for their files and digital belongings. Spending time towards open sourcing the backend, and make it in such way that it can work on any given server is a massive undertaking, and with the very limited resources Cryptee has at the moment, this is an unsustainable approach for business, growth and development.

Hoping these make sense! ✌🏻

All the best!

@johnozbay

There really isn't a trust benefit to open sourcing the backend. Because: a) It isn't possible to verify the code that is actually running on the backend. b) This is also the reason why all the encryption happens on the front-end. So that you don't have to trust black-box servers running unverifiable code. Once you read the front-end source code, you can verify that your data never leaves your device unencrypted.

This is very true however, encrypted or encrypted data leaks can be disastrous and this is what the backend helps with. Encryption may not always be "un-breakable".

The main reason why Cryptee, and most other privacy companies are hesitant on open sourcing their backend I think is because it risks exposing the tightly integrated abuse-prevention systems. It could quickly lead to all sorts of sign-up abuse, which isn't sustainable for a small company / startup like Cryptee. (financially or technically)

I totally understand however, abuse is very rarely an issue. Most companies will utilize cloudflare and/or SecureImage paired with email verification, making this problem basically impossible.

One option is to have a limited number of accounts per day. My NextCloud provider woeliki utilizes this. They just ask you to wait up to 48 hours for account creation and if they get spammed then they will ask you to re-try.

Besides, most abuse issues come from the front-end not the back-end.

Edit:

Cryptee is a project built for everyone to have a secure home for their files. And the largest majority of the internet users aren't tech-savvy, they can't (and shouldn't have to) set up their own servers, and perhaps don't even know the meaning of the word "backend" (and shouldn't have to). But they need a secure and private place for their files and digital belongings. Spending time towards open sourcing the backend, and make it in such way that it can work on any given server is a massive undertaking, and with the very limited resources Cryptee has at the moment, this is an unsustainable approach for business, growth and development.

I agree, most companies seem to have forgotten about this and everybody is always like "CLI WTH?!" and run away. However, you have to understand that Free Software is about cooperation on all levels and exchanging opinions. Technology is consistently evolving and I would love to see Cryptee evolve with it.

Hope this helps, gjhkldsa

@gjhklfdsa ✌🏻

This is very true however, encrypted or encrypted data leaks can be disastrous and this is what the backend helps with. Encryption may not always be "un-breakable".

Absolutely agree and understand.

I totally understand however, abuse is very rarely an issue.

I respectfully disagree. Especially because Cryptee's closer to the 'storage' side of things, and reddit/internet being full of users wishing to combine multiple cloud storage providers, this is a rather risky move. I'd be less hesitant say for example if Cryptee was just about to-dos etc. [ which btw is on the horizon 😅haha]

One option is to have a limited number of accounts per day.

I already do have a number-based sign-up quota system in place actually. It's 100 sign-ups from the same IP address per hour. However even this had a rather crippling effect on the first few months where the startup is growing rapidly, and getting featured on outlets like WSJ - MarketWatch. Most businesses in cities like NY use the same IP exit. So if multiple people from the same company start signing up even these methods fall short.

However, you have to understand that Free Software is about cooperation on all levels and exchanging opinions. Technology is consistently evolving and I would love to see Cryptee evolve with it.

100% agreed, on the same page & mission here! ~ This is also 100% the reason why I'm putting all my savings and livelihood on the line with this company / startup. ✌🏻As soon as I have more resources at hand to open-source the backend code, I absolutely will. 🙏🏻

Cheers ✌🏻

Was checking your GitHub to see if this software actually was open-source and found this issue.

I have premium subscriptions to other open-source end-to-end encrypted software like EteSync (calendars, tasks, contacts), Standard Notes (documents) and an E2EE hosted Nextcloud service (files, photos) because like you said, people can't (and shouldn't have to) set up their own servers. It's a very easy decision for me cost-wise to use the hosted service since otherwise you'd have pay to host your own VPS anyway and have the time/monetary cost of having to deal with all the maintenance.

But server-side being closed-source is a concern for me mainly because I want to know that in 20 years time when this service (most likely) won't be around, I'm still able to use this platform and take on the self-hosting maintenance burden if I have to. I personally don't at all want to self-host right now, but I do want to be able to.

I hope this is something you'll consider again soon, especially as the limited resources Cryptee has at the moment could be solved by gaining more customers like myself who will only use fully open-source SaaS products. There's plenty of other E2EE services like ProtonMail (email), Bitwarden (passwords), Riot/Matrix (chat) and more who have solved the issues you've mentioned so I hope you can take inspiration from their projects.

Hey there @ajvsol!

Thanks a lot for the thoughtful response. ✌🏻 I figured it's best to write down all my thoughts on this topic here, and be able to refer back to this thread when needed. So apologies in advance for the lengthy response below.

On the topic of service-lifetime and sustainability.

In my personal opinion, what's most important is to remember that technology evolves rapidly, platforms change, operating systems change, services eventually fade away, and the key here is to plan for that day to come from Day 1, so that users won't suffer.

A good example of what I mean by this is : AIM. AIM was once one of the most popular messaging platform, debuted in 1997 to fit that era's needs, and everyone I knew had an AIM in the 2000s. It was finally discontinued in 2017.

Just because it was around for a long time (20 years to be specific) + had global support of developers + a large community doesn't mean that we should keep using it today, since it may no longer be the best tool that fits our era's needs. And it doesn't.

20 years ago, back in 1997 when AIM first came out, we didn't have rich-media like we do today, we didn't have a need to send giant 100mb PDFs in-line in the chat itself, or send audio-messages or in-line photos/videos/ etc. AIM's developers did attempt to catch up with the modern era's needs and tried adding in-line photos / videos (but only in 2011 which is 14 years after its release)

For context, this year Facebook turned 14. And I don't think, during its first year, any one of us would be able to predict the functionalities FB possesses today.

So while I'm honored and really happy to hear that you'd consider still using Cryptee in 20 years, I don't think the internet / web / apps / services will look the same in 20 years if history is any indication.

So the key here is to assume and plan for the day the service will age, and build with portability in mind. So that users can move into the next era's next generation of services, instead of getting stuck in an ancient service for 100 years.

I specifically used "100 Years" here, because that is the ridiculous marketing claim Standard Notes is making on their page right now.

Our revolutionary, paradigm-shifting 21st-century business plan is to keep your information ready for the 22nd century. The notes you write now should be there for you in a 100 years. That's our killer app.

Here's a screenshot in case if they take that page down.

I don't even know where to begin with talking about how misleading and wrong this is – especially to a non-tech-savvy person. I truly respect their mission and what they're trying to do. And I'm not just trying to bad-mouth Standard Notes as a product here, I think it's an excellent piece of service that addresses a very specific need for some users. And us privacy services should stick together in our mission. However, I strongly, deeply disagree with them here. I don't think their approach in claiming their killer app will survive 100 years is good for the industry. I think it's a vastly misleading one.

I have an iPad 3 at home, released in 2012 (7 years ago) And latest OS it runs is iOS 9, released in 2015 (4 years ago) – and Spotify, a 26 billion dollar app, doesn't run on that iPad anymore.

So unless Standard Notes invents their own device, OS, file-system, storage technologies etc. This is not going to happen. Heck WiFi came to existence on September 1998; 20 years ago. For all we know 2-3 more WiFi-like technologies will come and go away in our lifetime.

So what my point here is, I'm not going to work towards making Cryptee's backend open source, only so that users can keep self-hosting in anticipation of the day it will sunset in 10 years. I will however consider open-sourcing to share knowledge with the FOSS community, and increase trust. But neither of these mean the service can / should be self hosted. This takes immense amounts of effort, and doing that alone will consume too much resources and shorten the life-span of the product in the first place.

My Sunset-plan for Cryptee is to plan for that day since day-1, and make it so that users can move their data away to future awesome services easily when/if the time comes in 20 years.

I can confidently say that I've been building everything, 100% of the service with portability in mind, and I often find myself in positions to make performance sacrifices to make sure that things are more cross-compatible. (Some examples of this are : Making sure Cryptee supports Markdown and can export HTML. Or that Cryptee uses the most popular JS encryption library OpenPGPjs which didn't have support for streaming encryption until this summer, instead of something like nacl, which had support for streaming encryption for years. Sticking with OpenPGPjs meant that files users upload can only be so big before they crash the browser, but it also guaranteed the longevity of the service and increased trust, by using an encryption library that is truly battle tested.

And finally, to address your final point:

There's plenty of other E2EE services like ProtonMail ...

Protonmail doesn't have their Backend open sourced either – and service-abuse is a very real problem I can relate to first hand. I cannot comment on how Bitwarden or Riot/Matrix can accomplish this, but I can say that financially, as a data-storage company, this a terrible idea.

I hope these make sense, and I apologize for the lengthy response once again.

Thanks for choosing & using Cryptee, and caring for it enough to make it a part of your life for 20 more amazing years to come my friend. ✌🏻

All the very best, John

[edit : typos]

Thanks for the comprehensive explanation. It's good to see that longevity is one of the values of Cryptee and that you're trying to ensure that through high portability and utilising popular open standards.

Portability can never capture everything though unfortunately, for example interlinking to other documents. I've got that issue now with a web app I use as a knowledge base and it has literally thousands of internal links - but there's no way to export that into another app easilyand it means I have to redo the links I had from other apps to them. I wanted to move that data into another similar app which is better maintained but I chose not to because it would be too time consuming to create those links again. I haven't checked out a markdown export of the inline attachments and interlinks Cryptee has yet so it might already have a decent structure, but this example is just to illustrate that portability has it's limitations.

In Standard Notes' defence I'd argue that it's quite possible to run Linux virtual machines and always have access to that platform for decades to come, and when exported it's all just plaintext so I'd be concerned if computers were somehow unable to read it 100 years on. I get your point regarding technology becoming defunct though, which is why I'm hesistant to make something an integral part of my workflow if someday I learn that the app has been sold or shut down or abandoned and I'm forced to expend time migrating to a new app and dealing with the hurdles involved.

I'm glad to hear you are open to it one day being open-source though. For now I'm reluctant to go all-in because there are apps with similar featuresets but I will test it some more and likely check up on it again once in a while. If you do decide to open it up I'd appreciate it if you pinged this issue again, but for now best of luck with Cryptee's future :)

Hey there!

Thanks a lot for reading through the long wall of text 😅

I think portability can and will work well, if done correctly on both ends. So It's important to think about not just the export as well as the import features. (the capability of the receiving app)

Cryptee can currently import Evernote documents with all interlinked PDFs, Audio, Video, Inline images, basically everything. So if you have an evernote document with a PDF attached, you can drag and drop the evernote doc into cryptee, and PDF will be uploaded, encrypted, stored alongside your document, and interlinked inline. (You can read Cryptee's import tutorials here, and more export features and tutorials are on the way now that we talked about it I've realized the tutorials are lacking.)

Is it 100% perfect? Sadly no. Evernote doesn't allow exporting multiple notebooks. So you have to manually export notebooks, and manually create folders in cryptee to drag and drop these export files. But this isn't a limitation of Cryptee. If Evernote allowed exporting the entire library, I would be able to enable this feature overnight.

In Standard Notes' defence I'd argue that it's quite possible to run Linux virtual machines and always have access to that platform for decades to come

Assuming you're a programmer / tech-savvy person. This is neither written in the fine print, nor implied. 100 years is a very long time. This also assumes you have the right input/output systems, and even interoperating cables/drives/readers/medium/machines and the knowledge required to transfer the files / formats. I can give a fantastic, real-life example of this which I had to honor to experience in-person thanks to my classmates. I had the unique privilege to watch, hear and witness my friends, classmates and professor resurrect Andy Warhol's previously undiscovered lost works, from a 1985 floppy disk. – If you wish to watch the full documentary (which is super cheesy btw), you can do so here. (Parts relevant to this topic start at 05:06) So I can say that having been there, and lived through this in person, it is VERY difficult to make things like this happen at company scale, especially for all users (and not just select few who can maybe emulate and run things)

As for your rightful worry that some day an app could be sold or shut down or abandoned. This is a perfectly valid one that I respect deeply. When this will happen is something I don't know and can't know. But I can confidently say that I'm betting my life's savings, livelihood, reputation and every waking day to making Cryptee last as long as it possibly can, and creating a private and secure corner for those who are not tech-savvy.

Once the day comes and the backend is open-source I'll ping this issue.

Many thanks for your thoughtful points and responses. 🙏🏻 Deeply appreciated!

All the best ~

One more thing: I just remembered a potential solution to service-abuse: FileSafe. It allows end-to-end encryption for attachments and stores them on your Google Drive, Dropbox or WebDAV.

This way you could significantly reduce the alloted storage space for free users and have them use their own free cloud storage accounts instead. This would not only reduce costs, but it would also mean you're able to focus less on data storage and more on making the best UX for documents/photo viewing.

Links to documentation, server repo and client repo.

cryptee / web-client

[Request] Open-source Backend #10