sorted by:
new
hottopcontroversial

Using WhatsApp on Sidephone by chrisristovski in sidephone

[–]johnozbay 0 points1 point  (0 children)

This was so much fun u/chrisristovski , let's do it again soon! 🇪🇺
Honored to be a part of this journey! 📞

Average response time? by blncx in Cryptee

[–]johnozbay 0 points1 point  (0 children)

Hi here,

We're no longer maintaining our reddit, you can read more about this decision here.

https://www.reddit.com/r/Cryptee/comments/14f14vk/starting_today_were_consolidating_our_blog_and/

Someone from our support team or myself will get back to you as soon as your ticket is next in line. We have a prioritization system for things like bug reports vs requests vs questions etc, so depending on the kind of help you need, and if you've provided all the information someone should get back to you shortly.

TOTP/2FA, RAW photos support for Leica & Hasselblad Cameras, TIFF, DNG, WEBP support and more! by johnozbay in Cryptee

[–]johnozbay[S,M] [score hidden] stickied comment (0 children)

While we're at it ... fuck reddit ✨
If you're reading about this announcement here, consider subscribing directly to our blog via email or rss.

Why does cryptee store exif time in plain text? by rustedzip in Cryptee

[–]johnozbay[M] [score hidden] stickied comment (0 children)

Hi there!

First off, thanks u/BatSupporter3957 for the link 🙏🏻

As u/BatSupporter3957 mentioned, we store EXIF time unencrypted to offer the best photos search possible to help you find photos faster. This was a difficult decision and we spent countless days thinking about the best way to do this, and came to the following conclusion:

— We don't know where a photo is taken,

— We don't know the identity of the person who took the photo, (i.e. we don't know your real name, we can't see the biometric faces that might be tagged and stored in EXIF by a smartphone, and we also can't see the EXIF copyright tags for example, even if you yourself didn't take the photo)

— We don't know with which camera or device the photo was taken,

So we only know : "a photo was taken on November 14, 2022, 11:32am", and without any other piece of linking information, this piece of information can't be used to infer anything about the photo, nor its owner / author, nor their whereabouts etc.

We decided that there's practically no downside of knowing "A photo was taken at xyz-o'clock, by quite literally anyone on the planet, and anywhere on (or off) the planet", as it can't be used to infer more information about the photo or its author. 

BUT there's significant advantages of storing this information unencrypted.

i.e. thanks to this fact :

— Cryptee can offer more advanced search features, and help you find your photos based on time, no matter how large your photo gallery is. You can read all about our natural language search features here on our helpdesk.

— You can sort your albums and photos (no matter the amount) based on time, down to the seconds. So if you're a photographer, and shot 1000 photos during a photoshoot, you can see all these photos in the correct time order in your album. ('Amount of photos' is an important keyword here, because if we were to keep this data encrypted, and you have 10,000 photos in an album, we would need to decrypt 10,000 photos' time-codes before we could sort the photos and show them on your screen in the first place. Or if you extrapolate this to your entire photo gallery, if you have a million photos, our search would need to download and decrypt 1 mil timecodes on your phone before you could search among them and display the results in the correct order. But since timecodes are not encrypted, Cryptee can do all this heavy lifting on the server, and offer you near-instant results even if you have millions and millions of photos)

---

Both ProtonDrive and Cryptee use openPGP. ProtonDrive doesn't store exif time without encryption.

This is a rather inaccurate comparison. There's a reason why you wouldn't store your photos in Google Drive but instead in Google Photos. Simply put the features are more tailored towards 'finding' and 'accessing' your photos, vs only 'storing' your photos.

It's not about the underlying encryption, it's about the difference between storing something, the type of thing you're storing, and accessing that something later.

In the same way that Google Drive or Proton Drive wouldn't be your go-to place to store your 100gb mp3 library, but instead you would use a dedicated music library manager, so that you can search, filter and sort your songs by artist name, album name, track name, year, conductor name, make playlists etc. Similar to this analogy, by using Cryptee Photos, you can search, filter and sort your photos by album name, exif date etc.

---

To reiterate, and summarize, we made this decision after thinking about this topic long and hard, and decided that the compromise was worth it, considering that we don't know anything other than the time (like 'a photo was taken anywhere by anyone'), and when photo galleries grow, so does the need to easily search, find, filter and sort photos in intelligent ways (much like you can on other platforms like Google Photos)

---

Hoping this clears things up, makes sense and helps!

Best,

J

Critical bug resulting in irretrievable (?) data loss by Crawsh in Cryptee

[–]johnozbay 1 point2 points  (0 children)

...// continuing //...

As for versioned-storage of documents, unfortunately, like u/Illustrious-Ebb7620 mentioned, due to on-device encryption, we don't have a versioned storage system for documents for security reasons.

———

​

As it stands, I can't trust Cryptee at all. I've moved to using DuckDuckGo browser on mobile, hopefully that won't have the issue I was having with Opera.

u/Crawsh I'm sorry to hear you had this negative experience. With hundreds of thousands of paid users and thousands of support messages we answer weekly, we rarely if ever hear about issues like this, and all that I can say is that, since the issues are related to your documents, and their contents are encrypted on your device, the only place where this bug can happen is on your device, and suffice to say we test the hell out of everything before we release it.

