-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everyone who isn't going mad already,
ps. I also think that hashed storage is a key to our problem of access
control lists:
GIVEN hashes don't collide (requirement for security), we can use that
characteristic for our implementation of fine grained access control
lists (which we don't have at the moment):
Client x is an application with granted rights through a group-x.
Once our index is separated from the 'content-to-return', we could
"salt" the hashes (in the index) with extra infos from a group-x to
allow queries requesting data from a specific client-x (being part of
a x-group) to return correct results":
Such a group-x could for example be represented as a graph in RDF.
Say we wanted the results of a query for a client-x, belonging to a
group-x, where content is allowed to group-x because of a access
control rule bound to group-x, we could "salt" all hashes for strings
in the index (which contains p2 strings) start matching in case a
client from such a group-x creates a p1 for a Function
bool=compare(p1,p2);
Making hashes p2-p1 match the comparers instantiated for client-x match.
Data plus the characteristic of non-colliding hashes creates the ACL.
But maybe I'm crazy. Yeah.
Kind regards,
Philip
Philip Van Hoof schreef op 3/05/2014 16:01:
> Hi everyone,
>
> I think that not duplicate storage of metadata (a rightful reason
> to wanting to store the metadata in the attrs of files) or the
> speed to access it (why it's currently a sqlite 'index' instead of
> using UNIX tools like find and locate - or why pipe() can't solve
> everything), is going to be the issue in future.
>
> The old-time reason of why we store metadata locally, so that to
> query it content can be anywhere instead of just locally, also
> still holds.
>
> Admitting that I'm a bit influenced by recent scandals related to
> various intelligence agencies, I think that also the time is right
> for secure metadata-storage. I .. don't think that much has
> changed. Just the perception of our users. But perception too
> steers innovation.
>
> A solution I have in mind is storing hashes instead of content
> with references to a key-value storage storing stringly values
> strongly encrypted.
>
> I think we must store stringly metadata as hashes in the index.
>
> SPARQL functions like str() can be adapted to convert the input to
> a hash, allowing operators to compare hashes instead.
>
> At the point of return we use the client's provided public key to
> encrypt the data and pass it on over IPC or using direct-access
>
> (libtracker-sparql can encrypt it in process in case of WAL
> direct-access, this of course requires leaking the private key to
> the process - of which I'm not a fan. With that Adrien's FD passing
> is yet again a good thing to have).
>
> This idea, I admit, doesn't secure relationships. I have no
> solution for that as we need the relationships between entities
> unencrypted for them to be queryable efficiently.
>
> Kind conspiracy regards,
>
> Philip _______________________________________________ tracker-list
> mailing list tracker-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/tracker-list
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTZQNkAAoJEEP2NSGEz4aDB3gIAKB0wRaPeJhgezWuIJXRU8/m
vy60Q40kb8S6qkWW1CTntbw3EFvvAgiMQBB29fa+bCUzb6F19r2WjQc8wvpUlyqr
/kN4NMW8arGNFo18M8av1rMGldwDSW9GT5zXZLEtoLF4VAJRuxVO0HT2OiYNjQfZ
Wng+Xxahj/GyhQ5AlRlbpPqoHcF7jxzL9tRzKEiuiyh0BGzEY9DVk8JMEWVEEV11
/rUfHs4Ewh/Wb31pW1s9hnSFgsBDY5koihWzPncRVc0PFnTZ7ncCupU/xslBa6oe
vFotDsQiSSo5SkNmz2grTlGsQPEz0FxSWozykmC00FuAnNE8XjeNAywHTQxBDwQ=
=C8Pp
-----END PGP SIGNATURE-----
_______________________________________________
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list
