Add option to store encryption key.

[ryanpcmcquen]

This would obviously not be the default, but per our other discussion, an unsafe option that the user would be warned against.

[johnozbay]

Will first research the implications, and bring this question up to the beta-users and ask what they think. If I get a nod, I'll implement a non-sync'ing per-device setting. 👍🏻

Generally not a fan of this, due to this being against Cryptee's threat model. (even if optional, it still provides a way to break the threat model) But as far as convenience/security trade-offs go, displaying a quick pin-code on mobile devices could be an acceptable way to address this issue for those whose keys are very long.

[gjhklfdsa]

@johnozbay @ryanpcmcquen

I guess, I'm not fully certain who Cryptee's audience is. Generally speaking not everybody is technically capable or not-lazy? Not saying E2EE isn't good, and services can survive like Protonmail or Bitwarden but they must be easy to use. Like, Protonmail by default utilizes one password but can be moved up to 2.

[ryanpcmcquen]

@johnozbay, any movement on this?

[johnozbay]

@gjhklfdsa @ryanpcmcquen – Good news. I'm actually already working on making this happen. Overall progress : 85% complete, internally testing, checking for loopholes, cross-browser testing, and making sure there are no flaws in the sign in / launch / or threat model of the app overall.

1) It will be opt-in, so that users are aware of the privacy implications associated with borders like: NZ US CN

2) It will also have an optional pin-code users can opt-in to enable that encrypts the key itself on the device.

3) It will be possible to enter a sort of panic-mode and wipe all offline data & keys with relative ease to continue providing the deniability.

Thoughts? ✌🏻

[ryanpcmcquen]

@johnozbay, that is great news! I stopped using crypt.ee but this will make me revisit it.

[johnozbay]

@ryanpcmcquen oh no 😔Sorry man I know I've been neglecting some of the features you've requested, and had to unfairly prioritize some other features in the interest of kicking-off a better revenue-model quicker.

(i.e. photos use the most storage, more people are coming in for photos than docs lately = better and quicker revenue stream if I improved Photos first etc.) So I ended up switching gears a bit and worked on Photos to accelerate the growth of the service.

I'm back on the Docs train now, and I'll be adding tons of new features in the coming weeks. (pretty much every 2-3 weeks or so, a new major feature will be coming up. So stay tuned ✌🏻)

And apologies once again 🙏🏻

[johnozbay]

Just a quick update on this.

ead69f8 brings a new key screen & loading flow. Aside from the sexier looks of it, and slightly faster loading time, not much will feel different for now.

But this update actually changes & prepares the flow / logic internally for the new "remember key" mode / flow. Almost there!

[johnozbay]

Hey There! 👋🏻

Good News! 🎉

f9a7a10e45791f3040aacfae9b48555df65d07e6 brings storing encryption key on all mobile apps. (This includes PWAs and the soon to be coming Android app)

I've also built an optional pin-code mechanism to use instead of the encryption on mobile devices. Still testing this, and will announce this here once that's ready.

Let me know if it works as expected for you – and I'll close this issue 🎉

Thanks for your patience on this!

Cheers, J

[ryanpcmcquen]

@johnozbay, well done.

[TobiasDev]

How far off is the android app? Out of curiosity. :)

[johnozbay]

Hey @TobiasDev! 👋🏻

Very close! Coding = 90% done. 🥂

There's some mini deeper integration work that I still need to do, like share targets. (this will put Cryptee in the sharing popup, and bring the ability to share text/photos to Cryptee – and also ability to share from Cryptee, say if you want to share a photo with a friend, you'll be able to tap share and that's it) simple stuff, but since things need to be encrypted / decrypted in the background as soon as you touch the "share" popup, there's some interesting coding workarounds that needs to be done to accommodate these still.

And finally, I'm still chatting with my attorney regarding the Play Store payment processing situation. This one's the biggest holdback for iOS. (not so much for Android as far as I'm understanding but still a headache)

In short, one of the reasons why I can price things so cheaply is because Cryptee's a Progressive Web App (PWA). One of the requirements to use Apple's App Store or Google Play Store, is to use their own checkout system, on which they markup the prices by 30% on each purchase, and you're not allowed to use any other payment processor. You're not allowed to redirect user to your website to accept payments there either. And you can't tell your users why you can't accept payments on your app either. It's insane. Here's a screenshot from Spotify's iOS App, when you click upgrade to premium, it takes you to a website, but legally they can't even tell you why or what's going on: https://imgur.com/a/y4eSVbR

Both Netflix & Spotify are taking apple to court, and moved away from accepting payments in their apps for this exact reason actually. (Which in return lost apple 256m$/year from app store revenue, and is now going to netflix as it should have been) https://www.billboard.com/articles/business/8471988/spotify-netflix-bypassing-apple-app-store-billing-charges https://boingboing.net/2019/01/05/spotify-too.html https://www.theverge.com/2018/6/20/17479480/supreme-court-apple-vs-pepper-antitrust-lawsuit-standing-explainer

If you take the 30% "Apple Tax", then ~25% Value Added Tax in parts of Europe, 20% corporate income tax, server expenses and free users quotas out etc. it would leave a very very slim margin of profit. Not to mention the privacy side-effects of Apple / Google processing payments to Cryptee. 😞

And even if I were to switch to Apple & Google for payments tomorrow morning, I would have to use them for all subscription management incl. on the web app, which I genuinely dislike from a privacy standpoint + financial standpoint.

In addition to the financial aspects, native apps also have general privacy shortcomings. It allows companies like Apple / Google to control your release cycles. An example for this recently happened with Telegram. Per Russia's demand, Apple held back telegram's updates on the app store : https://www.engadget.com/2018/05/31/apple-telegram-ios-app-russia-app-store/?guccounter=1

To fight this I'm building the native apps so that they update their core by checking from Cryptee's servers, rather than App Store / Play Store. In general the store-downloaded app will be a shell that contains the encryption/decryption/integration core functions, and the rest of the app will be dynamically updated from Cryptee's servers. I'll only need to push updates through the app store / play store if there's a change to the core.

So once these things are a bit more clear, I'll also need to re-code/re-tool the payment processing section depending on the legal conclusion / outcome. Or the conclusion may be that this is generally a bad idea for financial / privacy reasons and I might hold back for a little longer until I have more financial / legal firepower to fight these issues.

Tons of things to consider basically, which is what's taking all too long. But it's aaalmost here. 🎉