1 / 19

Location-based services – an IETF perspective

Location-based services – an IETF perspective. Henning Schulzrinne (+ Xiaotao Wu, Ron Shacham) Dept. of Computer Science Columbia University. Overview. Taxonomy of location-based services transition custom  Internet-based Privacy concerns Privacy mechanisms location object rules

keola
Download Presentation

Location-based services – an IETF perspective

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Location-based services – an IETF perspective Henning Schulzrinne (+ Xiaotao Wu, Ron Shacham) Dept. of Computer Science Columbia University CFP 2005 (Seattle) -- April 2005

  2. Overview • Taxonomy of location-based services • transition custom  Internet-based • Privacy concerns • Privacy mechanisms • location object rules • privacy rules and filters CFP 2005 (Seattle) -- April 2005

  3. Context • context = “the interrelated conditions in which something exists or occurs” • anything known about the participants in the (potential) communication relationship • both at caller and callee CFP 2005 (Seattle) -- April 2005

  4. geospatial longitude, latitude, altitude civic time zone, country, city, street, room, … descriptive type of location “hotel”, “airport” properties of location privacy (“no audio privacy”) suitability for different communication media Location information CFP 2005 (Seattle) -- April 2005

  5. Who or what is being tracked? • Objects • containers, hospital equipment • Vehicles • flight tracker, bus & subway •  aggregate person tracking • Persons • as individual: “Nurse Jane is in room 356” • as function: “some officer is on 5th & Main” CFP 2005 (Seattle) -- April 2005

  6. Call routing based on location emergency calls AAA tow truck pizza delivery 311 (local government) Presence (“buddy lists”) and event notification control incoming calls (“don’t ring phone if in movie theater or giving lecture”) fleet management family management “mom stuck in traffic” Location information in protocols CFP 2005 (Seattle) -- April 2005

  7. Semi-voluntary location tracking • Indoor • medical equipment, nurses & doctors in hospital • nursing home patients • Outdoor • 911 callers • parolees • children (in malls & amusement parks) • cell phones with location-specific advertisement CFP 2005 (Seattle) -- April 2005

  8. End system based  end system measures and conveys location GPS (outdoors) A-GPS (indoors + outdoors) Bluetooth or 802.11 beacon Network-based limited user control disable only by turning off device NE measures location (e.g., TOA) Ethernet switch knows port user is connected to 802.11 access point Location determination CFP 2005 (Seattle) -- April 2005

  9. Location recipients • Personally known to target • family, company • Known as function • AAA, PizzaHut, 911 PSAP, … • Unknown to target • cell phone company • surveillance • tracking by car rental company • LoJack CFP 2005 (Seattle) -- April 2005

  10. Privacy concerns • Location only • no identification of individual • location + correlator • MAC address 01-02-03-04-05-06 has visited these hotspots today • may be able to correlate to identity (hotel room) • location + personal identity CFP 2005 (Seattle) -- April 2005

  11. Granular privacy controls • Mechanically enforceable vs. indications • “show Bob only the country I’m in” vs. • “dear recipient, do not distribute this information” • Typically need to trust third party (service provider, server) • Make it easy for target to determine who gets what type of information • but limit rule complexity • make rules portable across providers • automatically derive rules from other information • “allow those in my address book to see my time zone” CFP 2005 (Seattle) -- April 2005

  12. Challenges • May be willing to divulge single location object, but not trajectory • “I’ll be at your location in 30 minutes” • set of points  “traveling 10 mph above speed limit” • May be willing to divulge reduced-accuracy location • “I’m in the PDT time zone” (so don’t call me before 10 am EDT) CFP 2005 (Seattle) -- April 2005

  13. GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) target location server location recipient notification interface publication interface GEOPRIV SUBSCRIBE presentity presence agent watcher SIP presence PUBLISH NOTIFY caller callee SIP call INVITE INVITE CFP 2005 (Seattle) -- April 2005

  14. Privacy • All presence data, particularly location, is highly sensitive • Basic location object (PIDF-LO) describes • distribution (binary) • retention duration • Policy rules for more detailed access control • who can subscribe to my presence • who can see what when <tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1“ srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W </gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no </gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z </gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple> CFP 2005 (Seattle) -- April 2005

  15. Privacy policy relationships common policy geopriv-specific presence-specific future RPID CIPID CFP 2005 (Seattle) -- April 2005

  16. Conditions identity, sphere time of day current location identity as <uri> or <domain> + <except> Actions watcher confirmation Transformations include information reduced accuracy User gets maximum of permissions across all matching rules privacy-safe composition: removal of a rule can only reduce privileges Extendable to new presence data rich presence biological sensors mood sensors Privacy rules CFP 2005 (Seattle) -- April 2005

  17. Example rules document <rule id=1> <identity><id>user@example.com</id></identity> <conditions> <sub-handling>allow</sub-handling> <actions> <provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme> </provide-services> <provide-person>true</provide-person> <provide-activities>true</provide-activities> <provide-user-input>bare</provide-user-input> <ruleset> <transformations> CFP 2005 (Seattle) -- April 2005

  18. Creating and manipulating rules • Uploaded in whole or part via XCAP • XML not user-visible • Web or application UI, similar to mail filtering • Can also be location-dependent • “if at home, colleagues don’t get presence information” • Possibly implementation-defined “privacy levels” CFP 2005 (Seattle) -- April 2005

  19. Conclusion • Wide variety of location-based services emerging • Both closed (long-term) user groups, incidental and “public” • Need user-understandable rule sets as well as legal clarity CFP 2005 (Seattle) -- April 2005

More Related