Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

On 9/24/14, 6:17 AM, "Brian Rosen" <[e-mail]> wrote:

> On the location issue, this is well traveled ground.
> 
> In many cases, the location of the device is no where near a boundary, and
> thus can be relatively imprecise.  As you get closer to a boundary, you need
> more precision in order to know if which side of the boundary you are on.  In
> white space, sometimes the regulator specifies the required accuracy of
> location, sometimes it doesn’t.
> 
> If you think about a canonical wireless microphone, you want location down to
> maybe 100 meters to avoid having problems with the microphone, but allow use
> of the spectrum where there is no problem of interference.  I wouldn’t want us
> to specify some default accuracy, but it really does need to be fairly
> accurate given current technology.  We’re starting to see location
> determination systems that could give us less than 2 meter accuracy in some
> environments, and that’s probably beyond what we need.
> 
> So you both are right.  Where the regulator specifies accuracy, that’s it, you
> send that, you need not send more.
> When the regulator doesn’t specify, someone has to put out a spec, and the
> clients need not send more accurate location.

Maybe we can build off of this and the text that Vince added in the –18 to
make one additional recommendation, at the end of the new paragraph in
Section 10:

“Similarly, regulators should require, and implementations should provide,
device location at a level of granularity only as precise as necessary to
support accurate database responses.”

Or something like that.

Re-reading the new text, I agree that the fingerprinting bit is covered.

Alissa

