Event blacklisting/Privacy mode

There are several ways of tackling this issue:
1) Either not log events from specific apps (which is solved now) by disabling the plugins in the applications
2) Have a little profiler as in a blacklist for home and another for work. Those could be either actors or subjects. According to the active profile we have a bouncer module in front if the insert method to make sure nothing gets in that is balcklisted.
I see us tackling this issue sooner as we think and I would like to know your opinions on this issue.
Cheers
Seif

Only the "Tim" usecase in the description of this bugreport can be solved by a blacklist system.
For the "Tina" usecase we need to find a way to apply filter on already existing entries in the database to delete them

Markus - we already have a DeleteEvents() method taking an array of ids. Just do FindEventIds(templates) and pass them to DeleteEvents. This makes it easy to do highly advanced event deletion schemes.

As for blacklisting this is really an issue in apps pushing events to Zeitgeist I think.

@Mikkel, right. So maybe it is just about putting this into an usable UI. But this is unrelated to this bugreport.

No the Tina use case can be used also with an external blacklist system. In
whiche she quereis for everything that is "!foo"

2009/11/25 Markus Korn <email address hidden>

> @Mikkel, right. So maybe it is just about putting this into an usable
> UI. But this is unrelated to this bugreport.
>
> --
> Zeitgeist should have any kind of system to protect users privacy
> https://bugs.launchpad.net/bugs/447417
> You received this bug notification because you are a bug assignee.
>
> Status in Zeitgeist Framework: Confirmed
>
> Bug description:
> Zeitgeist should respect the following use cases:
> * Tim has a directory ~/Videos/pr0n, he does not want zeitgeist to track
> any events regarding this directory
> * Tina played a card game at work and found out that this event is shown
> in her zeitgeist client, she would like to remove this event to hide it
> from her boss
>
>

Removing events after their insertion is not the answer, they should
never be inserted at all if they are blacklisted. If they get inserted
they are broadcasted to all listening programs (possibly including
stuff like Teamgeist) so it's too late to delete them.

I'd like to have filtersets defined (just like in Teamgeist for
deciding what is send out) and InsertEvents should check stuff against
the blacklist and reject it (returning None -ie. ""- in the event's
position in the the list of event ids resulting from the InsertEvents
call). The code for this (checking if an event matches the filters)
should probably go into a public module so that other applications can
use it too.

Better ideas are welcome, of course!

There are 2 balcklists.
blacklists that dont allow insertion ito the DB in the first place.
blacklists that dont allow exposure of the events over dbus per default.

The first is no issue and could be implemented instantly, while the second
is a matter of definition. Should the profiling be done on the client side
or should that be in zeitgeist?

2009/11/25 Siegfried Gevatter <email address hidden>

> Removing events after their insertion is not the answer, they should
> never be inserted at all if they are blacklisted. If they get inserted
> they are broadcasted to all listening programs (possibly including
> stuff like Teamgeist) so it's too late to delete them.
>
> I'd like to have filtersets defined (just like in Teamgeist for
> deciding what is send out) and InsertEvents should check stuff against
> the blacklist and reject it (returning None -ie. ""- in the event's
> position in the the list of event ids resulting from the InsertEvents
> call). The code for this (checking if an event matches the filters)
> should probably go into a public module so that other applications can
> use it too.
>
> Better ideas are welcome, of course!
>
> --
> Zeitgeist should have any kind of system to protect users privacy
> https://bugs.launchpad.net/bugs/447417
> You received this bug notification because you are a bug assignee.
>
> Status in Zeitgeist Framework: Confirmed
>
> Bug description:
> Zeitgeist should respect the following use cases:
> * Tim has a directory ~/Videos/pr0n, he does not want zeitgeist to track
> any events regarding this directory
> * Tina played a card game at work and found out that this event is shown
> in her zeitgeist client, she would like to remove this event to hide it
> from her boss
>
>

2009/11/25 Seif Lotfy <email address hidden>:
> The first is no issue and could be implemented instantly, while the second
> is a matter of definition. Should the profiling be done on the client side
> or should that be in zeitgeist?

I'd say thats a per-application thing, but I'm not sure I get the use
case for it right.

--
Siegfried-Angel Gevatter Pujals (RainCT)
Free Software Developer 363DEAE3

I think that Siegfried has an important point. Since we like to relay events around the system the Zeitgeist core will need a blacklisting mechanism. There are several steps in such a solution as I see it...

We need a matches_template(event_templ) method on the Event class. This will be mighty handy for lots of things.

Then we we should IMHO not just broadcast any old event over the bus. We should do some kind of subscription service where apps register event templates they want to listen for. And then we only notify apps that have registered matching templates.

Embedded in this subscription system should be a blacklisting mechanism.

2009/11/25 Mikkel Kamstrup Erlandsen <email address hidden>:
> Then we we should IMHO not just broadcast any old event over the bus. We
> should do some kind of subscription service where apps register event
> templates they want to listen for. And then we only notify apps that
> have registered matching templates.

Is this even possible at all with D-Bus?

>> templates they want to listen for. And then we only notify apps that
>> have registered matching templates.
>
>Is this even possible at all with D-Bus?

Yes. The direct solution is to have clients register some callback interface. The more elegant approach would be to send directed signals. Then a third approach would simply be using DBus Match rules (but I think this will restrict the API a bit). I am not 110% sure that directed signals are possible, but I think I read about it somewhere...

See also bug #491646

Assigning myself to this bug as the blacklisting impl. is very close to what we already do with the notifications.

My plan is to simply pickle a collection of blacklisting Event-templates and then filter events on those, almost exactly the same way we notify monitors.

The plus side here is that with a very little extra work I can make this work as an extension. I just need to insert a hook in resonance_engine.py where it filters any incoming events through the installed extensions. I actually already implemented this a while ago, but the branch where I had it is lost. It's easy to redo anyway...

I just linked the branch lp:~kamstrup/zeitgeist/blacklist to this bug report. It contains some initial work, but it is *far from finished* - so no need to review it yet.