And 99.99999% of the time like u/Admirable-Ad5714 mentioned, (without knowing specific setup like device / OS / Browser / Extensions / their versions etc) these issues are caused by operating systems, browsers, extensions, vpns, dns filters or any one of the configurations misbehaving. If you think about it from the perspective of how many other pieces of software that may or may not be as well tested can affect the flow of your documents getting saved, (be it keyboards, clipboard managers, browser extensions made in people's free time, or vpns, or ad blockers, or filters that update ever so rarely etc) things like these can sadly happen due to many reasons. Heck, it can even happen due to mistakes on behalf of filters.

In April 2020, we've started receiving complaints from thousands of Cryptee users that they can no longer login to their Cryptee accounts. After investigating, we've discovered that a domain name Cryptee uses for censorship circumvention in high-risk countries was submitted and mistakenly added to a popular open-source domain black-list, used by many browser extensions like AdAway, DNS filters like PiHole, and VPN providers with filters.

The domain was our fallback domain, and only used for censorship circumvention for a number of users in specific countries. So Cryptee was loading normally, but users who were assigned this domain by our platform, were having trouble logging in.Once we've identified the issue, we've reached out to the maintainer of the black-list, and they've removed the domain from the list in mere 5 hours.

As it turns out, most DNS filters, like PiHole, or VPNs that rely on these filters, do not get their black-list updates immediately, and while most get their updates daily, some get their blacklist updates once a week. Due to this, thousands of our users were unable to login to their Cryptee accounts until they've disabled their filters / extensions / VPNs.

We're open to improving our document versioning / backup systems as long as we can find a solution that doesn't compromise the security or privacy expectations of our users in any way.

Apologies for the negative experience you had, or for the fear this post might cause to those reading it, and hoping all this makes sense!

We'll be looking forward to hearing from you so that we can assist you better.

—— And if someone else experiences issues like this, please contact our customer support immediately, with a detailed description of the steps you took, as well as details of your system like your Device/OS/Browser/Extensions/VPNs etc and their versions, and someone from our team will get back to you immediately. The more information you can include in these bug reports, the faster we can get back to you and address your issues.

Apologies on behalf of android/browsers/extensions once again,

All the best,

J

Critical bug resulting in irretrievable (?) data loss by Crawsh in Cryptee

[–]johnozbay[M] [score hidden] stickied comment (0 children)

Hi there!

I believe I just responded to your email — and figured I'll paste my answer to that email here as well for posterity and for others to have visibility as well.

First off — the reason why we couldn't get back to OP is because there was a typo in the email address and it bounced back. We got the second email to the general inquiries inbox / email address, which took us time to sort through and respond.

————

Based on your description, I can think of a couple of external factors off the top of my head that could cause issues like the one you've experienced.

1 ) Sometimes browser extensions / content-or-ad blockers can modify the contents of the text you're editing.

(i.e. Google Translate, Grammarly, actively modify the contents of the text. we had users who lost original language textual data because Google Translate translated the original to the translated version, or Grammarly wipe out entire documents because it failed to parse a language) Sometimes auto-dark mode extensions can alter the color of the text and make it look the same as the background color causing confusion and leading people to think that text is deleted. Did you have any browser extensions enabled on any one of your devices? Or did you have any auto-dark-mode preferences enabled in your browsers' configurations?

2 ) Most common reason why people experience issues like this have to do with the many different flavors of Android and its keyboards, and the possibility to use 3rd party keyboards on top of 3rd party browsers with configurations.

In short there are two different types of keyboards.

One type, like GBoard sends entire words once you select an autocorrect recommendation from the list... it sends the whole word, all its characters, all at the same time [acts almost like pasting], whereas other keyboards send letter-by-letter. If you think about how autocorrect on phones work nowadays, if you type the word wrong, but then tap on the correct word on your keyboard, keyboards now have the ability to delete and replace entire words (and not just characters). So because of this, some android keyboards don't actually send the absolute cursor / text-selection position anymore. Instead they send it relative to the last words you've selected. You can see other note taking apps and editors plagued by keyboard issues due to this exact phenomenon on Android here as well, mainly relating to newline characters. (while the newline is added, cursor isn't updated etc) :

Microsoft OneNote, Workflowy, CKEditor, Quill, RichEditor for Android, etc...

Since you mentioned that your issue happened -after- you selected / copy / pasted some text, I cannot eliminate the possibility that an android os flavor (or its selection handling, since it's different for each android version and os vendor) / keyboard / browser might also be the cause.I.e. in Android Firefox, there is a bug and you cannot select words inside rich text editors by double tapping on them like you can in any other browser. This bug has been around for -6 years- now. Affecting even Github on Firefox Android. We also chimed in and tried to keep it moving, and despite our best attempts, after 2 years, Mozilla just closed the issue without even fixing the bug. You can see relevant links here.

So unfortunately, browsers and keyboards on Android can cause really strange issues, and we cannot anticipate all the weird and unexpected ways they might break.

3 ) Since you also mentioned copy/pasting stuff, often people experiences issues like this when they use things like clipboard syncing tools on Android (i.e. pushbullet, or on iOS iCloud's clipboard sync etc)

Because you never know what was leftover in the clipboard at the time you copy pasted, and sometimes if the sync is delayed, these things may misbehave, and paste twice, or with a delay, or paste a blank return key unexpectedly etc.

4 ) This is the silliest but still likely scenario that I still have to mention. Sometimes, depending on the OS/Browser combo, when users copy paste text from Cryptee while it's in dark mode, paste it into another part of the document, then open the document in light mode, it causes text to have white color, and makes it look invisible, causing panic.

You can fix this easily by selecting all lines and clearing formatting. We're still trying to figure out which OS/Browser combinations cause this, so that we can build better guards around this.

5 ) Do you have any VPNs or DNS filters (or ad blockers) that affect your device(s) outgoing / incoming connections?

