Would it be possible to password protect KOReader?

[smartscripts-nl]

I like the feature in Nickel that it is possible to password protect the program. Upon starting it and when it wakes from a beauty sleep 😁.

Could the same feature also be implemented for KOReader?

[poire-z]

When I saw that feature on Nickel, it had me worried:

• I don't want to use it
• anybody finding my device could set up some pin code, and prevent me from using it
• so, I'd have to set one, and be doomed to use it
• but I don't want to :)

Another reason to stay with my 3.19 kobo FW that doesn't have it :)

[Frenzie]

KOReader starts in seconds. You could consider closing it before suspending if you want to use this functionality. I'm not interested either. ^_^

[pazos]

https://www.mobileread.com/forums/showthread.php?t=315744

[smartscripts-nl]

I tried to implement this in a plugin myself, but the problem I encountered was that the dialog for entering the password was party overflowing the screen, so I couldn't reach the OK button. I suspect this was caused by the fact that a document was not yet visible on the screen c.q. loaded. Can it be that the Dialogs module needs a document to be present to compute the coordinates of a dialog?

[Frenzie]

To create GUI stuff you can use the wbuilder. (kodev wbuilder) Put your dialog in a UIManager:show() call.

Widgets always use a container that gives them a width and a height, typically related to Screen:getWidth() and Screen:getHeigth(). If they're overflowing it means you made or allowed them to be too wide, or that it was simply positioned off screen.

[smartscripts-nl]

Below I've added my code, with the problem. Even with the dialog set to fullscreen, the right en lower parts of it still are hidden from view.

Also, the dialog is only shown at the moment at which an ebook is already being shown. Would it be possible to show the dialog in an earlier stage, before the ebook becomes visible?

    pwdialog = InputDialog:new{
        title = "Password",
        input = "",
        input_hint = "Type the password",
        input_type = "string",
        description = "Password required",
        --text_type = "password",

        fullscreen = true,
        condensed = false,
        allow_newline = false,
        cursor_at_end = false,
        add_nav_bar = false,
        scroll_by_pan = false,

        buttons = {
            {
                {
                    text = 'Cancel',
                    callback = function()
                        UIManager:close(pwdialog)
                    end,
                },
                {
                    text = "OK",
                    -- button with is_enter_default set to true will be
                    -- triggered after user press the enter key from keyboard
                    is_enter_default = true,
                    callback = function()

                        local password_typed = pwdialog:getInputText()

                        UIManager:close(pwdialog)

                        if password_typed ~= password_required then
                            os.exit()
                        end

                        --print('Got user input as raw text:', pwdialog:getInputText())
                        --print('Got user input as value:', pwdialog:getInputValue())
                    end,
                },
            }
        },
    }

    UIManager:show(pwdialog)
    pwdialog:onShowKeyboard()

[pazos]

I think this is a bad idea. It gives the user the impression that the program is protected against unauthorized access, which is, and will always be, false.

Normally login screens are handled by the OS on which the program runs. On embedded devices one could implement a different binary that handles the login, but that's outside the realm of this app.

[melyux]

Some security's better than none. Kindle is stuck between a rock and a hard place, since a passcode is apparently "outside the realm" of the app, but the app prevents the Kindle's native passcode from working.

[Frenzie]

Coming at it from another angle, one could consider remapping the off/standby button to exiting the program to avoid accidentally entering standby without a passcode?

[melyux]

Please reconsider adding a passcode. A simple passcode when waking is miles ahead of nothing at all. Exiting Koreader every time is clumsy

[wokawoka]

Please reconsider adding a passcode. A simple passcode when waking is miles ahead of nothing at all. Exiting Koreader every time is clumsy I agree 100%. I guess that android e-readers have an advantage from this point of view and the lockscreen should get triggered despite koreader running (but I much prefer a very slim and optimized OS focused just on reading)

[KawaiiZapic]

Since we break the original passcode function on Kindle, shouldn't we to make it as a optional function?
One of the missing of passcode or the breaking of original passcode function, should be threat as an issue.

