Re: [Geopriv] retransmission-allowed is harmful

[Alissa Cooper <[e-mail]>]

In the Web context, I actually think there's a lot of value in being  
able to give someone location information with instructions on how it  
may be shared. The example in section 2.1 in lo-sec gets at this a  
bit, as do your run-of-the-mill social network privacy settings  
(allowing, for example, sharing with "everyone," "friends of friends,"  
"friends," or "no one" for a particular piece of data). If this isn't  
such a standard concept yet, I think part of the motivation behind the  
Geopriv privacy rules was the thought that it *should* be.

As to the semantic of retransmission-allowed, I think my understanding  
is closer to James' than Martin's, namely:

If I set retransmission-allowed = false, then there are two options:

(1) the information is not to be shared

(2) there is an authorization policy that governs redistribution of  
this information

If I set retransmission-allowed = true, then the information is  
totally public and can be shared with the world.

I think this makes more sense since the permissions granted by the  
authorization policy are supposed to be additive. Plus, the danger of  
not conveying retransmission-allowed is that you wind up in the same  
situation we have now for most sensitive data: the recipient receives  
it, it has no policy information attached whatsoever, and the  
recipient does what it likes with the data. Even if all of us knew  
that the absence of a policy meant that retransmission was prohibited,  
we would likely be the minority.

Alissa

On Mar 15, 2009, at 7:35 PM, Thomson, Martin wrote:

> a) no need to move them, the ruleset-reference is actually pretty  
> good.  Reading lo-sec, I'm thinking that the function this provides  
> (authorizing a rule maker) is useful.  However, this assumes that  
> the use case is valid...not something I've really thought about all  
> that much - how often does one pass information to someone then give  
> them instructions on how they share that - usually, it's enough to  
> indicate that the information is secret rather than trusting someone  
> else to manage dissemination.
>
> b) There's no need to move policy around with it - this is really  
> just a rehash of the discussion on whether we need to indicate that  
> the location URI follows possession model or not.
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]]
>> Sent: Saturday, 14 March 2009 5:23 AM
>> To: Thomson, Martin; 'GEOPRIV'
>> Subject: RE: [Geopriv] retransmission-allowed is harmful
>>
>> Two points:
>>
>> A) I guess nobody really thought sufficiently deep enough about
>> conveying
>> the policies in the style of http://www.ietf.org/rfc/rfc4745.txt /
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-20.txt
>> together with location information. I suspect that folks say it  
>> more as
>> a
>> vehicle for access control and hence it wouldn't travel around.
>>
>> B) In a location URI there is no policy that travels with it (as it  
>> is
>> currently defined). One could, of course, define a URI in the style  
>> of
>> http://tools.ietf.org/html/rfc4467 and attach meta data. We discussed
>> this
>> several times already but, as far as I remember, never made a  
>> decision.
>> It
>> wouldn't really change anything with the location URI concept as such
>> but
>> the entity that looks at it would have a clue what the URI actually  
>> is.
>> This
>> would then go into the
>> http://tools.ietf.org/id/draft-winterbottom-geopriv-held-context-03.txt
>> document.
>>
>> Ciao
>> Hannes
>>
>>
>>> I also had other thoughts overnight.  Retransmission-allowed
>>> (or something to that effect) is actually helpful on location
>>> URIs.  I've made the point previously, but for what it's worth:
>>>
>>> Any indication would need to appear in the conveyance protocol
>>> associated with the location URI.  A default of "no" needs to
>>> be assumed.  A value of "yes" indicates that the rule maker is
>>> confident that the LS serving the location URI is able to
>>> effectively enforce rules.  Without such an indication, "no"
>>> is the only permissible interpretation an LR can make.
>>>
>>> Ta,
>>> Martin
>>>
>>>> -----Original Message-----
>>>> From: Hannes Tschofenig [mailto:[e-mail]]
>>>> Sent: Thursday, 12 March 2009 6:10 PM
>>>> To: Thomson, Martin; 'GEOPRIV'
>>>> Subject: RE: [Geopriv] retransmission-allowed is harmful
>>>>
>>>> In previous discussions I mentioned that the basic privacy fields  
>>>> do
>>>> not provide enough semantic, see for example
>>>> http://www.ietf.org/mail-archive/web/geopriv/current/msg06389.html
>>>> (with
>>>> regard to the question of who the recipient actually is).
>>>>
>>>> You point out another aspect that is not discussed in RFC
>>> 4119, namely
>>>> what is the relationship between retransmission-allowed and the
>>>> policies referenced by the ruleset-reference element. RFC 4119 also
>>>> does not saw what the meaning is if the ruleset-reference is empty.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail]
>>>>> [mailto:[e-mail]] On Behalf Of Thomson, Martin
>>>>> Sent: 12 March, 2009 08:13
>>>>> To: GEOPRIV
>>>>> Subject: [Geopriv] retransmission-allowed is harmful
>>>>>
>>>>> I just finished reviewing draft-barnes-geopriv-lo-sec.  I wont get
>>>>> those hours back, but it wasn't all in vain.  There's stuff
>>> in there
>>>>> I'd recommend to all members of the group.
>>>>>
>>>>> A thought arises:
>>>>>
>>>>> If I set retransmission-allowed = false, all I'm saying is the
>>>>> default.  We knew that already, no gain to be had unless a value  
>>>>> of
>>>>> true turns out to be useful.
>>>>>
>>>>> If I set retransmission-allowed = true, then there are two  
>>>>> options:
>>>>>
>>>>> (1) the information is totally public - share with the world
>>>>>
>>>>> (2) there is an authorization policy that governs
>>> redistribution of
>>>>> this information
>>>>>
>>>>> But that's the thing.  Unless you have a policy, you should be
>>>>> assuming the empty policy - and the empty policy prevents
>>>>> redistribution.
>>>>>
>>>>> Therefore, you need a policy before you can redistribute location
>>>>> information.  Therefore, the authorization necessary to
>>> distribute is
>>>>> signified by the presence of policy.  Absence of policy indicates
>>>>> that you should keep the information to yourself.  Therefore,
>>>>> retransmission-allowed is pointless.
>>>>> Therefore, it's harmful because recipients might assume (1).
>>>>>
>>>>> The prosecution rests ma'am.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> p.s. "is harmful" in the subject was chosen to be inflammatory, if
>>>>> you are reading this, I've been successful.
>>>>> Thank you for your time.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------
>>>>> ---------------------------------
>>>>> This message is for the designated recipient only and may contain
>>>>> privileged, proprietary, or otherwise private information.
>>>>> If you have received it in error, please notify the sender
>>>>> immediately and delete the original.  Any unauthorized use of this
>>>>> email is prohibited.
>>>>> ---------------------------------------------------------------
>>>>> ---------------------------------
>>>>> [mf2]
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------
>>> ---------------------------------
>>> This message is for the designated recipient only and may
>>> contain privileged, proprietary, or otherwise private information.
>>> If you have received it in error, please notify the sender
>>> immediately and delete the original.  Any unauthorized use of
>>> this email is prohibited.
>>> ---------------------------------------------------------------
>>> ---------------------------------
>>> [mf2]
>>>
>>
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
> _______________________________________________
> Geopriv mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geopriv