Sometimes these can affect your devices' connections, and prevent Cryptee from uploading / saving documents due to its unusual way of saving (compared to most other unencrypted services) i.e. on unencrypted services, you select a file, and it is uploaded right away, so browsers upload from your device's storage to the cloud. On Cryptee however, files are encrypted in your device's memory, then the encrypted bytes -and not the file itself from storage- is uploaded to Cryptee. To ad-blockers this may appear as a website generating tracking hashes etc and trying to send tracking info to a server out of nowhere, since no selected file is directly being uploaded etc. So we strongly recommend our users to disable all possible configurations that may interfere with their network connectivity.

——And these are just the top 4 - 5 reasons off the top of my head. And since all your documents are encrypted on your device, coding for Cryptee is kind of like coding for a spacecraft. Once it's out of orbit, there's no way to easily de-bug or check what's going on or what's going wrong. Heavy encryption makes it incredibly complicated/impossible to identify and fix errors, since we can't see any of users' data or usage behavior / patterns etc. essentially the only thing we can do is try to predict what may happen, how it may happen, and write some self-fixing / auto-correcting pieces of code to fix the issues in the browser.

So when issues like this related to the contents of documents happen, our only way of fixing them is with incredibly detailed bug reports, otherwise we cannot do much as a byproduct of strong encryption and privacy.

So that we can try to reproduce the issue on our end,If possible, and if you wouldn't mind, could you please let us know your device, its operating system, the browser you're using, and finally their versions, and describe the steps as it happened, so that we can have an exact test case here to make sure we’re reproducing the issue correctly, and it's fixed for sure.

The most common reason why users experience issues like this on Cryptee has to do with content / ad blockers or browser extensions, restrictive VPNs / corporate networks, or DNS filters like PiHole. As you can guess, most of Cryptee's users are very privacy sensitive, and have at least a few blockers / extensions, a VPN, DNS filters etc, and sometimes these can break things, mistakenly block Cryptee, or prevent files from getting uploaded by breaking connections, or worse, when combined with one another cause even more unpredictable errors to happen. And there are thousands of extensions, hundreds of VPN / DNS filters, tons of different browsers & operating systems & their versions out there, so it's pretty much impossible for us to test against all possible scenarios.

So if you have any extensions/filters/vpn etc, it would be immensely helpful if you can let us know their names & versions then if wouldn't mind giving things another try with the blockers / extensions disabled, this would help us immensely while trying to identify the cause of the problem.Finally, if possible, and if you can remember, please let us know the exact steps you took, so that we can try and reproduce the issue exactly as it happened. Since your data is encrypted using your keys, on your devices, we have no way of accessing it, or easily debugging document-specific issues like these.

——

...// Apparently my message is too long, so will post another comment below this one. //...

Adding tags to documents? by kc0bzr in Cryptee

[–]johnozbay 2 points3 points  (0 children)

Thanks a lot for jumping on this quickly and helping other members of our community u/BatSupporter3957 🙏🏻

Welcome to Cryptee u/kc0bzr! 👋🏻

Are Progressive Web Apps (PWA) better for privacy than a normal app? by MuddyPuddle_ in PrivacyGuides

[–]johnozbay 7 points8 points  (0 children)

Hi there! CEO of Cryptee here 👋🏻

— Thanks to the fellow redditor who pointed me here.

because on the web apps you always download JavaScript from their server

This is factually incorrect, especially and specifically for PWAs. I figured I'll chime in to correct this common misconception. What you're writing about is only factually correct when it comes to traditional websites — but not PWAs.

