Ability to prevent encryption to become enabled

[jrg]

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?

[olf]

@teleshoes

my proposal is literally just:

1. prompt for a 13+ char password at installation, and use that for encryption at boot

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.

@avhakola

I know it is somewhat easy to get the PIN from the LUKS headers, but how do you get the headers from locked/powered off device without any knowledge of the PIN or developer password?

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.

• @jrg

  An option to disable encryption would increase SFOS complexities much more.

  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”).

[jrg]

@olf

Note that this discussion thread is only about the ability to not employ home-volume encryption during the initial startup (“startup-wizard”),

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