Last week, I left my device on classroom unexpected, and after I find it back, some new reading history were appeared. This make me feel really bad.
It can be prevented if there's a passcode to deny the unauthorized access to my device, whatever the passcode function is strong enough or not. If there's a passcode, it will telling anybody who want to access to my device without my permitting, I DO NOT WANT TO KNOW WHAT I AM READING, YOU BETTER NOT TO TOUCH MY DEVICE, that's enough.
It's hard to make a high security level passcode function, but actually we don't need that to be too strong. Just like the lock in your garden gate, I just want to tell you I don't want you enter my garden, but it can't prevented you from jumping over the wall. In fact, with the lock, the most of people will not try to enter your garden.

I REALLY NEED A PASSCODE, A PASSCODE AUTOMATICALLY LOCK UP WHEN I LEAVE.

[NiLuJe]

https://github.com/koreader/koreader/issues/5970#issuecomment-599770966 still stands.

While you could somewhat trivially implement a lock screen as a ScreenSaver mode, it could be trivially bypassed any number of ways (from simply restarting the device to accessing it over SSH/USB/serial).

TL;DR: If you're not comfortable reading smut, don't leave your device lying around ;o)?

[melyux]

https://github.com/koreader/koreader/issues/5970#issuecomment-599770966 still stands.

While you could somewhat trivially implement a lock screen as a ScreenSaver mode, it could be trivially bypassed any number of ways (from simply restarting the device to accessing it over SSH/USB/serial).

TL;DR: If you're not comfortable reading smut, don't leave your device lying around ;o)?

Just call it "child lock" but just have something, anything. No expectation of fully hardened, government-proof encryption. Just something, anything. A Halloween costume. I doubt Kindle and Kobo passcodes are much more effective anyway, but at least they tried with something, and KOReader disables that so should provide something to cover that hole. :)

[melyux]

Further point: Even if Kindle and Kobo were to come up with a fully encrypted device, KOReader would still negate that encryption by providing anyone with screen access to the device. All KOReader should do is prevent unauthorized access to the screen, which is very simple with a passcode. That's it. Let the underlying device take care of encryption for now. We don't have to solve for the whole encryption stack. The only concern for KOReader is screen access, which it monopolizes from the underlying OS.

(P.S. Restarting the device, as you said, would default to the OS passcode, so it's not really a hole in the security)

[KawaiiZapic]

#5970 (comment) still stands.

While you could somewhat trivially implement a lock screen as a ScreenSaver mode, it could be trivially bypassed any number of ways (from simply restarting the device to accessing it over SSH/USB/serial).

TL;DR: If you're not comfortable reading smut, don't leave your device lying around ;o)?

Bypassing is never a problem, problem is the missing of passcode. No one can be sure that the passcode is always safe.
And in this case, I think we don't need a safe passcode, we just need a more sounded way than write "DO NOT TOUCH MY DEVICE" on screensaver.
Bypassing is always possible, but most of people don't know how to use serial, most of people will not try to enter a locked door, even a paper door.
Anyone could make mistakes. We can't stop mistakes from happening. Isn't the jailbreak of Kindle is a mistakes?

[roygbyte]

Fascinating conversation. On one hand the "broken window theory." On the other hand, a sign that says "no trespassing". Both beg the questions: is the appearance of security/inaccessibility enough to thwart "strangers" from snooping into our literary lives; is a door left unlocked or a window open enough of an invitation to make a stranger feel at home?

My own suggestion towards a semblance of privacy would be to veer towards obfuscation. Hide yourself in plain sight, but make it very hard to understand. Change the UI's language to piglatin. Make the text really small. Display "low battery: changer now". All suggestions about dressing up, wearing a Hallowe'en costume to hide who you really are. Better than nothing, and at least something for those who want to stand out by fitting in.

If @smartscripts-nl has something that's mostly working, then this solution should be halfway towards being done? I don't have a horse in this race, but I am curious to watch the racers turn around the bend.

[poire-z]

Could be a real simple plugin:

• that registers an action "Unlock" to Dispatcher, that people can assign to a gesture (so, they can choose what to draw to unlock)
• that reacts to onSuspend and show a fullscreen widget (top/modal widget that would catch any other gesture) showing a blank page and a message (or just letting the screensaver, but I don't know if it could intercept the screensaver disappearing on Resume)
• and so would prevent any other action until the Unlock gesture is triggered.

Unless all this can just be integrated in the existing screensaver - because it has already a: Keep screensaver on screen after warkup > [ ] Until a tap so it could just have another Keep screensaver on screen after warkup > [ ] Until unlock gesture

[NiLuJe]

Yeah, I'd probably try to integrate it into Screensaver directly ;).

[mergen3107]

Isn't it possible to kill KOReader process when connecting via USB? Then even if KOReader has password protect, it is still not safe :D

[NiLuJe]

It's absolutely never going to be a question of security, as that's never going to be a guarantee ;).