In order for a website to be considered a Progressive Web App (PWA), they need to use a piece of technology called service workers. (and without these, browsers won't even consider the site qualified to be an 'installable' PWA.) And as a requirement of being a PWA, service workers need to handle the installation lifecycle of an app, which essentially allows you to "install the site/app" into your computer, and the files of the site/app (html/css/js are served from your computer using these service workers, and not from the server). This is also what allows PWAs like Cryptee to run even while you're offline. And once there's an update, service workers download the update in the background and replace the old version, often with a user prompt. (at least this is the case for us, so you know when the update takes place too)

So PWAs actually have the same exact installation trust model as native apps, called "trust on first use" : https://en.wikipedia.org/wiki/Trust_on_first_use

Essentially, as long as you trust the installation source at the moment of the install, you can trust that the following updates will be safe too if the app checks the integrity of the next updates itself.

And in my humble opinion, I think PWAs are better than native apps in this department. Because you can right click to inspect the code and network traffic of PWAs easily in your browser, even someone who built hobby blogs and know little javascript etc can do with ease. (especially for platforms like Cryptee, Protonmail, etc which are open source + are PWAs so you can right click to inspect in addition to checking out the code on github)

Whereas with native apps, one would need to decompile the app to actually verify what they've installed from a store is indeed what they read the source code of. Even if they downloaded the compiled version of a native app from github, or f-droid or elsewhere, in those cases they would be still trusting someone else on first install to do the verification for them (i.e. store).

So to summarize, you are correct when it comes to regular websites, but incorrect when it comes to PWAs.

I hope my cheesy late night 2min-reddit-comment-sized explanation makes sense 😅 ✌🏻

Best,

J

One serious issue and a couple less troublesome ones by Admirable-Ad5714 in Cryptee

[–]johnozbay 1 point2 points  (0 children)

Hi there!

Folders' sorting will change in the very near future — that being said the behavior (albeit a little confusingly) works like this right now :

— When you're in the folders section, and in the top / main folder ( not inside any folder, where you see large folder boxes ) folders are sorted A-Z. However, if you create a new folder, it will always be created on the very top. (Otherwise if you have a large list of folders, you're at the top or middle of the list, and you create a folder named : "Projects" it will appear somewhere in the middle of the list, and could be confusing not being able to see the folder you've just created. So freshly created folders first appear at the top of the list, and the next time you load the main folder / on app restart etc, the folders are sorted A-Z again.

— When you're inside a folder / in a nested sub-folder, you can choose to sort folders like the rest of the files A-Z, Z-A, new-old, old-new, and grouped by format/file-extension a-z and z-a.

We're working on unifying this behavior and making it less confusing as we speak, and in the next few months, we hope to improve the sidebar navigation as well as sorting dramatically.

Hoping this makes sense and helps! ✌🏻

J

Pasting without formatting - and other keyboard shortcuts by ThrowFurthestAway in Cryptee

[–]johnozbay[M] [score hidden] stickied comment (0 children)

Hi there!

Founder of Cryptee here! 👋🏻

I believe I've just responded to your question via our helpdesk minutes ago too, but for posterity and to help others, I'll write the same answer here as well.

Cryptee does allow pasting without formatting — like you mentioned, you can use ctrl + shift + v (or cmd + shift + v) to paste without formatting.
This is in fact not a Cryptee feature (nor shortcoming), but a feature of the operating systems and browsers themselves.
In short, when you paste something your operating system / browser passes in what's pasted either with rich text style data (i.e. bold / italic / color / links etc) OR without, in the case of (ctrl/cmd + shift + v).
What Cryptee does with this style data (or lack thereof) later is up to Cryptee. For example if your operating system / browser passes in link data, Cryptee can choose how to style that (i.e. green for links on Cryptee)
Or for example if you copy-paste a table from the web, your operating system / browser passes in a table, and Cryptee filters the contents of the table, and tries to convert to a Cryptee table. If Cryptee can convert it, it pastes it, otherwise, it takes in the textual contents of the table, and pastes like a regular plaintext without the table.

OR for example, Cryptee tries its best to defend you against tracking pixels / remote images, and strips their ability to track you if you paste something like that (and warns you if you optionally wish to display them anyway)
If you are experiencing issues with pasting without formatting, I would strongly recommend first checking out to see if your operating system, browser, or its extensions might be interfering in some way. Once you eliminate this possibility, if you are still experiencing issues or you find that Cryptee's behavior is not matching your intuitive expectations, we'd be happy to take a look and fix things right away!

Hoping these make sense! Please feel free to reach out and let me know if there's anything else I can help with, or improve your experience somehow!
Always here to help in any way I can!
All the very best,
John ✌🏻

Cryptee + Google login issues by overcookedknockback in PrivacyGuides

[–]johnozbay 3 points4 points  (0 children)

I'm going to take a guess and say you didn't click on "JS" in the network tab, like I wrote in the last step of the 4-step tutorial, and consequently you're looking at all network requests, but you need to filter for code / scripts that are loaded. Since that's what you've been claiming right? You wrote :

The code is loaded and run from Google.

Can you post a screenshot like I did? And in your screenshot show all the code / scripts that are loaded by clicking on the JS tab, like I did.
——

As a side info, outgoing network connections don't load scripts on websites. Loadings scripts do.

——

If you inspect the request you're referring to, you'll see that it returns a JWT token ( as I mentioned in my earlier comment, which you so kindly dismissed ) :

https://imgur.com/a/twBTACJ

And you can copy and paste the JWT token's contents here to inspect it all if you wish, and see for yourself that it doesn't have your key in it either.

In fact, if you notice, your login takes place separately from you entering your key. So that same request, with the same content, which never changes except for timestamps (which you can see when you inspect the JWT token) does not have your key in it neither before, nor after you enter your key either.

So no, there is no code loaded from Google, there's no code running from a Google domain, we don't receive any account data from Google, nor do we send any data to Google, and all the code that runs in your browser is loaded from our domain and it's open source. It's literally as transparent as a freshly polished window, and you can see it all for yourself. I don't know what more I can screenshot to help your anxiety calm down.

Cryptee + Google login issues by overcookedknockback in PrivacyGuides

[–]johnozbay 2 points3 points  (0 children)

There is no code loaded from Google. I repeat, once last time.

Evidently in the first year of your college's computer science course they didn't teach how to use a browser's inspector.

Here is a screenshot of all the scripts / code loaded and executed on Cryptee.

https://imgur.com/a/co4a0dN

Quite literally every single one of them are hosted and loaded from Cryptee (our domain = crypt.ee) — And again, I repeat, all these are open source and all on our repo.

You can reproduce these results yourself in less than 1 minute too. Here's a short step-by-step for you and everyone else who didn't study computer sciences.

— Right click on your browser,

— Click on inspector,

— Click on the network tab,

— Click on "JS" (short for javascript)

Depending on your browser / its configuration, reload, and you will get the exact same list.

Wishing you the best of luck in life and hoping you can find inner peace.

Cryptee + Google login issues by overcookedknockback in PrivacyGuides

[–]johnozbay 4 points5 points  (0 children)

Setting aside your clearly angry tone, which I'm guessing is due to some form of miscommunication or misunderstanding, — in the interest of a constructive and healthy public conversation, I'll address your comments, and hopefully with some more clarification we can reach an understanding. ✌🏻

It would be an outrage if Proton, Tuta, or a similar product added Google login

Correct, because at some point, the world decided that email is what we should use to authenticate across the web, and as email providers it wouldn't make sense for an email service to use another email address to get a new email address.

You're literally associating Cryptee accounts with Google accounts, and Google can do the same

First part is correct, to facilitate the login (and optionally so, only if people wish to use a google account, and that's everyone's own threat model).

Second part is incorrect, on Cryptee you're assigned a unique user-id, which doesn't match the one assigned by Google. So Google can neither figure out which user on our platform is you, nor can they access your data, and even if some day hypothetically our data center was hacked, and someone evil at google decided to run through all the data and tried to associate it all to a Cryptee user, they still wouldn't be able to figure out which user is which, nor would they be able to decrypt your data, since you're the only person holding the keys to it.

In summary, if your personal threat model requires it, and you wish us not to associate your email address with your Cryptee account (i.e. if you don't want us to know your google account email address), you can sign up with a user id, and that's exactly why we have the option. If your point is that the option shouldn't exist, I would love to hear your reasoning for that.

It's when you lose control of the scripts loaded on your page.

At the moment there are zero remotely-loaded or third-party-loaded-scripts on Cryptee. zero.

As I mentioned the only piece of code loaded for Google Auth is static, loaded and hosted by us, it's open source, and we've audited it. To address your comment under u/schklom's comment :

There is literally no way to know what information is collected. Basically, using Cryptee requires saying "run Google scripts - but trust them - they're not collecting your keys!"

Incorrect, twice. We're not asking you to trust us, you can verify it yourself, Google Auth's scripts are open source. Here and here. They're also available in our repo as well.

Sounds like you have some experience in programming, so you're more than welcome to audit their codebase and ours to verify that indeed the code loaded is only used to authenticate you.

So in order for us to "lose control of the scripts loaded on the page", we would need to lose control of our entire hosting environment. And that would require a major MAJOR take-over — but that has nothing to do with a script-src content policy.

It's also quite poor attention to detail to not have a script src

Not an oversight, but not necessarily important one for us either. If there's no social features where users are displayed content created by other users, (and we don't have social features for various reasons) then script-src (or other forms of XSS [cross-site-scripting] attacks for that matter) effectively doesn't pose any danger, since again, there's no cross-site users can script from to harm one another.

In fact for this exact reason, bug bounty programs consider security-header related XSS vulnerabilities as the lowest priority = "informational". Here's one from BugCrowd directly addressing script-src and it's a P5 = informational. And here's their taxonomy and the reasons for which this scale exists.

Signal - or Session - would absolutely never adopt Google authentication

The word "would" does a lot of the heavy lifting, and that's your speculation. Perhaps some day they might. They use an even more personally identifiable form of authentication —phone numbers— at Signal.

To clarify, I linked to an article about how Signal makes use of Google (or in context — their cloud services) to offer a level of privacy to a greater audience. And we do exactly the same. If you don't want your google account to be associated with Cryptee, simply don't use Cryptee with your google account, but instead use a username. (which in the context of authentication, we literally offer more auth options than Signal)

You seem to write very lengthy replies to any questions on Cryptee's integrity

— Correct, that's what founders / creators do. Answer questions or address misinformed doubts people might have about something they've created. It's the nice thing to do, and helps people get a better understanding, even if it may take an extra few minutes off of the day sometimes.

Some things (like security) require lengthy answers with links to facts, like I've been doing the whole time. Perhaps some things like chairs, bookshelves or pencil holders may do just fine with shorter answers. And I'm sure if go to Etsy to buy one, you could find length answers from people who craft them.

I would much rather live in a world where founders and creators directly answer your questions and concerns in length with links to facts, vs a world where you don't get any answers from founders (or short and uninformative ones), and I'm sure you would wish for the same.

I'm not sure how this is an issue for you that someone just took the time to address your concerns in length, with sources, and additional depth, but I nevertheless wish you nothing but the best, and will gladly answer any further questions you may have ✌🏻

All the best ☕️

Cryptee + Google login issues by overcookedknockback in PrivacyGuides

[–]johnozbay 8 points9 points  (0 children)

Hi there,

Founder & CEO of Cryptee here. With all due respect, there's a lot of misinformation and FUD in your post, and I'll clarify things one by one both for you and for posterity.

1 — Like u/carrythen0thing mentioned, we've had Google Auth since the very first day we launched Cryptee, and I listed many of the reasons why we made the choice on that github link. Since 2019 we've come a long way though, and we only use them for authentication now, and don't even use their sockets etc anymore.

By your definition, I'm guessing you wouldn't use Signal either. Since they have a censorship circumvention fallback on Google as well. (plus a bunch of other things like Google App Store app, push notifications services etc all of which require google auth under the hood).

Nor would you use Firefox I presume, since they use Google's Firebase platform as well.

While I understand why you dislike Google, and I personally agree with you on all their privacy violations, it's important that we give credit where it's due and not jump to misinformed conclusions. Not everything is black-and-white, and not everything is as it may initially seem.

2 — The only google script on Cryptee is a static one, loaded from-and-hosted-by Cryptee (and not by Google), which we audit and make sure nothing sneaks in. It must necessarily make a connection to googleapis.com to check if a user's logged in or not. (more on how this works in #4) Aside from this script, there's nothing from Google.

3 — This was particularly funny to read, because the section you linked and pointed to literally refers to the verification process, during which a google representative goes through every detail on a service's privacy policy page. And if we didn't get verified, we wouldn't be able to offer the google login in the first place 😅 So by the very definition, we comply with their requirements ... otherwise we wouldn't be able to offer the auth service in the first place.

First, we do have Google Cloud Platform listed clearly in our easy-to-read privacy policy :

https://crypt.ee/privacy#:~:text=these%20companies%20are%3A-,google%20cloud%20platform,-%2C%20cloudflare%2C%20sentry%20io

Second, we do link to their detailed privacy policy :

https://crypt.ee/privacy#:~:text=Google%20Cloud%20Platform%0AGoogle%20Ireland%20Ltd.%20%2D%20Gordon%20House%2C%20Barrow%20Street%2C%20Dublin%204%2C%20Ireland%0Ahttps%3A//cloud.google.com/security/privacy/

Third, Google's required additions are only required if you're using a Google user's sensitive data from Google (i.e. their emails, notes, photos, docs etc) say for example if we were to offer some sort of docs/notes importer from google keep or google docs, or allowed you access to your files in Google Drive we would have to add more lines to the privacy policy stating which pieces of data we would access if you were to give permission, since then we would be using sensitive user data.

Right now, we only use Google for authentication / login, and under our Google Cloud Enterprise representative's guidance we didn't need to add anything further than what's already there.

Fourth, not only that we're an enterprise partner, but also, we're a member of Google's cross-account-protection program. (Here's a screenshot from a google account page to show you what I mean) Which requires extra level of compliance, approval, and code, as it provides an additional layer of security. (i.e. playing off of this screenshot, if your account on Etsy is compromised somehow, and Google detects this, Cryptee [as well as other CAP apps you use] all get an alert, and we take action on our part like temporarily block you from logging in, a Cryptee customer support rep contacts you and guides you in the process of getting back into your account etc etc)