> 
> But, we’ve also looked at obfuscation when you want to report location less
> precise than what you have.  What we know is that it’s really, really hard to
> do it.
> 
> Brian
> 
> On Sep 24, 2014, at 2:57 AM, Vincent Chen <[e-mail]> wrote:
> 
>> Hi Alissa,
>> 
>> On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <[e-mail]> wrote:
>>> Hi Vince,
>>> 
>>> Thanks. I like the text you added, but I think the bit about fingerprinting
>>> and the caution to implementations about not over-sharing that I had
>>> suggested are both important — any reason not to include them explicitly?
>> 
>> Sorry I did not respond directly to these points. Here's my train of thought.
>> 
>> 1. The whole point of the White Space Database is to give information about
>> available spectrum at a location. The location has to be precise enough for
>> the information to be valid. So it seems odd for PAWS to recommend that a
>> device give imprecise location.
>> 
>> 2. While PAWS does indicate that serial number is optional, it is unlikely
>> that a regulator will make it optional.
>> 
>> In any cases I felt the statements indicating risk of tracking covers
>> tracking via explicit information provided by the device and via implicit
>> information derived from fingerprinting.
>> 
>> -vince
>> 
>>  
>>> 
>>>>> 
>>>>> Now that the document is clear that Slave device location and serial
>>>>> number are optional (unless required by a ruleset), I think the remaining
>>>>> task on the above three points is to add a bit of text to Section 10 to
>>>>> explain the potential privacy threats from authorized databases, perhaps
>>>>> as a short paragraph or two at the end of Section 10. Something along
>>>>> these lines (just a suggestion, feel free to reject this entirely or use
>>>>> bits that you like):
>>>>> 
>>>>> "In addition to the privacy risks described above, in some cases, users of
>>>>> Master or Slave devices may open themselves up to privacy risks related to
>>>>> the secondary use of PAWS-related information by a database administrator.
>>>>> For example, in situations where rulesets require that Master or Slave
>>>>> devices uniquely identify themselves (via the DeviceDescriptor or
>>>>> DeviceOwner parameters), database administrators may be able to use that
>>>>> information to track connectivity activity over time, or they may share
>>>>> such tracking information with third parties. Where Master or Slave
>>>>> devices choose to provide or are required to provide geolocation
>>>>> information in conjunction with unique device identifiers, this capability
>>>>> may further extent to location tracking. Even where a device does not
>>>>> provide a specific unique identifier, a database administrator may be able
>>>>> to uniquely fingerprint a device based on the combination of other
>>>>> information provided in DeviceDescriptor or DeviceCapabilities parameters.
>>>>> 
>>>>> In cases where devices have a choice to not send device-identifying
>>>>> information or geolocation, or to send less granular geolocation (i.e., a
>>>>> region rather than a point), PAWS implementations can reduce the risks
>>>>> associated with secondary use by not sending that information. Where
>>>>> rulesets require this information to be sent, these risks require
>>>>> out-of-band mitigation (e.g., public statements or contractual terms
>>>>> preventing secondary use).”
>>>>> 
>>>>> Thanks,
>>>>> Alissa
>>>>> 
>>>>>>  
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------------------------------------------------------------
>>>>>>> COMMENT:
>>>>>>> ----------------------------------------------------------------------
>>>>>>> 
>>>>>>> = Shepherd write-up=
>>>>>>> "An in-depth review by a JSON expert might be useful."
>>>>>>> 
>>>>>>> Did that happen?
>>>>>> 
>>>>>> Tim Bray had looked at it before final call.
>>>>>>  
>>>>>>> 
>>>>>>> = Section 1 =
>>>>>>> "It opens the door for innovations in spectrum
>>>>>>>    management that can incorporate a variety of parameters, including
>>>>>>>    user location and time.  In the future, it also can include other
>>>>>>>    parameters, such as user priority, time, signal type and power,
>>>>>>>    spectrum supply and demand, payment or micro-auction bidding, and
>>>>>>>    more."
>>>>>>> 
>>>>>>> Time seems to be listed both as a current parameter and a future one,
>>>>>>> which is confusing.
>>>>>> 
>>>>>> Agreed. The second "time" should be removed.
>>>>>>  
>>>>>>> 
>>>>>>> = Section 4.4 =
>>>>>>> "FCC rules, for example, require that a 'Fixed Device'
>>>>>>>    register its owner and operator contact information, its device
>>>>>>>    identifier, its location, and its antenna height."
>>>>>>> 
>>>>>>> It would be nice to have a citation for the rules referenced here.
>>>>>> 
>>>>>> OK.
>>>>>>  
>>>>>>> 
>>>>>>> = Section 5.1 =
>>>>>>> Feel free to ignore this if it's completely misguided, but does altitude
>>>>>>> really not matter? Are we sure this protocol won't be re-used for
>>>>>>> devices
>>>>>>> on airplanes trying to find available spectrum? (I note that in RFC
>>>>>>> 6953,
>>>>>>> requirement D.1 specifies that the data model must support "the height
>>>>>>> and its uncertainty" -- I have no idea what "the height" means or if it
>>>>>>> is related to altitude.)
>>>>>> 
>>>>>> See Section 5.3 on "height" of the antenna. It's separated out, from the
>>>>>> "latitude, longitude" specification
>>>>>> of GeoLocation. It allows specification with respect to ground level or
>>>>>> mean sea level, and is intended
>>>>>> for Fixed devices, rather than mobile devices.
>>>>>> 
>>>>>> From the current regulator's perspective, the allowed power for mobile
>>>>>> devices is low enough that
>>>>>> height does not matter.
>>>>>> 
>>>>>>  
>>>>>>> 
>>>>>>> = Section 10 =
>>>>>>> I agree with Stephen that the database operator should be considered as
>>>>>>> a
>>>>>>> potential adversary from the standpoint of potentially being able to
>>>>>>> create a fine-grained database that tracks the locations and spectrum
>>>>>>> use
>>>>>>> patterns of individual devices. That data could certainly be abused.
>>>>>>> 
>>>>>> 
>>>>>> So just listing that as a potential threat and declare that fixing this
>>>>>> as out of scope is sufficient?
>>>>>> 
>>>>>> Or do we need to state that Databases MUST not track? I can see how
>>>>>> anonymized tracking
>>>>>> can be useful for spectrum management in the future, much like anonymized
>>>>>> tracking of car locations
>>>>>> provide valuable traffic information for navigation systems.
>>>>>> 
>>>>>> -- 
>>>>>> -vince 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> -vince 
>> 
>> 
>> 
>> -- 
>> -vince 
>