Hello Ivan,

I read your response, thanks for your help. But a new question arises
from your words:

I haven't started working on the Semantic Desktop integration yet, but I
think there may be a privacy problem here: Imagine a user has a private
todo list (for example, "TODO buy condoms" or something like that), and
it's stored in Tracker's database. Then any program aware of the
ontology I use for tasks, can easily fetch the task and publish it on
the web.

This is true for many other kinds of data, including plain text, but
when all the metadata and short data is stored in one central semantic
database, it may be necessary for some apps to be able to stored
encrypted data. For example, some diary apps allow specifying a
password. Back-up tools do that too. Archive formats can be encrypted
too.

So the question is: If I use Tracker on Gnome 3 as a database for my
app, e.g. to store tasks, including very private ones, is there a way to
store them encrypted in such a way that only apps which are given
permissions from the user (e.g. by having the user give them the
password) can understand the data?

This problem is not mentioned when talking about Semantic Web, but when
it comes to Semantic Desktop, it's natural to hide your resources unless
some of the are specifically public.

Note: Maybe SELinux can help with that, but I don't think it can block
partial access to Tracker (just block entirely, which is not what I
want), and anyway SELinux is currently not even enabled on many distros
(although it does exist on them, as part of the kernel).

Anatoly


On ה', 2013-05-30 at 15:23 -0700, Ivan Frade wrote:
> Hi Anatoly
> 
> 
> 
> 
> 
> On Thu, May 30, 2013 at 6:52 AM, אנטולי קרסנר <[email protected]>
> wrote:
>         Hello,
>         
>         
>         My program consists of two parts:
>         
>         1) On the lower level, an RDF schema is defined. It's a
>         standard set of
>         classes and properties, possible extended by users who want
>         more options
>         (using a definition language translated to RDF).
>         
>         2) On the high level, the user defines resources using those
>         classes and
>         properties. 
>         
>         
>         There's no problem with the lower level, because the data
>         model is
>         public: Even if a user decides to add new content, she's very
>         welcome to
>         share it and make other people's apps have more features. 
> 
> 
> Yes and no. Adding classes and properties is easy but the
> removal/renaming is complicated:
> 
> 
> App A installs ClassA, subclass of CoreA
> 
> App B installs PropertyB to ClassA
> 
> What happens if App A wants to change its classes? Rename ClassA to
> ClassA2?
> 
> 
> Now we uninstall app A. What do we do with its schema? 
> 
> 
> Add here changing properties domain or cardinality...
> 
>  
>  
>         The problem is
>         with the second part. In the higher level, the user defines
>         tasks,
>         meetings, appointments, plans and schedules. These may be
>         private, and
>         the user may prefer to to have any info in the URI revealing
>         the source
>         of the information.
> 
> 
> Here are two things, security and URI schemes, and they are
> independent.
> 
> 
> RDF is just a graph with no permissions/security in it. The software
> on top should take care of exposing only the right nodes and edges to
> the client depending on its permissions. Not a trivial problem.
> 
>  
> 
>         
>         So here are the questions I have on my mind:
>         
>         1) Which URI scheme should I use? I don't have a website or
>         any web
>         pages, so using http doesn't make sense. It also doesn't seem
>         to make
>         sense to use any other standard IANA-registered URI. I've been
>         considering two options: Use some custom, my own, URI scheme
>         name for
>         public resources, and use a bare URN for private ones,
>         something like
>         this:
>         urn : random_name_i_made_up : some_private_resource_uuid
>         But I was wondering whether a custom URI scheme is a good
>         decision, I'm
>         open to hear ideas from you :)
> 
> 
> The URI just needs to be a *unique* ID of a resource.
> 
> 
> At least in Tracker terms, autogenerated or using your own schema
> doesn't make any difference.
> 
> 
> 
> 
>         
>         2) How to hide the private resources? On one hand, it may be
>         very useful
>         for the URI to tell where a task came from, especially when
>         tasks are
>         shared and delegated between people. On the other hand, it
>         doesn't
>         consider privacy. Then I was thinking, can I/should I use two
>         different
>         URI styles depending on user settings? This would create some
>         inconsistency. I'm not sure what to do here, since I don't
>         have any
>         experience with URIs. Hopefully you have some advice for me.
> 
> If you use the URI to detect privacy... any client who doesn't honor
> your pattern will have access to everything.
> 
> As a rule of thumb, it is not good to encode information in the URL. 
> 
> 
> Specifically in Tracker, there is no way to hide "some" resources.
> There is a database per-user, and anything with user permissions can
> read/write anything in the store of that user. In other words, either
> you have access to the graph or you don't.
> 
> 
> 
> You could to store those private resources in some different db
> (internal for your app)... ugly, but blame RDF :)
> 
> 
> 
> Regards,
> 
> 
> Ivan
> 


_______________________________________________
tracker-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/tracker-list

Reply via email to