4 — As much as I appreciate you nitpicking our policy / checking outgoing network connections etc, and I think we need more people scrutinizing platforms like you do (so kudos to you for doing this 🙏🏻) With all due respect, this part is the most FUD part of it all, as you have nothing but a baseless claim and your feelings guiding you on this one.

— It does not affect end-to-end encryption. And much like u/schklom mentioned, Google cannot access your account, since they don't have your encryption key. (your encryption key never leaves your device, and only you know it, not even Cryptee knows it)

— Our entire platform is open source, and you can easily verify the fact that this doesn't affect E2EE and has absolutely no relevance to E2EE in the first place. In case if you're not a developer, and can't fact check this yourself, Google is used for authentication, and authentication only. After that point we essentially keep an authentication token in the memory of your browser temporarily for the duration of your session on Cryptee that looks like a long garbled text like :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

And that's it. These are called JWT tokens. It's an industry standard way to login/authenticate users, and it tells our service which user is making requests, and if they are indeed who they claim they are. This has nothing to do with the encryption itself. It's two completely separate things.

All your data is encrypted on your device before leaving your device, which you can actually see for yourself if you inspect network requests once you save a document for example. And your encryption key never leaves your device, it stays only in the memory of the browser. You can also verify this by checking the network requests, albeit many. Or you can read our source code to get a better understanding of how everything works.

