Ability to prevent encryption to become enabled

Feature Requests
41

I fully agree with @explit, an option to disable encryption would increase SFOS complexities much more. From my point of view the need for security & privacy by default for mobile devices is no discussion at all.

So I still have not read strong technical reasons in this Feature Request, i.e. reasons not based on personal experiences. And if you would like to modify your own SFOS image why not try the script by @teleshoes?

1 Like
42

Forcing users to enter a passphrase many will have issues with remembering, is a recipe for disaster (i.e. a huge number of frustrated users and support-requests).

Thus IMO that is a no-go.

Forcing security upon users is always a bad idea, especially if for some of them the drawbacks outweigh the benefits: They will eagerly search for workarounds to bypass this security, see this thread for an example.

Backup the partition by adb tool to a PC: Its data is encrypted, the LUKS-headers are not.

  • Do give the users choice!
  • Do not patronise (i.e. disempower) users by forcing a kind of security upon them, which someone else deems adequate!
    Any such decision forced upon people will be inadequate for some.
  • That is bullshit: It is exactly the scheme Jolla has been supporting right from the start and still supports on devices with an initially unencrypted home-volume (Jolla C, Jolla Tablet, Sony Xperias initially flashed with SailfishOS < 3.3.0).
    Note that this discussion thread is only about the ability to not employ home-volume encryption during the initial startup (“startup-wizard”), it is not about reverting this procedure without re-running the startup-wizard (i.e. a “factory reset”).
3 Likes
43

Exactly. And adding an option increases the testing complexities a lot.

44

Yes I’m aware. My main motivation for using SFOS is to have a beautiful OS, that I can modify, tinker, SSH into, is a Linux, not to be part of the GAFAM ecosystem, not to have a contract with G++gol, not to have all these fu++ing apps that phone home permanently, is advertising free, is not an attack surface for main stream viruses… When being pressed to install this or that app for the electricity/cellphone/whatever provider, I tell them “sorry, not possible on my phone for technical reasons, it will not work. YOU have to make it work here and now or you lose a customer”. Last but not least this forum, and it’s a very interesting hobby. Since the Browser problem is solved 3 days ago, I’m happy!

4 Likes
45

Incredible how people seem intent on pinning this on BIG BAD JOLLA, when it’s the exact same shit as on Android and iOS (and Windows and Mac and …). Someone who wants to break into your house will always be able to get in, but that doesn’t make a simple lock useless.

More than half of the devices on that list (C, Tablet and Xperia X) are no longer supported as of 4.6, and honestly haven’t received any real updates with fixes specifically for those models in years. XA2 and Xperia 10 no longer receive any real updates either and will be dropped in two years when Sailfish 6 is ready.

2 Likes
46

This is nonsense, all supported devices receive the exactly same SailfishOS updates; WRT home-volume encryption specifically as well as the rest of the OS, only the hardware-adaptation layer differs between devices.

Nevertheless, the whole story about “much higher testing efforts” cannot be taken seriously, because not encrypting simply means not to use a whole lot of code (LUKS, in the Startup Wizard etc.), hence there is nothing to test, except for implementing the dialogue to omit home-volume encryption and test it once. Using home-volume encryption or not is surely expected to make no difference, because it is transparent to the rest of the whole system (OS, apps etc.); if something may have ill side effects it is code which employs the encryption (LUKS, in the Startup Wizard etc.), not not using this extra code.
By the way, I never had the impression that Jolla focuses much on testing lately (> 5 years), anyway.

P.S.: The information that SailfishOS 6 will be ready in two years is quite remarkable, just as stating that Jolla will drop support for the Xperia XA2 and Xperia 10 models with this release. Can you name a source for these statements?

1 Like
47

I never had problems with the encryption in more than 5 yrs using SFOS. It’s ‘transparent’ and the UI/userspace ‘sees’ the home partition as a normal drive. I absolutely can’t understand what happened with this C2 fiasco. Did Jollaboys really test nothing practically? Didn’t they take 10 devices out of 1000 and tried to ‘real live’ setup them? If Jolla would have done so, they would have had the BUG (statistically) on 4-5 devices and could spare out the current mess.

48
  • nah, im not laying blame on anyone. i am a jolla fanboy and i love+support what they do, especially with their limited resources.
  • i AM, however, making the case that the encryption happens to be useless, and maybe worse than useless since it makes users erroneously feel safe. in my opinion, they should make it opt-in and have a big caveat on it.
  • for whatever reason (maybe it’s because most android devices aren’t rooted or don’t allow bootloader images or whatever, i do not know), it does NOT seem to be the case that android device encryption can be easily broken. im sure some can, but i could not find a step-by-step tutorial to decrypt any of the devices i checked. (again, i could be wrong here, but at least a quick google didn’t turn it up)
  • apparently, many android devices DO offer optional long password encryption like what i am proposing. it might be worth considering for security enthusiasts.
  • so, in your analogy with the house, i would say the pin code is more like the simple lock on the door. the encryption is like another lock attached directly to that lock. if someone is going to bother entering recovery mode and mounting your partitions, they might as well flash the image to bypass the encryption.
  • => i think the casual attacker won’t see a difference between pin alone and pin+encryption, and neither will the dedicated attacker. MAYBE some theoretical script kiddie exists in between the two that will be willing to do recovery mode attacks, but not encryption attacks, but that’s hardly the convincing argument i think it would need to be to make the encryption non-useless
