Device APIs and Policy Working Group Teleconference -- 01 Jun 2011

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

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 (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

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]

<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

darobin: not a blocker for LC

Battery Status

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

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

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

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

<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

<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 .

<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]

<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

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

<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]

<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]

<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

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]

<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

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 (Dom)

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011May/0065.html (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

Device APIs and Policy Working Group Teleconference

01 Jun 2011

Attendees

Contents

Administrative

Welcome, agenda review, scribe selection, announcements

Minutes approval

TAG minimization draft