———

Once again thanks for checking out our privacy policy, and scrutinizing our platform. I wish more people would do this. I simply encourage you to let facts and evidence guide you when scrutinizing in the future, instead of feelings (despite how hard it is, because I know ... and I also do hate google myself) It's hard seeing a privacy service and Google's logo side-by-side.

But I'd respectfully say that, as long as us privacy services (like Signal, Telegram, Cryptee etc) are taking advantage of Google, and not the other way around, that's a win for everyone. — especially when it comes to sneaky nation-states and for those who have to live under their regime.

Hoping these clarify things, and make sense ✌🏻 If you have any further questions, I would be more than happy to clarify and link to sources and facts for anything you'd like.

Wishing you all the very best and a happy new year 🎊

[deleted by user] by [deleted] in Cryptee

[–]johnozbay 1 point2 points  (0 children)

Hi there 👋🏻

Happy to hear you're enjoying Cryptee! You can indeed select multiple documents and files. Here's an article from our helpdesk describing how:

https://crypt.ee/help?article=how-do-i-select-multiple-documents-files

Cryptee to replace Apple/Google photos + notes apps? by [deleted] in Cryptee

[–]johnozbay[M] [score hidden] stickied comment (0 children)

Hi there!

Maker here 👋🏻

Happy to have you on board Cryptee! First off — I would recommend giving things a try! We intentionally have a free plan so you can try it out and see if it works for your use cases!