1 Like
49

lol, not to sound snarky, but…QA is very easy when you’re not the one doing it…and you already know the issue you’re trying to find! :slight_smile:
i mean, i understand where you’re coming from, but it’s hard to overstate how difficult (and expensive) qa+testing can be, especially to someone who doesn’t work in the industry. i doubt that jollyboys-formerly-known-as-jolla has the amount of dedicated tester man-hours that even they think is sufficient.

edit: i’m also not saying that your criticism is invalid, just that underestimating the challenges of qa, and the hindsight bias, may be coloring your position a little

5 Likes
50

Agreed and the issue/bug itself is also a bit special:

A corner-case, rather rare use case was buggy: the First Boot, that is executed exactly once during the lifetime of the device.
Whatever testing you do, it’s usually on a set-up, running phone going through all the commonly used functions.

It just happened now that a relatively large number of users were “forced” to execute that rarely-used function, so a large number were bitten by the bug (not all of them either!).

Of course the situation was escalated by the fact there was/is no way to recover “in the field”.

Imagine the same situation, but with the possibility to reset to factory state. People would have just tried again, succeeded and no-one would have given it a second thought.

1 Like
51

About androids, it’s worse than iOS:
https://cybersecuritynews.com/phones-cellebrite-tool-can-unlock/

Cellebrite could not brute-force the Google Pixel 6, 7, and 8 series when the devices were powered off.

So the titan chip doesn’t stop them when powered on? Sounds like a bypass of shorter pin after first unlock. So looks like google can’t get it right like apple (both with their custom hw (secure enclave/titan) and sw)

3 Likes
52

I’m curious now, what do you think where I’m coming from?

Yes, only needed one time at first time, but what happened was like the Challenger catastrophe. The boosters were also needed only one time at start but did explode.

1 Like
53

sorry, what i meant by “i know where you’re coming from” was: “your frustration seems reasonable to me”.
there was a big problem that seems like it would have been easily caught if jolla had done even the tiniest amount of QA. i am not saying one way or another whether this is true, i just want to point out that the exact testing steps that would have caught a terrible bug are always obvious in retrospect in any project, and the hindsight bias makes it seem like the dev team was bizarrely negligent and could not have reasonably missed the issue. occasionally, this is even true.

1 Like
54

OT: Yes I was frustrated, watching this tragedy, but not personally affected. So I’m back again, but in future or next time will do less adventures with updates but more enjoy what I could reach until now and a little hold back ambition.

1 Like
55

Yes, and how many hardware adaptation bugs on XA2 and Xperia 10 have been fixed since, let’s say, 2020? That was all I was getting at.

Feel free to bookmark the post to check back when the last update released as ‘Sailfish 5’ is out: XA2 and Xperia 10 will be dropped. They run on old, outdated kernels and Sony no longer updates those. Xperia 10 II and 10 III run on the same, slightly newer kernel, so they will also be dropped simultaneously, but in ‘Sailfish 7’. Also quoting myself from two years ago:

56

Leaving out crucial parts of statements to let your counter-arguments appear to be sound is insincere.
Side note: Mind that this is never a proper way to “win” an argument; even if that works, this scheme cannot make a wrong statement right.
May I also remind you that this discussion thread is about the “Ability to prevent encryption to become enabled”, not flaws of the hardware adaptation layers for specific devices.

Thus it proves (on a psychological level, while I was originally arguing on a technical level) this nonsense to be nonsensical.

For your statement, “XA2 and Xperia 10 no longer receive any real updates either and will be dropped in two years when Sailfish 6 is ready.”, I now understand that you lack technical reasons or specific information.

So I see, that you see yourself as a seer: Well, I cannot and do not want to argue about this kind of insight.

57

​​​​​​​​​​​​​​​​​​​​

58

I also want to be able to keep my data decrypted on disk, i.e. opt out of LUKS disk encryption.

After reading this thread I want to set some straight facts :

  1. The default should be encrypted, as it is
  2. But the installer must make available the option to not encrypt available since it’s not there currently
  3. Out of all my phones, I’ve lost data on ALL of them because ultimately, the encryption worked against me. Most of them are Android so the encryption scheme is different but the point stands. Be it because the memory became corrupted and it decided my screen lock wasn’t my screen lock anymore, or an over the air update failed, or because a hardware component failed and thus the key couldn’t be reconstructed anymore or just plain because it wouldn’t boot and thus data recovery can’t happen. It makes phones very fragile data storage.
  4. If you don’t care about losing your data then it doesn’t matter if it’s encrypted, I care enough about my data to know that I’ve lost more to corruption then to hypothetical security issues or theft.
  5. At the very least I want to be able to store the encryption key and a backup of the headers for data recovery purposes in a safe place.
  6. security bugs in hardware or software are irrelevant for this discussion, they will get fixed eventually.
  7. Guesstimating how much work something is, isn’t an argument.
  8. At rest encryption has nothing to do with being hacked to expose your activist friends.
  9. This is literally the reason I liked my previous sailfish phone, I could recover it with my laptop. For me it is a killer option to drop Android who holds your data hostage at all costs. I don’t want sailfish to go the same route to tie everything to disk encryption and give drm more rights than the device owner over the data of the device owner. Having the option to disable it guarantees this.
4 Likes