Thanks, Alissa! The new sentence looks good and strikes a great balance. I'll add and upload a new version.
-vince On Wed, Sep 24, 2014 at 2:05 PM, Pete Resnick <[email protected]> wrote: > It sounds like we're closing in. Just in case, I've put the document on > tomorrow's informal IESG telechat and invited Vince to join us (neither of > the chairs can make it). If it resolves before then, great. If not, we'll > work it out in real time. > > Thanks for working on this, all. > > pr > > > On 9/24/14 3:28 PM, Alissa Cooper wrote: > > On 9/24/14, 6:17 AM, "Brian Rosen" <[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]> wrote: > > Hi Alissa, > > On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <[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 > > > > -- > Pete Resnick <http://www.qualcomm.com/~presnick/> > <http://www.qualcomm.com/~presnick/> > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