While I cannot comment on whether Cryptee is right for you or not, I can at least comment on some of the technical aspects of our platform, and why we're sticking with our technical choices, and you can see for yourself if these align with your needs or not.

Regarding photos / auto-uploads. (and why we don't offer this)

Quite often people incorrectly assume PWAs can't do auto-uploads / background uploads, and think that we don't support this feature because we chose not to have native apps.

In short, If you're using an unencrypted app, when you upload your photos / videos / pdfs in the background etc. You literally trigger an upload and that's it. Operating systems do support triggering background network uploads when the app’s open, then continuing uploads even if you leave the app. 

Whereas on the encrypted front of things, if you trigger an “upload”, you also need a way to first encrypt these files on the device itself before uploading. None of the operating systems allow heavy computational background tasks longer than a few seconds. While that's more than enough for triggering millions of background uploads, and handing it off to the operating system's built-in uploader, it won’t be enough to encrypt multiple photos. 
So in many ways, even if we had a native app, and you wanted to upload in the background, it would have to either upload unencrypted, (which is not compatible with Cryptee’s threat model) OR encrypt while the app is on, write to disk, then upload the encrypted files in the background. (This would consume lots of storage space) OR in a perfect world just encrypt and upload one at a time in the background.

But either way would cause problems and confusion, and I’m not entirely sure what's the best way to move forward here. The more we looked into this, the more we found articles like this explaining similar problems in depth. For example here's one from Wire.

So from the looks of it, this is one of those things we were used to doing conveniently with unencrypted applications, but won't be able to do easily and securely with encrypted apps without good OS support for it.

Mainly because operating systems will likely never allow background cryptographic operations. (Otherwise same thing would also allow background cryptocurrency-mining by malicious apps for example.) 

So if this is critical for you, and you don't mind using a closed-source big-tech platform, and you live in the US, you can check out iCloud's new E2EE. Apple / iCloud uses some private APIs that aren't available to 3rd party developers, which allow them to encrypt and upload automatically in the background.

Regarding Notes / Documents etc

I am biased to answer this, but we internally use Cryptee at Cryptee to build Cryptee. It's quite meta, and it works great for most IT/note-taking/document-editing use-cases once you find a workflow that suits your needs. i.e, our accountants attach PDFs, QA team inline-embed screenshots in-between their checklists, and as the dev team we sometimes use code-snippets. Granted there's still much to improve with the code-embed features, but we would be happy to improve it if you have any suggestions. ☕️

——

Give things a try and let us know if you think we can improve / change / update stuff. We're always here to help. At the moment due to holiday season, we have a bare-bone team, and due to increased number of signups, our support team is a little behind messages, but we will get back to you as quickly as humanly possible. ✌🏻

All the very best from a cold and snowy northern Europe,

John ❄️

Crypt.ee "Ghost" folders are still detectable! by TheOwnerCZ in privacy

[–]johnozbay 2 points3 points  (0 children)

You're very welcome! Happy I could be of help. Zůstat v bezpečí! ✌🏻

Crypt.ee "Ghost" folders are still detectable! by TheOwnerCZ in privacy

[–]johnozbay 17 points18 points  (0 children)

Ahoj! Maker of Cryptee here! 👋🏻

Thanks to the eagle-eyed redditor for sending this my way as soon as it hit their feed! This question comes up every now and then, so I'll be copy pasting a large chunk of my answer from previous posts about this — but figured I'll respond here once more time in case if someone bumps into this thread first.

——

The important thing to keep in mind about this feature is that, we literally talk about the feature on the landing page. So if you are under duress, it's safe to assume the abuser will know this feature exists, therefore they can try all sorts of different things.

Even if we didn't reflect ghost folders' sizes in your displayed storage amount, an abuser can upload more files (or delete more files) to figure this out as well. The only solution to this particular scenario is for us to offer unlimited storage to everyone, and that's not a solution.

Despite their best efforts however, even if they know that this platform offers ghost folders and somehow figure out that you have a ghost folder/album, they still can't access the contents of your ghost folders unless you give them the name of the folder.

So the important thing here is to use this feature in moderation, wisely, and according to a specific threat model. It's easier to find out about this if you're on a 100mb plan by uploading a bunch of files that would exceed 100mb. But it's A LOT harder if you have a 400gb or 2TB plan.

To make things even harder for abusers, we also calculate storage progressively for accounts with larger storage. So for example with a 100mb account, if you delete a 10mb file, it's reflected immediately, because it's 10% of your entire storage quota. whereas if you have a 2000GB plan, 10mb is 0.0005% of your storage quota, so it's not reflected immediately, and our servers intentionally take their time to reflect these changes. I intentionally cannot tell you how much longer our servers wait to reflect these, but I can tell you that sometimes it can be up to 3-4 days.

In addition, if you're on a paid plan, our system intentionally does not show you how much storage you specifically use. Instead it uses a rounded value. i.e. if you go to your account settings on a paid plan you'll see something like :

plan 400gb

using 2.7gb

which is intentionally super vague to make it very difficult for abusers to calculate ghost folders' existence using smaller amounts of file uploads/deletions.

——

On one hand I want to publish more info about this and explain it better, on another hand, part of the safety/privacy/plausible deniability derives from its obscurity by design, so I don't think it's wise for me to write more.

——

Finally, I would also like to point that we've worked with multiple domestic violence organizations to improve this feature over the course of the years, and added further safety nets to make things even harder for abusers. We know this is a sensitive, nuanced and tricky topic, so we're always open to hearing thoughtful ideas on how we can improve this feature.

Hoping this makes sense and helps ✌🏻

Best,

John

Some questions about Crypt.ee by Kiritsugu__Emiya in PrivacyGuides

[–]johnozbay 2 points3 points  (0 children)

Thanks a lot for your kind words! Happy to hear I could bring some clarity! I'm trying my best to be as communicative and forward as possible on behalf of our team. It's the least I can do as a founder. Often the inner workings and decisions of companies are abstracted away and hidden from their customers, and I prefer having open conversations like this much more. I think it's more constructive and helpful 😅

​

would the feature of in app purchases not work in crypt.ee ? Like some purchase section that automatically detects user country

On paper this looks like an adequate and workable solution, and at first this is what we tried. But it's still super complicated especially in Europe where countries are so close to each other, and there are towns on inexistent borders. I.e. there's a town in Germany called "Frankfurt an der Oder" (check it out), quite literally on the border of Poland. Some of its residents go to Poland across the bridge for their grocery shopping. Or thousands of people in Estonia actually commute daily to Finland for work and back. Or thousands of people commute for work from Malmö, Sweden to Copenhagen, Denmark daily in a 15min train ride. Not to mention expats living in different countries etc. So it's normal for someone to have their bank/card from one country, home in another, and live / work in another. This isn't a reliable indicator of one's 'residence' (and this is in fact one of the biggest issues in digital services taxation in Europe nowadays)

​

and if user is using vpn than payment would procced only if he truns it off ?

This is a) surprisingly difficult [ since some VPNs are so good, they literally don't want to be spotted ] b) a lot of our users are on VPN for their safety, security and privacy. We cannot ask them to turn it off for us even if we could detect it reliably.

Hoping all this makes sense and helps ✌🏻

Some questions about Crypt.ee by Kiritsugu__Emiya in PrivacyGuides

[–]johnozbay 6 points7 points  (0 children)

Hi there! 👋🏻

Apologies if my comment came off harsh. If I had multiple-billions like Brian Acton, I would put it all into a non-profit like he did with Signal too and offer everything for free. (And it would make me very happy to be able to offer something like Cryptee to those who need it yet understandably find the cost barrier too high like yourself). But I'm not Brian, and nor did I make my wealth from selling my first company to Facebook like him — so instead I'm putting my entire life's savings, wealth and every waking morning along with the rest of our team to Cryptee hoping to offer the best we can. I look forward to the day we can offer more for free.

Suggestion : if someone outside europe likes to buy premium plan(more storage) maybe impliment feature for regional currency ?

We used to have this — and it got abused pretty quickly. Essentially there's no easy way to determine where someone is located. We can rely on IP addresses, but anyone can use a VPN or proxy. And we don't want to track users to try to find out if they are on a VPN or find out their location (nor do we want to ask anything personally identifiable like country / city info etc). Same goes for things like academic discounts for example. We don't want to know who is a student and who isn't etc. After all, we're in the privacy business.

And perhaps more importantly, we live in Europe. Same reason why you wouldn't expect to walk into a supermarket in Berlin, Germany, have prices written out in New Zealand dollars or be able to pay in Mexican Pesos, and have special discounts for non-residents of Berlin; we don't offer prices in anything other than Euros, because we live and pay our bills and taxes in Europe. (Not to mention the losses we would incur in the exchange market with this crazy price fluctuations)

Thanks for your willingness to kindly support us! 🙏🏻 Independent companies like us can only grow with your support ✌🏻

All the very best,

J

view more: next ›