Encryption stuff in need of solutions

[Fania Bremmer]

Am 20.01.2012 10:35, schrieb ivan.cukic at gmail.com:
> @fania
> The password input can not be the part of activity switcher. Technical security issue. We need a separate window.
Well, in which window this dialog is technically, is not relevant for 
the UI Design, no?
Could be a separate window, that lies on top of the activity switcher, 
not fullscreen, so the user can tap into the background and close with 
this interaction the window.



>
> AS for the always present introduction activity, it is a bad solution that I thought we dismissed infavour of showing the activity manager
What do you mean by "activity manager"? What screen would that be?


> , or the previous activity.
>
> Cheerio,
> IvanOn 20.1.12. 10.23 Fania Bremmer wrote:
>
>>> This means that plasma-* will need a little bit more logic not to
>>> listen only for which is the current activity, but also to listen for
>>> the state of the current activity. If the state is not 'Started' then
>>> it should not show the current activity. Though I have no idea what to
>>> show (showing previous activity is not a complete solution - the user
>>> might want to boot into a private activity - and there is no previous
>>> one then.
>> Well, best effort: if it is a private activity show a dialog with Ok
>> and dismiss buttons. If the password is wrong, ask again and again
>> until it is right or the user clicks on dismiss. The dismiss operation
>> tries to find a non-private activity, if none is found then present a
>> new dialog with "Create new activity" and shutdown buttons :-)
>>
> Mhh, maybe I didnt understand the problem fully, but I guess we dont
> need dismiss buttons.
> The user works in a non-private activity. He opens the switcher and taps
> a private activity. The pw-dialog appears, as described in my concept.
> - The user enter the right pw ->activity launches.
> - The user enters the wrong pw ->  the error message appears; the user
> can try to enter again pw's...
> - If the user doesnt want to enter the pw, he just taps another
> activity, that launches then
> - If the user doesnt do anything for a longer time, the switcher slides
> out anyway and the open pw dialog closes
>
> Of course this requires at least one non-private activity. But we
> discussed that already, that we might put the introduction activity as
> non-deletable and non-private.
>
>
>>> If the user doesn't know the password, it should be possible to go to
>>> a public activity. But that raises more problems - if kamd asks for
>>> the password, would it mean that kamd should have ui for the activity
>>> switcher as well... security is a messy thing.
> I was recently thinking about the user forgetting the right pw - that
> would litterally block that activity locked forever. But ok, thats maybe
> bad luck then :)
>
>
> _______________________________________________
> Active mailing list
> Active at kde.org
> https://mail.kde.org/mailman/listinfo/active
>