Most likely software updates will also bring your remote security features where you can track and hopefully retrieve your stolen devices. And that lockcode prevention is part of that story.

Users beeing able to set a flag which would allow bootloader unlock would be one idea, not making any promises, but putting it in drawing board along with imei based solution.

PS. Oh and forgot to mention that locked bootloader+lockcode combination is also protecting your data, so if someone steals your phone with company secrets then he is not able to access them (but with factory reset & lockcode combination device can be still wiped). Some people like that their secrets remain secret, but yes, some people dont care if their nosy wife or husband can spy them by bypassing the lockcode with bootloader commands.

Not even Apple with its überstrict bootloader disallows a "thief" from reflashing the device.

They'll even do it at the stores, for free, no questions asked. But for DIY guys, booting with "Home" button pressed will skip password, lock code, whatever and enter flashing mode.

EDIT:
Oh well. I can see the point there, though. Still, I think it is beyond doubt that a device should be reflasheable whether it has lock code or not.

Thank you for your answer, those are very valid points. However I think security measures should be optional so the user can decide what's valued more. Regarding data protecting, I'm using dm-crypt on my laptop for exactly the reasons you mentioned (minus nosy && linux-skilled partner ), I feel however not too much reassured by a lock code & locked bootloader. At least jolla care can flash it and access my data, and so probably someone else at some point. Maybe the performance hit is too big atm for encryption on a mobile without hardware aes support, that's for example a thing I'd like to test at some point - but not if I'm risking to brick the device permanently. So a locked bootloader potentially may lower device security for me.

I am unpleasantly surprised by this. With all the "open" claims, I did expect an open bootloader. Now I'm again at the mercy of a company on which OS my device runs.

So, it's up to the pc-side software whether your jolla's data can be read? How would that provide any security?

I would expect full storage encryption for any new OS these days. Linux has support for it for a long time. And I'd rather have something quirky, like Aegis, than nothing.

That would not provide any security, so its not up to the pc-side software. And thats also going off topic from this thread. I'll just stop commenting on security details all together, so people can focus on how they can possible recover from possible bricks and if they will be able to unlock their bootloaders at some point.

Thanks for the information but no need.

If somebody is able to steal my phone, I hope he can wipe it , sell it and some service is able to track it down by IMEI number.

If not -and most likely- at least it doesn't need to be recycled , having my "personal little vengeance" on the thief become a burden on the environment.

Features I do expect.

-Full firmware flashing:
-Thief having to whipe my personal data if I had entered a security code.

I have no further expectations.

If someone gets a physical access to your device - you are already in a serious trouble. It's too late - the device is compromised and no locked bootloader will prevent nasty things. Same goes about desktop computers too. So this is hardly justifiable and always looks more like power grab than any real security reasons. In Jolla's case it's highly surprising. Having an open enough device was expected. Surely if some encryption is used it should be explicitly controlled by the user who sets it up (setting your own keys etc.). Otherwise this is completely not true:

https://sailfishos.org/wiki/QA

Until Jolla opens up the bootloader I halt all my support for this closed platform.

No more updates on SMPC MPD Client and development stop of my MTB bicycle tracking application.

At this point if I support android, I support an more open platform.

Very sad that my device now just lays around and I cannot play with it over chistmas holidays

In mobile world there are only 2 DRM solutions widely adopted and they are: Microsoft PlayReady and Google Widevine. Jolla does not support neither of those currently -> So _NO_, there is no support for neither of the Digital Rights Management frameworks in the device currently.

If you think that DRM-term in mobile devices means something else then you have been eating wrong kind of mushrooms. All media files in device are unprotected and there is no Digital Rights Management frameworks device to protect media companies interest (well there are unix filesystem groups, but with developer mode its does not protect against malicious user). That is the current state of course if some media company makes native client for their media files, they might deploy their own DRM solution for example into TOH.

Okay, so, guys - here's the exact situation, with a large amount of gory technical details so you can understand what's going on too.

* Philosophy wise, we're into user privacy - protecting your private data against attackers, physical or applications - ie, not DRM (other people's rights..). When you've set a lock code, we try to protect your data as well as we can.

A way to see this is that I really wouldn't want my private conversations to be easily extractable because I put my phone into a malicious USB charger or a competitor stole my phone off the table in Amsterdam in Ruoholahti while I was getting a drink.

* The bootloader of the Jolla is 'little kernel' ("lk") which speaks the typical Android fastboot protocol, which has a open source flasher.

* There's three modes of booting:
- Normal booting - boot into 'boot' partition, which is a combined kernel + initrd + cmdline image
- Recovery booting (volume down + power on) - doesn't do anything at the moment as there's nothing in recovery but boots into 'recovery' partition (same format as boot)
- Fastboot mode (volume down + put USB in) - opens a fastboot session on USB that you can connect to with fastboot flasher

There's a few toggles in the device currently:
* Developer mode - which gives you full root on your device and it says, please note this: "this may void your warranty" - it does not say "this will void your warranty". The philosophy there is that if you break something with it, you get to keep both pieces - don't do anything stupid - like overwrite the boot loader, or use hardware parts beyond their specifications.
- It is possible to flash kernel, recovery, etc from within device as we do this in OTA updates. If you really have to hack, do it with recovery partition until the below is in place.

* OEM unlock - which determines if bootloader is open or not - no special code is required to unlock - just fastboot oem unlock, but the power comes with responsibility - and I'm not in any way as an employee recommending this.

Now - one of the things about breaking things is that you can glue things together and it's all good again - About recovery:

At an upcoming update (I cannot say which, because, until a feature is released, it can at any point be pulled and postponed), there will be a recovery partition installed that will 1) ask for your device lock code if you have one and 2) allow you to factory reset your device in case you've hacked it a bit too much ("unbootable brick" situation)

That recovery I'd like to improve in such a way that it enables users to do full system backup/restore from microSD and other useful bits that we've learnt from maemo times is just generally nice to have (BackupMenu, BootMenu, etc).

Now, about factory images.

The Jolla device has all it's system data on a eMMC, one big SD card practically. This is shared with the modem part and includes things like modem firmware and other bits (take a look at the 25+ GPT partitions!). The device factory image is a combination of SailfishOS, a Qualcomm Android hardware adaptation and modem bits. The hardware adaptation and modem bits are copyrighted by Qualcomm and are put in place by the factory partner - and Jolla cannot distribute those parts.

Due to a bit of a design flaw on my behalf that I hope to solve for future devices, our entire system is merged together in one big 'sailfish' BTRFS volume which makes it even harder to separate bad bits and 'good bits' and 'flash them seperately'

In practice, what this means, is that we cannot provide full factory images. And that sucks. But if we do a proper recovery, backup and restore possibilities, it takes care of a lot of the trouble.

I don't personally buy devices that can't be hacked. We started developing Sailfish on hackable devices - we know our roots. And I have one coming to me at full price - no rebates or special treatment.

Does this clear up the situation a bit? Device is open as is explained above, but, when you hack, you'll always want to be able to restore your device. And that's what I hope the recovery will sort out unless you really screw up the device. In which case it's your own fault.