-9

When you click on a passworded activity, the password window pops up. A password protected activity would be great for those times most of us allow others to use our desktop or laptop. Apps such as browsers can then be designated to running a particular profile in those activities. Future versions of KDE is said to have applications/windows that are 'activity aware', I'd like apps such as kopete, accounting app, etc to be accessible behind a password protected activity.

What should it be good for? It would not add any security, you could still start Kopete in another activity etc. What do you want to have? Loading encrypted directiories (browser profile) when changing to the activity? Separate KWallets for such activities? Just a password dialog would not change anything.

The User wrote:What should it be good for? It would not add any security, you could still start Kopete in another activity etc. What do you want to have? Loading encrypted directiories (browser profile) when changing to the activity? Separate KWallets for such activities? Just a password dialog would not change anything.

I said apps like kopete would run a particular profile with an 'activity' which would make running it in another moot. There is security through an addiction layer e.g password protected activity.

oracle2b wrote:
I said apps like kopete would run a particluar profile withi na 'activity' which would make running it in another moot. There is security through an addiction layer e.g password protected activity.

If someone else needed to use your computer why couldn't they just do a quick user switch? Isn't that what user switching is for?

You want the activities layer to add and manage profiles (rc and data files) for applications different from the ~/.kde/share ones? How many different activities with unique profiles would you want creatable? And the applications with separate profiles would include kde, non-kde and wine apps?

It would need encryption and stuff like that, otherwise there would not be any extra-security.
Should it be for multi-user-environments?

This seems like it isn't the right approach. It is like trying to shoehorn a multi-user mode onto a per-user system (Windows 98 comes to mind).
Either it would take a large amount of effort to distinguish the activities sufficiently to ensure that password-protected activities are secure from any kinds of user access (i.e. all data related to the activity is encrypted/password protected, but only the data related to that activity), or you would end up with a facade that isn't really secure.

As Linux systems are inherently multi-user environments, even if you are running a single-user system, you should set up some kind of guest access whereby you lock your current session and start a new guest session for the borrower to use (or set up a permanently separate account if they are going to be using it on a regular basis - this has the added benefit that they can set their own preferences without touching yours).

Despite the lack of the support this idea has received here, it's being implemented anyway. http://ivan.fomentgroup.org/blog/2012/0 ... ctivities/

Originally, this was intended for Plasma Active - a non-multiuser system. Locking activities is not a bad idea in such an environment. The same goes for a lot desktop installations out there where the whole family uses the same account on a computer - it is a nice way to hide something from your children.

Otherwise, it can be used if your contract for a job obliges you to keep some documents encrypted.

> The same goes for a lot desktop installations out there where the whole family uses the same account on a computer

Well for that use case we should just work on making user switching easier and better. Something lightdm-kde does a bit better than KDM (though still room for improvement)

There's no point trying to bodge activities to mimic user-switching like behaviour when we could just use what we currently have.

The use-cases are valid, and have been devised by some of our ui designers.

This is not about simulating multi-user experience, but rather achieving something that was previously simulated by using m-u.

In my opinion, it adds more security in e.g. this user-case:
You use one notebook for everything, work & private, and being highly mobile. So the risk to get your machine stolen may be high. Then you also manage your bank accounts with that machine (e.g. using Kmymoney). If you have a protected activity for banking and get all related documents (browser cache, account numbers and whatever nobody else should be able to see) encrypted improves security and usability.
For now, I use a truecrypt container, where I put all stuff in. That means, I have to start truecrypt first.

robsn81 wrote:In my opinion, it adds more security in e.g. this user-case:
You use one notebook for everything, work & private, and being highly mobile. So the risk to get your machine stolen may be high. Then you also manage your bank accounts with that machine (e.g. using Kmymoney). If you have a protected activity for banking and get all related documents (browser cache, account numbers and whatever nobody else should be able to see) encrypted improves security and usability.

Thank you for articulating what I had difficulty explaining. If implemented correctly, this could also be a killer feature. I imagine a light-bulb moment/epiphany for most users just like the introduction of incognito mode/private browsing changed most users habits and how they view online browsing security/privacy.

I agree with all said.

Lets hope that app developers can be persuaded to use encrypted caches and so on.

But, lets first polish and push this into mainline plasma

It is probably hard to realize, but you could use Xephyr + Plasma Valut + Conterization.

But these activities would be very limited. What about moving windows between activities?

But these activities would be very limited. What about moving windows between activities?