PING - informal chairs’ summary - 29 May 2014

PING - informal chairs’ summary - 29 May 2014

Note: Next meeting - 26 June 2014 at the usual time

Special thanks to the Working Group representatives who joined the PING
call to lead discussions of privacy considerations: Giridhar Mandyam from
the Geolocation WG and Janina Sajka, Katie Haritos-Shea, James Craig and
Michael Cooper from the Independent User Interfaces WG.

Also, many thanks to Joe Hall for scribing.

* Geolocation WG
Giridhar Mandyam led a presentation on the newly re-chartered Geolocation
WG [1] and some of the privacy issues they have been considering as their
next work begins [2].

The Geolocation WG was one of the first device API WGs. Under the initial
charter, they produced two specifications: the Geolocation API and the
DeviceOrientation API, which saw widespread adoption. Another initiative,
that of reverse geo-coding -- mapping the latitude/longitude to an address
-- lacked developer interest and was shelved before last call. There are a
number of privacy concerns that arise from exposing geolocation information
to Web applications, such as exposing home addresses and facilitating
tracking of individuals. Furthermore, users may not be aware of which sites
they have provided with long-term access to their geolocation data, and
there is a limited ability for them to manage permissions through the
browser UI; Nick Doty noted that this issue -- persistence and revocation
of permissions -- is a major challenge with Web APIs that is not unique to
geolocation.

There are two main work items in the new Geolocation WG Charter [3]. The
first item is adding geofencing to the Geolocation API, to allow for
hardware-based geofencing (beyond the JavaScript-based method currently
supported in the API). Use cases for geofences include alerts near points
of interest, and mobile marketing. The second work item is cleaning up the
DeviceOrientation specification, to address interoperability problems that
arose in the first version of the specification. Additionally, there are
plans to develop use cases and requirements for indoor location extensions
to the API, which allows for more specific information -- for example,
floors in a building. (This work is not explicitly listed in the charter.)

Joe Hall asked how the indoor location extensions would be implemented; it
depends on the technology, but it could use knowledge of access points in
buildings, bluetooth beacons, Bluetooth Low Energy (BLE). Databases with
WiFi access points are vital and there are people actively taking
measurements of access points for this purpose. Nick Doty asked whether
there might be simple options for providing less precise geographic
information. There is a flag that, when set to false, causes the API to
operate with granular location (enableHighAccuracy flag), although this may
be difficult to get it implemented in a mobile browser. James Craig
mentioned that a feature that is currently missing from the Geolocation API
is a means to provide the user with the justification for why a site wants
access to geolocation data (which is not always apparent). There are some
limits to this approach (e.g. how do we know the notification is
trustworthy?) but this could be an optional feature that some sites might
like to use. Hannes Tschofenig mentioned the related IETF work on indoor
location and its approach to privacy[4]; the Geolocation WG (and the Indoor
Location Alliance) has been following this work, but also mentioned that
they do need to get support -- for example, from OS vendors -- in order to
extend these features to the browser.

* IndieUI WG
The Independent User Interfaces WG & TF (IndieUI) would like advice about
privacy considerations in the Contextual Information for User Interface
Independence specification (User Context 1.0) [5].  (This is one of two
deliverables for the IndieUI.) The objective is to develop a general
interface to communicate user settings (not just accessibility settings).
The idea here is that servers can do a better job of tailoring content if
users are able to clearly specify what their preferences are. (Note: some
of this is already available with standard approaches, e.g. font size.) The
risk is that expressing such preferences might expose a user’s disability,
and possibly identify a user (along with their associated preferences). An
example might be the preferred font and color for captions. Unlike in the
Geolocation API, the Indie UI User Context 1.0 draft specification [5]
includes a method (a localised string) to provide a justification for
requesting the data (e.g. for captions for a YouTube video) - sometimes
optional, but required for some high-security contexts where a user may
want to trust only certain sites with that information. For example, screen
reader preferences are considered higher risk and in most cases that
information is not needed by the operator. The WG aims to publish the first
draft of the Context User 1.0 specification in late June.

James Craig added some comments on fingerprinting, asking that attention be
paid to Section 4 of the draft specification. The specification doesn't
restrict access to things that are readily discoverable, but the WG has
discussed solutions for more high-security preferences (e.g., HTTPS); they
want to put access to some items, such as assistive technology, behind a
prompt. Nick noted that PING is trying to get common guidance on
fingerprinting, so it is helpful to consider which elements are most likely
to be used for fingerprinting and the potential risks to users. There was
some debate over the value of HTTPS in this context, given that the other
end still receives the information and that requiring HTTPS could be a
barrier to entry for using the API. Nick encouraged followup discussions
over email, particularly given the ongoing PING work in this area.

* Privacy guidance and process documents
- Privacy Considerations Document
Nick has sent comments, and Joe Hall and Christine Runnegar are planning to
send comments. This subgroup suggested they should form an informal task
force to work on the document. Nick will put the document on github.
- Specification Privacy Assessment
Frank Dawson has been spearheading this, and mentioned the working meeting
held at CDT in March.  Some deep process issues have been identified, such
as: if you handle privacy considerations after chartering, it is hard to
get those incorporated, so it is necessary to think about the potential
footprint of privacy and security when chartering.

Nick Doty mentioned three relevant W3C work items that PING might want to
be aware of (that is, take a look at). First, best practices in capability
URLs [6], which involves privacy -- they are looking for feedback. Second,
the Tracking Preference Expression (TPE) specification of the Do Not Track
WG is in last call on June 18 [7]. Third, the Web Security Group is looking
for feedback on proposed guidelines for specification reviews [8].

* TPAC session
Just a reminder that we have requested a slot for a privacy session at the
W3C Technical Plenary and Advisory Committee (TPAC) meeting in Santa Clara,
California (27-31 October 2014). We would like to know how we can make best
use of that time for PING business, and so we strongly encourage discussion
of this subject on the mailing list.

[1] http://www.w3.org/2008/geolocation/
[2] http://lists.w3.org/Archives/Public/public-privacy/2014AprJun/att-0012/
Geolocation_WG_Status_for_PING_May_29_2014.pdf
[3] http://www.w3.org/2014/04/geo-charter.html
[4] https://datatracker.ietf.org/wg/geopriv/
[5]
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html
[6] http://www.w3.org/TR/capability-urls/
[7] http://www.w3.org/TR/tracking-dnt/
[8] http://www.w3.org/Security/wiki/IG/W3C_spec_review

Christine and Tara