[roygbyte]

Wow. This issue is HOT :hot_pepper: :fire: Whoever squashes this bounty (metaphorically speaking, I don't think there actually is a bounty) will surely receive a shower of accolades :1st_place_medal:

Really seems like the way to go is to make it password protected in appearance only. Messing around with processes, whatever, definitely would inspire the wrong assumptions about the security (there is none, doubtfully can be any) of the device. But I'm just repeating what's already been said.

[melyux]

I like the secret gesture or the passcode ideas. Not the dummy passcode thing (you could just do that by pasting a fake keypad image onto your wallpaper image), that's too close to nothing. But we're not concerned with device security anyway, just screen security.

[Frenzie]

Incidentally, the (not so secret) gesture concept has been proposed in a different context, namely to switch ignoring touches on and off so that only the page turn buttons would be used (on devices where that's applicable).

Just something to potentially keep in mind if one wanted to work on something like this.

[poire-z]

Keep screensaver on screen after warkup > [ ] Until unlock gesture

I had a try with this. It was quite complicated to get working (because all the gestures from gesture manager are set on the ReaderUI widget, and won't trigger on the ScreenSaverWidget at top, so I need to steal/duplicate them :) Would have been a lot easier to just use a InputWidget and wait for a password to input from the keyboard - but I think it would not be really practical, and a gesture to draw on the screensaver image is way more practical for the user/owner of the device.

So, I would add these strings: Keep screensaver on screen after warkup > [ ] Until 'Exit screensaver' gesture For a dispatcher/gesture action: exit_screensaver = {category="none", event="ExitScreensaver", title=_("Exit screensaver"), device=true}, Waiting for specific gesture to leave screensaver InfoMessage drawn over the screensaver/cover.

(I have no idea if the autosuspend would trigger when in this state of waiting for the gesture, and if KOReader would suspend if no action for some time. I consider this out of scope :)

I think we should not mention anything sounding like "protect" or "security", and let the user decide if this "feature" is good enough for him for securing his device. Would that be ok ? Any wording suggestion for the above strings ? "Exit or Leave" screensaver ? "Waiting for specific/owner gesture..." ?

[NiLuJe]

A name based on something like "screen lock" would perhaps make the feature more discoverable/obvious ;).

[poire-z]

Btw, it would work only on device where we manage the screensaver, which I guess is only on suspend, so only on devices that we can suspend. Also, in case the user has forgotten his gesture, can he still poweroff on all such devices ? Haven't tried yet on my Kobo, but I guess/expect that long-press on the power button would still work and can get me out of that screensaver.

[roygbyte]

How about "show me the secret handshake"? 😛

[melyux]

@Frenzie I actually thought of that "multi-gesture to enable/disable gestures" idea independently (I swear). Was there work done on it somewhere, or a discussion, or is it still floating like a ghost right now?

[poire-z]

that "multi-gesture to enable/disable gestures" idea independently (I swear). Was there work done on it somewhere

It has been implemented recently, in #9738.

[fritzrehde]

What is the status of this issue? Is some simple password-screen inside Koreader being implemented? If not, how could I use the password protection of my Kobo together with Koreader?

[mergen3107]

As far as I remember, the passcode lock was not implemented, but there was a new optional gesture you need to do to unlock the screensaver. Don't remember the exact issue number though.

Maybe it is in the user guide?

[fritzrehde]

Cool, thanks @mergen3107! To be honest, I really like the gesture system, and thinks it provides enough "security" (though of course very, very weak and easily broken) for me personally, given I can make the custom gesture as complex as I want to. The gesture is also much nicer to type in, and lets me unlock the device much more quickly than entering a passcode. Great work!

[KawaiiZapic]

Thanks for your suggestion, it's a pretty good alternative way to impl "lock screen" and make this look like the 3x3 dot pattern lock in Android. It's good enough to be a "paper door", but it responds so slowly in kpw 3 that makes me even don't know if the system recognizes my gesture.