Re: [Geopriv] RE: [Simple] Changes in xcap-auth

From: Jonathan Rosenberg ^lt;>
Date: Fri Nov 07 2003 - 15:21:34 EST


Henning Schulzrinne wrote:

>>> I don't understand why the except clause in each permission
>>> statement should be dismissed while the separate exception list
>>> model can be supported.
> The exception list is restricted in its functionality to avoid the
> privacy problems caused by exception entries. Mixing the two means
> that both list types would need to be restricted as described.
> Also, having unbounded except lists makes processing more
> complicated since the simple row model no longer applies (it's no
> longer a relational table).

I share Ito-san's confusion here. Assuming the same kind of
restrictions you have asked for - no external references, no
wildcards, no domain-scopes, I dont see the difference between:





THe differences seem merely syntactic, but maybe I am missing
something here.

Henning also wrote:
> Blacklists were popular for spam-protection early on, but I think
> everyone has realized by now that they are close to useless. I'd
> hate to create a complicated, brittle, difficult-to-predict system
> just to find out a year later that this expensive feature turned
> out to be mostly an empty promise, in terms of increasing user
> privacy.

There are some serious differences here with the email spam case.
Firstly, the systems we are talking about require authentication,
which is absent in email. Secondly, and perhaps most importantly, I am
not interested in rules like "allow anyone in the world but", as I agree this is silly. We are talking about rules
like "allow only people from EXCEPT". That
is, I expect these systems to require a user to explicitly grant a
permission, but an extremely common case, I think, will be to grant it
by indicating a domain with a set of exceptions.

Ted wrote:
> To take up your point on implementation, I note that
> folks do seem to be assuming a connection between
> the UI and the protocol behavior. I can easily see
> a UI saying "Grant all buddies civil geolocation data
> at City level, except $ex-spouse, who should get
> my timezone" and translating that as a grant of
> timezone to all buddies and a second grant of
> City to each of those that isn't the ex-spouse. From
> the user point of view, it's an "except", where from the
> protocol point of view it is additive permissions.
> There is no question that there are engineering trade-offs here.
> You gain simplicity and have an easy method to
> ensure maximal privacy, but you may get increased
> object size and you may need to structure group data
> in ways that ensure it fits this model reasonably
> efficiently. Neither choice is perfect, but this one
> does have some very useful characteristics for a
> large number of GeoPriv cases. There may be other
> usage patterns in other uses of XCAP that mean
> we can't have a perfect fit, but if we can keep that
> split to a minimum, I think it's worth it.

To summarize (correct me if I am wrong), I think your suggestion was
that exceptions can be handled by expanding the lists associated with
the domain. As such, even though the user sees an exception rule in
the UI, the underlying system pushes a permission with everyone in it.

My concern is that I believe this will be very difficult to manage. It
requires the users to have access to the set of users in the domain
from which the exceptions are being specified. That list is
undoubtedly dynamic, and potentially pretty large. When a new employee
joins the company, everyone would have to update their permissiosn (or
have their agents do it automatically somehow), and similarly when
someone leaves. The result will be odd behavior for users, where
people that a user believes to have permission, actually doesnt.

-Jonathan R.

Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft                     FAX:   (973) 952-5050                      PHONE: (973) 952-5000
Geopriv mailing list
Received on Fri Nov 7 15:23:23 2003

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:24 EST