[cap-talk] Rooted graph bad for POLA ? ( search capability )

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Thu Oct 2 09:12:23 CDT 2008


At Thu, 2 Oct 2008 13:41:06 +0200 (CEST),
"Rob Meijer" <capibara at xs4all.nl> wrote:
> On Mon, September 29, 2008 14:07, Marcus Brinkmann wrote:
> > But to make progress on this matter, it would first be necessary to
> > define the scope of the problem.  For example, it is not even clear to
> > me what your universe of objects is.  Is it a single node computer, a
> > local network, the internet?  I think that the bigger your universe
> > is, the more likely it is that your claim is correct, but for
> > universes with a small scope, like the personal computer on my desk, I
> > think that your claim is wrong.
> 
> I disagree. I  feel it both applies for 'user' as stakeholder within the
> internet as universe, as for (persistent?) process in a desktop as
> universe. For example your mail client should be able to use an index
> service to search a mail in the mailboxes it has permission to read.

If the scope of your example is the mail client process alone, then it
will by definition not have access to the indexer, unless the indexer
is part of the mail client process.  The indexer is a different
process in the same desktop, but by your definition not part of the
universe.

Once you start including all reachable processes into the universe,
you might find that you have dragged basically the whole desktop
system.  So let me start from there: I require a desktop computer
system which gives me unrestricted access to everything that is stored
and executed in it.  I use free software, and I reject TPM and DRM.
So, whatever the implementation details of my mail client and search
indexer are, at some level I need access to all my files, all my
mails, and everything else stored on the computer.

This is the super-root without which I would feel that the system does
not give me the same level of functionality as a system which does not
have such a super-root.

Thanks,
Marcus



More information about the cap-talk mailing list