On 9/24/14, 6:17 AM, "Brian Rosen" <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> wrote:
Hi Alissa,
On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <[email protected]
<mailto:[email protected]>> 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
