Re: [Tracker] Fear and Loathing in Las Vegas

[Philip Van Hoof <philip codeminded be>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/09/2014 15:50, fr33domlover wrote:

Hi Freedom lover,

> I think it can be useful, here's an example: Assume you have
> Tracker installed, and you want to install some photo album manager
> which has a tendency to find your photos and upload to the "cloud".
> The problem is that it also takes some personal photos you don't
> want to share, and you can't configure it to ignore those photos.
>
> While this is an app problem, it would be so nice if you could tell
> Tracker "don't let that app access these photos", problem solved
> instantly.
>
> It doesn't even have to be about hashes and crypto - just have an
> ontology for "data access permissions" and use it to describe which
> software can access which info. When doing a query, cross the
> result with that data to filter out the hidden parts.

You need the hashes and the crypto to enforce it. Else apps can still
open meta.db themselves and get the data out bypassing any security we
provide.

They could index the data of the user themselves too if they can run.
But with kdbus, lightweight containers, etc I'm thinking of doing the
metadata indexer in a container that holds the $HOME/Documents FS and
exposing the metadata to other such containers that run the apps of
the user who'll need to query the metadata's sparql endpoint.

That would preferably go over SQLite WAL or libtracker-sparql's
direct-access. Although with kdbus's implicit zero-copy fd-passing
like solution for large messages, the overhead of IPC might be
negligible (actually exactly like our current FD passing done by Adrien).

But I'm not sure about it: right now we return the const pointer right
from the sqlite_next's return value. With kdbus we'd  still need to
create the message (meaning tracker-store would carry a burden it
doesn't have to carry with direct-access), and we'd have to traverse
the entire result over SQLite's sqlite_next cursor. Something the
client's process otherwise has control over.

With crypto and hashes the client has to decipher and make a map of
the hashes though. So neither solutions are free. But that way it can
use direct-access and make use of SQLite's cursor API exposed by us so
that the sparql and the sqlite world map.

> I think the in general Tracker should be a desktop/mobile data
> manager, and the apps should have less control. For example, many
> 3rd party mobile apps spy on you and read all your private data.
> Wouldn't it be so powerful to allow Tracker to manage this on its
> end, so that you can give less trust to those apps?

Not just powerful. In Lennart's containers and apps idea I think it's
even going to be a requirement sooner or later: the idea is hw
isolation to protect the user's privacy.

But if we are going to expose ALL of the user's metadata to all the
apps and containers through a single metadata API; then you don't need
the hw to spy on the user any more. Just our single metadata API.

I don't like that. Apps ought to be controlled and not just trusted.

> Having the plain option without hashes would also be faster, and
> you don't have to fight crackers all the time, since people who
> desperately want your data can just sneak behind Tracker to the DB
> or parse the DB files etc. Of course it's also nice to have crypto
> for those who really want it.

That's why the DB needs to be encrypted. Then they can try to parse DB
files. They could only reveal relationships in my proposal. Not the
data itself.

> I'm not a Tracker user/develop but I've been working on semantic
> desktop related things, just wanted to share my thoughts on this.

We know :), nice to have you back.

Kind regards,

Philip


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJUCgfcAAoJEEP2NSGEz4aDHA0H/1JAjzVR4xSV8D0SA6ZJtg8I
1NPY7OkG8z8Tz3+V3n6dCcIu4qAJe53dnyIQIoIxZSN0Y8taKpfXJ9p/15eo0xGd
xq17b+8/muTdDLxC7Cl7AFpr8sOKPuCVru8jDGcDkn+VfM5NFGNA7ctvfm/a7S5Y
d7ScHRjkrWBP/KRIRono5KtwSU0M3ijNs53yq8JCO5MqhadeNlqI5U3W5FQX7nZi
dI/AE7BR0inQEUUtySUSEUIQQdElWi7AQ6dYec0Cd/hhV23TVH9C1BuTkBlR4xx+
L25M/BWWKnmvI/W13EE3j3uscob/8WJs1rXHcgXiJ1WcXZW6O6SNwwi+uXZVP2k=
=GEy8
-----END PGP SIGNATURE-----