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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
