Happens on 2012-04-23-16-57-basyskom-plasma-active-testing-meego-usb-live Reproducible: Always Steps to Reproduce: 1. create a private activity 2. lock the screen 3.unlock the screen by touching shortly 4. see the pw dialog for unlocking private activities beeing half transparent Actual Results: every user can see through the dialog all the content of the private activity Expected Results: nobody should see any data/information of a private activity, while it is locked -> the dialog should be either fully opaque or we show a dummy background image for locked activities, so that the different boxes and resources are not visible
There was some talk about the transparency of the dialogue in question. The initial version was opaque, but the transparency was added later. I don't like the idea of having two different dialogue modes for activity unlocking when (1) activity is being switched to and (2) when the activity needs unlocking after a screen lock.
I understand that from a consistency point of view its better to have similar dialogs. From a security point of view, a transparent layer thats still shows all the resources added to a private activity, is still not the best option. So maybe to keep the same dialog, we could stick to the transparent dialog, but use another layer image inbetween (for example the grey default one) to cover the boxes of the activity screen.
I was leaning more to make it opaque in all cases option :D Ok, will see what to do to make it as desired - transparent when switching, opaque when unlocking.
(In reply to comment #2) > I understand that from a consistency point of view its better to have > similar dialogs. > From a security point of view, a transparent layer thats still shows all the > resources added to a private activity, is still not the best option. Maybe I misunderstood something here, but why would it make sense to show the content of a private Activity before it's unlocked when switching to it??? The same privacy/security concerns that apply to unlocking the screen when a private Activity is activated apply to switching to a private Activity just the same, don't they? If If I have a private Activity and give my tablet to someone else, I switch to a non-private Acitivity first. If that person switches to a private Activity, he must not see anything that's going on there.
>>If If I have a private Activity and give my tablet to someone else, I switch to a non-private Acitivity first. If that person switches to a private Activity, he must not see anything that's going on there. +1
(In reply to comment #5) > >>If If I have a private Activity and give my tablet to someone else, I switch to a non-private Acitivity first. If that person switches to a private Activity, he must not see anything that's going on there. > +1 Okay, so that would call for making the dialog opaque in both cases again, wouldn't it? However, only Activity unlocking dialogs should be completely opaque (for security/privacy reasons), no other dialogs.
Ah, Thomas, actually the usecase switching from an open activity to a private activity doesnt trigger the problem: here the old open activity is still in the background when the pw dialog is shown. So nothing is visible of the private activity, until the user really unlocks it. The only case I can think of, is the lock screen usecase, when the private activity is shown in the background - only here the risk that someone spots on resources through a transparent dialog is given.
Git commit e3fbf1a2fc5f93cf07901ddfa03ce68fe116dc17 by Ivan Čukić. Committed on 28/04/2012 at 09:59. Pushed by ivan into branch 'master'. After the screen is unlocked, the background for the private activity unlocking is opaque. M +2 -1 service/ActivityManager.cpp M +3 -2 service/ActivityManager_StartStop.cpp M +1 -1 service/ActivityManager_p.h M +12 -2 service/jobs/ui/AskPassword.cpp M +8 -3 service/jobs/ui/AskPassword.h M +4 -4 service/ui/Ui.cpp M +2 -2 service/ui/Ui.h M +1 -1 service/ui/UiHandler.h M +2 -2 service/ui/plugins/declarativeui/declarativeui.cpp M +1 -1 service/ui/plugins/declarativeui/declarativeui.h M +1 -1 service/ui/plugins/declarativeui/declarativeui_p.h M +10 -1 service/ui/plugins/declarativeui/package/contents/ui/uihandler.qml M +7 -6 service/ui/plugins/kdialogui/kdialogui.cpp M +1 -1 service/ui/plugins/kdialogui/kdialogui.h http://commits.kde.org/kactivities/e3fbf1a2fc5f93cf07901ddfa03ce68fe116dc17