# Device APIs and Policy Working Group Teleconference

## 01 Jun 2011

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Robin_Berjon, Frederick_Hirsch, Dominique_Hazael-Massieux, Laszlo_Gombos,
Daniel_Appelquist, Kyung-Tak_Lee, Anssi_Kostiainen, Dzung_Tran, Wonsuk_Lee,
Rich_Tibbett, Cathy_Chan, Dong-Young_Lee, bryan_sullivan

Regrets

    Claes_Nilsson, Niklas_Widell

Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    AnssiK

## Contents

  * [Topics][5]

    1. [Administrative][6]

    2. [Welcome, agenda review, scribe selection, announcements][7]

    3. [Minutes approval][8]

    4. [TAG minimization draft][9]

    5. [Contacts][10]

    6. [Battery Status][11]

    7. [Network Information][12]

    8. [Feature Request Access Containers][13]

    9. [HTML Media Capture][14]

    10. [Other][15]

    11. [Adjourn][16]

  * [Summary of Action Items][17]

* * *

<trackbot> Date: 01 June 2011

### Administrative

<scribe> ScribeNick: AnssiK

<darobin> RESOLUTION: Anssi rocks

<dom> +1

### Welcome, agenda review, scribe selection, announcements

<fjh> 19-21 July F2F logistics, [http://lists.w3.org/Archives/Member/member-
device-apis/2011Apr/0000.html][18]

fjh: F2F is in July, please register

<fjh> Please register - [http://www.w3.org/2002/09/wbs/43696/paris-2011/][19]

<fjh> Chartering

<fjh> see [http://www.w3.org/2010/11/DeviceAPICharter.html][20]

<fjh> [http://lists.w3.org/Archives/Member/w3c-ac-
members/2011AprJun/0041.html][21]

fjh: chartering is on its way

... AC reps are looking at it as we speak

<fjh> DAP and Web RTC

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0059.html][22]

fjh: WebRTC and DAP chairs met recently

Dom: WebRTC will be dealing with the media streaming, DAP will handle the
media recording

... we could get inspiration from them

<fjh> 2nd Last Call DOM Events, end 28 June

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0055.html][23]

fjh: DOM3 Events LC

... any other announcements?

<wonsuk> +

darobin: web perf WG is about to release couple of things

### Minutes approval

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/att-0048/minutes-2011-05-25.html][24]

**RESOLUTION: Minutes from 25 May 2011 are approved**

### TAG minimization draft

fjh: I sent some comments

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0004.html][25]

<fjh> comments, [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0070.html][26]

DKA: thanks for inviting me to call in

