~anjan/public-inbox

peanutbutter feedback

Details
Message ID
<D08OUBZEXWSQ.3M648R47PDJC1@matfyz.cz>
DKIM signature
missing
Download raw message
Hello, Anjandev,

I have come across peanutbutter (the swmo screenlock) yesterday and I
was very pleased to see that there are ongoing efforts in this area --
thank you for working on this!

I have since then been using it on my samsung,coreprimevelte phone and
have several questions and suggestions if you don't mind. Please forgive
if I missed some important document -- actually I only found the README,
I haven't looked at the code itself -- where some of these concerns
would be addressed.

A probably obvious question is whether you intend to support changing
the touchcode without recompilation. I understand that for early
development the current mechanism is sufficient, but obviously it would
not make much sense security-wise if everyone who installs this from the
Alpine repo had the same passcode.

An automatic idea would be to have a configuration file for that, but I
don't know if that could be considered secure either if it was plain
text. Perhaps it could at least contain some sort of a hash of the code.

Possibly the best way would be if the program used some built-in Linux
authentication mechanisms -- I don't really know much about this, but
could maybe PAM be helpful here somehow?

I have found the current touchcode to be rather weak -- touching the
screen semi-randomly, I was able to unlock the phone (which however
might be rather because of another issue, please see below). I don't
know if the lower right is always reset and whether the touchcode must
be always 4 taps long (my simple experiment seems to suggest that
entering wrong 4 taps code and then the correct one does unlock the
screen), but if so, it doesn't give many combinations and would be easy
to brute force.

So if the code is eventually configurable, perhaps it should not be
limited in length. Another thing I can think of would be to add more
segments instead of the four corner, but that might be problematic for
small screens and even on big ones, it might be hard to tell where are
the segment borders without some visual aids -- perhaps the number of
segments could be configurable too.

Speaking of visual aids, do you plan to implement some visual feedback
for the user? Such as maybe display the segment borders (configurably),
indicate which segment was pressed, indicate wrong combination and so
on. There is some security-by-obscurity now without the feedback, but I
don't think that's a strong argument against adding some in the future.

This is something very marginal and currently unimportant but while I
like the default lock background (I don't see any images in your repo:
is it generated as a color gradient or is it the GNOME Mobile
background?), I would probably eventually like to have the option to
experiment with different ones.

It would probably make sense to somehow inhibit sxmo's buttons daemon:
currently, when the screen is locked, it is still possible to change
sound volume (which is a good thing) but also open the system menu
(using Volume Up), which is probably harmless since Power Button doesn't
seem to work through the lock, and kill windows (triple Button Down)
which could already be problematic.

I assume this is because sxmo listens to the input devices directly
(bypassing sway) using some daemon and runs the appropriate actions? If
that is the case, the daemon could either be completely suspended when
the lock is active, which would mean that peanutbutter would have to
somehow handle at least the Power Button presses and optimally even the
volume control (or it could let the user configure the Volume Buttons'
functions with active screenlock) which would probably mean more code.
Or (probably better), the daemon could be modified to recognize the
"lock active" state and behave accordingly.

Last thing that I noticed and which seems like a bug to me, unless I'm
missing something: it is actually possible to unlock the phone using a
different than the default combination. As I wrote above, randomly
tapping the screen lead to the screen unlocking for me. I originally
thought that is simply because I entered the correct combination by
accident, but then noticed that the screen unlocks when I press
different than the upper right corner. I have been able to determine
that for instance (I am not sure there are not others) starting at upper
left segment, going down, upper right and repeat four times ending on
the upper left (simply start at upper left and keep going
counter-clockwise) unlocks the screen. I believe this would definitely
be worth investigating.

May I ask what your plan is going forward for Xorg integration? I
understand that currently the lock is swmo-only. That doesn't matter
much to me as I use that flavour, but I wonder if it might be needed for
full integration with the sxmo project in the future. Of course, I
suppose sxmo could offer the lock for swmo only.

If you actually found some of these comments useful, I would be happy to
also put it up on the project's ticket tracker, should you create one.
Perhaps a dedicated mailing list might become appropriate soon too?

Thank you once again for starting this project, I really hope this will
catch on and sxmo will finally have an official screenlock.

Also thank you for reading this.

Kind regards,
K. B.
Reply to thread Export thread (mbox)