search

cryptee / web-client

Cryptee's web client source code for all platforms.
https://crypt.ee
Other
445 stars 22 forks source link

[Bug] Get stuck on a loading screen in iOS 12 #173

Closed eugenesvk closed 1 year ago

eugenesvk commented 1 year ago

Describe the bug I can't open a note on a phone, get stuck on a loading screen

To Reproduce Steps to reproduce the behavior:

  1. (desktop PC) Save a note, e.g. fdTest_inFile.md
  2. (iPhone) Log into Cryptee by opening the installed main screen icon
  3. (iPhone) Try to open the same note fdTest_inFile.md
  4. (iPhone) Get stuck on a loading screen forever (ar at least for 10+ minutes while trying to keep the phone awake)

Expected behavior After a short delay allowing for downloading/decryption the note should open

Screenshots Example of a loading screen

System Information (please complete the following information):

Additional context While trying to troubleshoot and after disabling all the content blockers/VPNs and trying to open Cryptee directly in Safari (not via the main screen app), once I got a red screen error while trying to open a document, mentioning that this might be a connection error and something about localstorage (touched another screen area and the error disappeared, so couldn't screenshot it), but then trying to open another note would again just stuck me in the loading screen without any errors

Also, sometimes I wouldn't even get past the login screen, after entering the encryption key, I'd get stuck in the loading login screen (though this only happened with the main screen app, don't think I've had this while opening the page in Safari, that one always logged in and only got stuck trying to open a document)

johnozbay commented 1 year ago

Hi there!

We've recently updated Cryptee (f487c37cd4bb7d2df62f490d6cd0f24ff1286cf4) and it should hopefully address some of these initial loading issues and improve performance. And may fix some of your issues.

That being said, I think the reason why you're experiencing these issues have to do with iOS 12.5.6. We can only support browsers that are at max 4 - 5 years old, and unfortunately iOS 12 and all the browsers (Safari, Chrome etc everything) on iOS 12 use WebKit (which is from 2018).

Back in 2018, some of the features we need for Cryptee to run as well as it does today didn't exist, and back when we launched in 2017-2018, we had fallback technologies for these, which made the experience slower and more cumbersome for everyone moving forward, so last year, at the 4th year mark, we dropped some of these fallbacks. Which means that although Cryptee will continue to work, due to the fact that your device can't make use of these new performance features that are available in newer browsers, depending on how much free memory your device has available, parts of Cryptee or some documents may not load / open or downright not work.

Using a 5 year old browser also means you're not getting any critical security updates. So for your own security, I would strongly recommend updating your phone to a newer operating system or if it reached its end of life for software updates, I would strongly recommend getting a newer phone so you can benefit from all the security updates.

If this week's performance updates don't fix your issues, I'm afraid it's likely due to the outdated browser engine webkit on your device, and we won't be able to help you any further.

Hoping this makes sense and helps!

Best,

John

eugenesvk commented 1 year ago

we had fallback technologies for these, which made the experience slower and more cumbersome for everyone moving forward

That's a weird fallback if instead of falling back when the main path fails it slows the main path. But otherwise it makes sense if you removed the optimizations, then it became slow.

Using a 5 year old browser also means you're not getting any critical security updates

Well, not just yet :) — a critical security update juts got out a week ago

johnozbay commented 1 year ago

That's a weird fallback if instead of falling back when the main path fails it slows the main path.

The browser engine is so old it literally doesn't support stream reading/writing, (https://caniuse.com/mdn-api_writablestream) and started supporting this only in iOS 14.

Before iOS 14, if you had a 50mb file, you had to read the entire file as a string into your device's memory, then encrypt the whole thing from memory (+50mb) resulting in a 100mb memory use. (and same but in reverse for decrypt while downloading) Because you physically couldn't read/write/manipulate/work with streams = thus had to encrypt/decrypt files as a whole.

After iOS 14, WebKit finally started supporting writablestreams, which allowed us to read/write/encrypt/decrypt in streams, removing the requirement for us to read/write files in strings for the purposes of encryption. BUT. there's more.

While you're correct that fallbacks should be easy to build in non-encrypted environments, fallbacks are extremely difficult to implement, due to the fact that once a file is encrypted, our servers cannot update / upgrade the file (and how it is encrypted).

So if your file is encrypted and saved as a whole, it is served as a whole. if it is encrypted and saved as a stream, it is served as a stream.

The literal encryption method (and thus the type of files we store had to change) — what this means is that, if your phone was stuck in iOS 12, and can't use streaming decryption, it meant that your desktop cannot use streaming encryption either (even if your browser i.e. chrome may support it) since if you stream-encrypted something on your desktop, your phone would still need to be able to stream-decrypt it. And if your phone can't decrypt in a stream = boom, you cannot open that file.

And this meant that we had to wait patiently for all devices, operating systems and browsers to mature, support streaming encryption and age for a year or two, and let everyone slowly migrate and update their devices before we could update our platform to use more performant technologies.

johnozbay commented 1 year ago

also — For a long time we kept the non-streaming fallback for encryption decryption, however that required our servers to always serve files as wholes (rather than in streams = effecting performance for everyone) and same for uploads, required our servers to always accept files as a whole [vs in streams]) and while we kept and maintained two separate API endpoints for these, the problems I listed above are the reason why the performance wasn't good, and there's no way to fallback unless you encrypted the same file twice using different methods.

johnozbay commented 1 year ago

Well, not just yet :) — a critical security update juts got out a week ago

^ This is a misinformed and factually incorrect opinion, and a part of apple's security theater I'm afraid. Your operating system got a security update. Not your browser engine. Your browser engine has been stuck in version : 607.1.40 ( which is at least 4 years old ) While apple did fix one safari related vulnerability that affected the operating system, without updating the entire browser engine they cannot fix 4 years worth of hundreds of other vulnerabilities and issues with Safari itself.

I would strongly recommend updating your device to a newer one for better security.