<DKA> [http://www.w3.org/2001/tag/doc/APIMinimization.html][27]

DKA: I discussed the draft with people in this group and in Geolocation WG and
WebApps WG as well last your at the TPAC meeting

... Web App Data Minimization is a working title

... it's about data minimization really

<dom> "Data minimization in Web APIs"

DKA: the topic spun off of the privacy workshop held in London last year

... we were trying to figure out what TAG could do to help in this space

... another WS in Boston was held between IAD? and W3C where we pondered the
Privacy by Design concept

... it is more concrete concept if applied to (web) services

... I took an action to talk about the general principles, and how it applied
to API design on the Web

... it is one concrete essential thing we can do, from TAG perspective

... any feedback is useful, schedule: will deliver the next draft by the end
of this week

... will discuss the draft at the TAG F2F next week in Boston

... any feedback sent asap will likely make it into the TAG F2F meeting

... that's all folks

fjh: promoting best practices like this is a good idea

... any comments?

DKA: the doc will become a TAG finding

... or a TAG Note

... preference: TAG finding

... personal preference

<fjh> +1 to promoting data minimization within W3C and broader community

DKA: would like it to be a checklist to check against

fjh: I think creating something around data minimization is useful, but
creating a bigger framework would easily get complex

DKA: agreed, will start small and let it grow organically

<Zakim> darobin, you wanted to explain things a bit

DKA: diff TAG Note TAG Finding

... I think it could be said that TAG Finding represents something that's part
of the Web Arch

... more substantial than TAG Notes

... like WG Notes

... TAG FIndings are not RECs

Dom: one of the open questions for me is, which APIs would be affected by this

... would this apply to Geoloc WG deliverables

... data from sensors vs. user data

DKA: cannot diff between data from sensors v. private data

<fjh> reminder of fingerprinting based on sensor and other information makes
most information private in that sense

DKA: any data that may interact with UAs

Dom: how this principle would apply to accel or battery, for example

DKA: accelerometererometer case: the app should only request info it needs

... the API should not return all the information it has

<dom> [Device Orientation spec][28]

DKA: could be sensitive info , e.g. your accelerating might imply you are in a
train

... also data related to health info is very sensitive

<fjh> The major issue is combining information, e.g. sensor information along
with other information, impact on insurance etc

DKA: e.g. blood pressure sensors

<darobin> [I think that the core issue is to think before you spec]

DKA: more and more sensitive sensors are added, so it is good to get these
principles nailed down soon

darobin: battery status obviously is not privacy sensitive, but each sensor
would need to be evaluated against these principles

... any other questions for Dan?

... should other WGs be informed of the work?

DKA: e.g. Geolocation WG has privacy on their radar

darobin: mention geopriv and Geoloc WG freaks out

DKA: thanks for your feedback DAP WG!

### Contacts

<fjh> Comments before Last Call, [http://lists.w3.org/Archives/Public/public-
device-apis/2011May/0061.html][29] (Suresh)

<dom> (my comment on using URLs for ContactField.value is still pending I
think too)

richt: Suresh's comments haven't yet been baked in, other comments are in

<fjh> suresh suggests propose to drop the fields 'revision', 'gender' and
'timezone'

darobin: going though fields to be removed, see the discussion on the ML

... Suresh feedback: normative language in non-normative section

<fjh> proposed RESOLUTION: remove fields revision, gender and timezone from
contact interface

richt: will fix

**RESOLUTION: remove fields revision, gender and timezone from contact
interface**

richt: much based on vCard and PoCo, not so for CAB

<fjh> an informative reference is not an endorsement

<richt> to be clear, it's not a place to endorse other specifications.

darobin: PoCo needs to be in there, some fields reference it

fjh: having a reference is not an endorsement, harmless to have extra
references

<darobin> "All properties included in this interface have a corresponding

<darobin> definition in [POCO-SCHEMA], [IETF vCard], and [OMA CAB], thereby

<darobin> allowing the API to be supported across implementations supporting
these

<darobin> various contact formats."

Dom: reference needs to be bound to the actual text to be meaninful in the
context of a spec

<richt> will add Suresh's proposed text to the spec

darobin: Suresh's feedback processed

<richt> will drop updatedSince as agreed on mailing list.

<dom> ContactField.value as URLs?

Dom: value props on contact fields should be URLs instead of free-form
DOMString

... UA has to normalize the data

richt: would like to keep it as a DOMString, based on implementation
experiences so far

dom: having a field which may be free-form or an URL does not help IOP

<dom> dom: maybe we should have both .url and .value properties

darobin: looking at the tel: URI scheme

... to find out if it could work

<darobin> 1-800-HELLO

darobin: e.g. people who might enter phone numbers like above

dom: a picture can be either an URL reference or a base64-encoded data: URI

... if you *can* use URLs then you do use them

darobin: saving back to vCard?

... how does that work out?

dom: we don't have functions for creating contacts

darobin: there's no spec to reference for normalization

<darobin> uri = tel:1234;phone-context=munich.example.com

dom: this is a case we need implementors' feedback

... but this would be the Right Thing to do

<darobin> [are we turning email into mailto: as well?]

richt: personal opinion is this may add too much burden on implementers

... and complexity

... saving back case is an issue too

<darobin> [I see the value in having URIs handy, but it seems like convenience
that can be done in script and could be added transparently in v2]

richt: cannot put restrictions on the fields

... at this stage the non-URL way is preferred

dom: picture field can take an URL of the pic, or a base64'd version of it as
a data: URI

darobin: I'm fine with pictures

<darobin> current = "a URL to an image resource or base64 encoded string of
the image data."

richt: for pictures makes sense, absolutely

<dom> emails?

<darobin> new = "a URL to an image resource which may be a data: URL."

richt: need to handle this on case by case basis

<dom> and urls?

richt: but for tel it is harder

dom: not sure the proposed new URL JS object is doing normalization as
discussed above

richt: two ways: keep DOMString

... base the field on URL, which enforces URL behaviour

<richt> we can base the field on a URL constructor or enforce it on
DOMStrings. Both have different implications.

<dom> [feedback on contactfield as urls][30]

darobin: return this to the list

... no decision time now it seems

<dom> I was about to say: we're already relying on HTML5, Web IDL, which have
schedule problems of their own

<darobin> Agreed upon = 1) dropping gender, timezone, revision; 2) AppB all
informative; 3) add Suresh's sentence with OMA CAB; 4) remove updatedSince

