GlobaLeaks icon indicating copy to clipboard operation
GlobaLeaks copied to clipboard

Evaluate replacemeents with INTEGERS in place of uuid4 db tables ids.

Open evilaliv3 opened this issue 9 years ago • 5 comments

Given the fact that we do not rely anymore on the need of making not guessalbe the ID of the database (as it was need by the tulip concept), we should evaluate the removal of UUID4 in the database entries and we would evaluate the usage of simple integers.

This would speed up queries in general as integers.Obviously the space for the index would be reduced as integers are stored up to 8 bytes (sqlite), but i think it will be enough.

\cc @fpietrosanti @mmaker @hellais @vecna : what do you think? is there still any need for some tables to have uuid4 that i'm forgetting?

evilaliv3 avatar Aug 25 '15 19:08 evilaliv3

yes, and INCREMENTAL, please. we have seen that there is not security reason to keep the ID secrets

vecna avatar Aug 26 '15 08:08 vecna

i'm with this totally. the only issue would be to do a migration so that every uuid is migrated to an id while still preserving all the references but i will try to understand how to do this smootly.

last concern: the only uuid that may be interesting to keep is the internal tip id; the reason? if we use an incremental id you are able to know the number of the tip that are inside the system. the same may apply wherever the node is reused among multiple initiatives where you can understand how many context/receiver are there totally and even query them. maybe we sould keep this uuid only for context/receiver/internaltip?

what do you think @fpietrosanti ?

evilaliv3 avatar Aug 26 '15 09:08 evilaliv3

@evilaliv3 I don't think that we should consider "internal database structure" as a privacy issue, let's go with the best application database design possible, considering also that this database schema will need to possibly be movable also to other databases (pgsql, mysql, etc)

fpietrosanti avatar Aug 26 '15 10:08 fpietrosanti

Applying label Performance

fpietrosanti avatar Aug 26 '15 10:08 fpietrosanti

fabio it's not an internal database structure issue only

its something exported by all the API.

e.g. the id of a tip currently does not provide you the information on how many internaltip the system is handling. now you have url that poit to the tip that are: http://po47k4agopleagki.onion/#/status/8d2fcd6f-f419-4020-b979-478127b0c225

if we do this change to the tip id the link would be http://po47k4agopleagki.onion/#/status/12 that clearly says you that you are accessing the leak number 12 so the system has or hard 11 other leaks. given that generally db systems makes also reuse of id that are deleted you are alwaysable to recognize how many tip are in the system.

evilaliv3 avatar Aug 26 '15 10:08 evilaliv3