richt: pending for a proposal for backwards compatibility?

... delay publishing?

darobin: the URL "spec" is not scheduled for publishing?

<dom> **ACTION:** Dom to figure status of URL object in JavaScript in Web Apps
[recorded in [http://www.w3.org/2011/06/01-dap-minutes.html#action01][31]]

<trackbot> Created ACTION-402 - Figure status of URL object in JavaScript in
Web Apps [on Dominique Hazaël-Massieux - due 2011-06-08].

darobin: thought WebApps wanted to take it but they couldn't (too many
deliverables already)

... TODOs: resolve URL thing, once done LC ready

richt: good for me

<richt> :)

<darobin> coordination email to Geo: [http://lists.w3.org/Archives/Public
/public-device-apis/2011May/0052.html][32]

darobin: not a blocker for LC

### Battery Status

<fjh> Editors draft updated, [http://lists.w3.org/Archives/Public/public-
device-apis/2011May/0057.html][33] (Anssi)

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0058.html][34]

<darobin> AnssiK: I have baked in all the changes

[http://lists.w3.org/Archives/Public/public-device-apis/2011May/0057.html][33]

<darobin> AnssiK: if you read this and dislike something, please simply send
me email

[http://lists.w3.org/Archives/Public/public-device-apis/2011May/0058.html][34]

<darobin> robin: new WD?

<darobin> AnssiK: agreed

<fjh> +1 to updated wd

<wonsuk> +1 for republish updated wd

<dom> ISSUE: Should (some of the) ContactField objects use URLs rather than
free-form strings?

<trackbot> Created ISSUE-111 - Should (some of the) ContactField objects use
URLs rather than free-form strings? ; please complete additional details at
[http://www.w3.org/2009/dap/track/issues/111/edit][35] .

<darobin> AnssiK: need to define how events are triggered in such a way that
they are testable; express [onbatterystatus event handler] in IDL; and define
"immediately" properly

**RESOLUTION: New WD heartbeat for Battery, and start preparing for LC
afterwards**

<darobin> **ACTION:** Robin to publish Battery heartbeat [recorded in
[http://www.w3.org/2011/06/01-dap-minutes.html#action02][36]]

<trackbot> Created ACTION-403 - Publish Battery heartbeat [on Robin Berjon -
due 2011-06-08].

[http://dev.w3.org/2009/dap/system-info/battery-status.html][37]

there's the latest ED

### Network Information

darobin: we could publish it right away

... would like people to take a look at it and send their +1s

<dom> +1 on publishing

darobin: if no issues, we'll go to FPWD

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0066.html][38]

<wonsuk> +1 to publish

dom: only issue, privacy sensitive network name

<fjh> No SSID

darobin: should we keep it or remove it?

<fjh> +1 to Dom, removing the privacy sensitive item

dom: prefer to remove networkName

<darobin> **ACTION:** Robin to remove networkName from Netinfo [recorded in
[http://www.w3.org/2011/06/01-dap-minutes.html#action03][39]]

<trackbot> Created ACTION-404 - Remove networkName from Netinfo [on Robin
Berjon - due 2011-06-08].

darobin: happy to remove it

<darobin> **ACTION:** Robin to move NetInfo to FPWD [recorded in
[http://www.w3.org/2011/06/01-dap-minutes.html#action04][40]]

<trackbot> Created ACTION-405 - Move NetInfo to FPWD [on Robin Berjon - due
2011-06-08].

### Feature Request Access Containers

<darobin> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0069.html][3]

darobin: heads up

... no feedback so far

<fjh> **ACTION:** fjh to review feature request access containers [recorded in
[http://www.w3.org/2011/06/01-dap-minutes.html#action05][41]]

<trackbot> Created ACTION-406 - Review feature request access containers [on
Frederick Hirsch - due 2011-06-08].

AnssiK: any discussion on moz labs?

<darobin> [http://lists.w3.org/Archives/Public/public-web-
security/2011May/0029.html][42]

darobin: not much in public, some private

... also discussed in web security

### HTML Media Capture

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0064.html][43] (Dom)

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0065.html][44] (Wonsuk)

darobin: discussed in HTML WG

... also feedback / questions from Wonsuk

Wonsuk: the scope of the capture would need to be clarified

... will come back later

### Other

darobin: any other specs?

### Adjourn

<darobin> RRSAgent: stop

## Summary of Action Items

**[NEW]** **ACTION:** Dom to figure status of URL object in JavaScript in Web
Apps [recorded in [http://www.w3.org/2011/06/01-dap-
minutes.html#action01][31]]

**[NEW]** **ACTION:** fjh to review feature request access containers
[recorded in [http://www.w3.org/2011/06/01-dap-minutes.html#action05][41]]

**[NEW]** **ACTION:** Robin to move NetInfo to FPWD [recorded in
[http://www.w3.org/2011/06/01-dap-minutes.html#action04][40]]

**[NEW]** **ACTION:** Robin to publish Battery heartbeat [recorded in
[http://www.w3.org/2011/06/01-dap-minutes.html#action02][36]]

**[NEW]** **ACTION:** Robin to remove networkName from Netinfo [recorded in
[http://www.w3.org/2011/06/01-dap-minutes.html#action03][39]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][45] version 1.135 ([CVS
log][46])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0069.html

   [4]: http://www.w3.org/2011/06/01-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #item10

   [16]: #item11

   [17]: #ActionSummary

   [18]: http://lists.w3.org/Archives/Member/member-device-
apis/2011Apr/0000.html

   [19]: http://www.w3.org/2002/09/wbs/43696/paris-2011/

   [20]: http://www.w3.org/2010/11/DeviceAPICharter.html

   [21]: http://lists.w3.org/Archives/Member/w3c-ac-
members/2011AprJun/0041.html

   [22]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0059.html

   [23]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0055.html

   [24]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/att-0048/minutes-2011-05-25.html

   [25]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0004.html

   [26]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0070.html

   [27]: http://www.w3.org/2001/tag/doc/APIMinimization.html

   [28]: http://dev.w3.org/geo/api/spec-source-orientation.html

   [29]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0061.html

   [30]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0045.html

   [31]: http://www.w3.org/2011/06/01-dap-minutes.html#action01

   [32]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0052.html

   [33]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0057.html

   [34]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0058.html

   [35]: http://www.w3.org/2009/dap/track/issues/111/edit

   [36]: http://www.w3.org/2011/06/01-dap-minutes.html#action02

   [37]: http://dev.w3.org/2009/dap/system-info/battery-status.html

   [38]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0066.html

   [39]: http://www.w3.org/2011/06/01-dap-minutes.html#action03

   [40]: http://www.w3.org/2011/06/01-dap-minutes.html#action04

   [41]: http://www.w3.org/2011/06/01-dap-minutes.html#action05

   [42]: http://lists.w3.org/Archives/Public/public-web-
security/2011May/0029.html

   [43]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0064.html

   [44]: http://lists.w3.org/Archives/Public/public-device-
apis/2011May/0065.html

   [45]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [46]: http://dev.w3.org/cvsweb/2002/scribe/