<trackbot> Date: 29 May 2014

<christine> Hi all. We'll start in a few minutes.

<christine> Thank you fjh

<christine> Giri, are you on the call?

<gmandyam> Yes I am

<christine> 1. Welcome and introductions 2. Geolocation WG 3. IndieUI WG 4. Privacy guidance and process documents 5. TPAC session 6. AOB

<yrlesru> zakim this is aaaa

<janina> Hi, I'm Janina Sajka, Chair of IndieUI (and also PF in W3C-WAI)

<JoeHallCDT> Joe Hall here, chief technologist at the Center for Democracy and Technology, a global online digital civil liberties organization

<MichaelC> Michael Cooper, staff contact to IndieUI WG

<gmandyam> Giri Mandyam, Qualcomm Innovation Center - joining the PING call to go over Geolocation WG

<npdoty> scribenick: npdoty

<tara> Tara Whalen, co-chair of PING, Privacy Engineer at Apple.

<fjh> Frederick Hirsch, Nokia, Chair DAP

<scribe> scribenick: JoeHallCDT

<tara> Thanks!

<Ryladog> Hi, I am Katie Haritos-Shea on IndieUI

<scribe> done

<christine> Agenda item 2 - Geolocation WG

<christine> Giri, we cannot understand you

<christine> Thanks, better

<tara> Much better, thanks.

discussing slide 2

<terri> Terri Oda, Security Researcher at Intel Open Source Technology Center

Giri: geoloc WG one of the first device API WGs

<christine> slides - http://lists.w3.org/Archives/Public/public-privacy/2014AprJun/att-0012/Geolocation_WG_Status_for_PING_May_29_2014.pdf

… specifically for mobile devices in mind

… level 1 spec is the geoloc api

… other level is device orientation

… gyroscope, when the device is in motion, direction it's moving in cartesian coords

… both apis proved to be very popular

… have been interop. issues but lots of vendor take-up

… under the previous charter, attempt for level 2 api

… main feature reverse geocoding… lat/lon of address

… not developer interest

… reverse address lookup feature was shelved before last call

… Qualcomm Innov. Cntr. does a lot of the mobile chip geoloc stuff

… certainly are privacy concerns

… safety issue, e.g., children exposing their home address

… legal issue, govt. tracking location

… not just a US issue given legal developments, but an issue in repressive nations

… recognized problem with the limited ability for users to control geoloc information through browser api

… users may not have a clue which sites they've given long-term access to geoloc. API

it's also an issue in WebRTC with permissions I believe

<npdoty> +1, not unique to Geolocation! persistence and revocation of permissions is a challenge

that was just me, not as scribe

… doesn't seem like the w3c has a uniform answer across WGs for this

… questions?

… none.

… slide 4 (slides are not numbered)

<jcraig> Slide #5 content:

<jcraig> New Geolocation Working Group Charter

… slide 5, "New Geoloc WG Charter"

<jcraig> Two main work items

<jcraig> – Adding geofencing to Geolocation API

<jcraig> • Leverage HW-based geofencing (as opposed to JS- based geofencing, which is possible with existing API)

<jcraig> – Cleaning up DeviceOrientation specification

<jcraig> • First version of spec resulted in poor interoperability

<jcraig> between different browser implementations

… Qualcomm has impliemented low-power geofencing

<jcraig> • In addition, development of use cases and requirements for indoor location extensions to API

<jcraig> Geofencing: Sample Use Cases

<jcraig> • Alerts when points of interest are in the user's vicinity

<jcraig> • Asset tracking

<jcraig> • Mobile marketing

<jcraig> – Advertisements related to geographical context

<jcraig> (That's actually Slides #5 and #6)

… there were problems with browser implementations of DeviceOrientation

… want to extend to indoor location extensions

q

… this can specialize information to a specific location in a building (floors, etc.)

… didn't want this to be explicit in the charter

… issues with multiplatform support for that

… geofencing: alerts when points of interest are near

… asset tracking: where is your stuff?

… mobile marketing… ads based on geography and presence

… slide 7: references on identified issues wrt privacy in existing API

<npdoty> JoeHallCDT: what is the technology used to do indoor location? beacons, access points, etc.?

<jcraig> BLE: Bluetooth Low Energy

<npdoty> giri: depends on the technology, we do use bluetooth beacons

… q: how does the indoor loc mojo work?

… wifi AP analytics, also beacons can be used

npdoty: follow up about the address thing

<Zakim> npdoty, you wanted to ask about civic address

… remember a petition to drop a v2, reverse geocoding

<christine> (Has the sound dropped, or aonly for me?)

… are there opportunities to provide less precise information with less UI stuff?

only for you CR

<Hannes_Tschofenig> I hear the sound quite well

<christine> Now okay

Giri: there is a flag, when set to false, allows the API to work on crude location

<npdoty> enableHighAccuracy flag

… might be difficult to get into a mobile browser

… as to second part of the question, have thought about it as a performance issue.

<Zakim> jcraig, you wanted to ask about exposing geoloc justification to users

<Hannes_Tschofenig> I have a question as well about the relationship to the work in the IETF.

jcraig: there is a related feature missing from the geoloc api

… i.e., an informal justification to the user as to why and app/site wants geoloc

… it is not always entirely obvious why a thing wants access to geoloc

<Hannes_Tschofenig> +1 That's sounds like a useful feature to me!

… this could be very useful

<npdoty> +1, I raised that back during v1

<Hannes_Tschofenig> I bet that they do not add such functionality

Giri: we reference a report from Berkeley that calls out this as a shortcoming

… how do you deliver this in a generic cross-WG manner

… e.g., WebRTC with browser-to-browser comms.

<Hannes_Tschofenig> I think that this is called "the race to the bottom".

<npdoty> the pushback heard then (and heard generally) is that the notification string could be fraudulent or misleading

… how do these video and audio streams stay with an intended recipient

or overloaded with legalese for secondary uses

<npdoty> I totally agree it would be good to give general guidance, since every WG is facing that question

jcraig: this could be optional

… some websites would like to use it.

gmandyam: good advice

Hannes_Tschofenig: some of this is very similar to what we've standardized at IETF

… e.g. relative location is useful in a building

… also looked at privacy protections, wondering if you've looked at that

<npdoty> yeah, more precise indoor location might be a good reason to look at IETF's pidlo location object, as opposed to just a set of address fields

gmandyam: We've looked at the GeoPriv object… we're part of (some industry group Joe hasn't heard of)

<npdoty> http://www.in-location-alliance.com/en/about

… we have to in some sense get certain OS support to extend these features into the browser

… if we can't get two browsers to do something, it's difficult to justify work to do this

Christine: thank you very much, excellent intro to the re-chartered WG

… please keep us apraised of what you're doing

<npdoty> +1, thanks gmandyam!

IndieUI

<jcraig> Janina

<gmandyam> Thanks to PING for inviting me. Thanks for all the good questions. I unfortunately I have sign off now. - Giri

<christine> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html

janina: IndueUI WG is looking for advice from PING

… servers can do a better job for tailoring content to users if users can better specify something

<christine> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#privacy-model

… the user is communicating preferences and this effort would tailor content to the user according to those prefs

… discloses possibly who this is and their preferences

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#privacy-model

… some of these settings are available… but not in a standard way

… caption styling is a big use case

… this spec has a justification string (like that just discussed for Geoloc)

… optional in some cases, required in some high-security preferences

… media settings, like closed-caption styling, are probably not high-security preferences

… high-security preferences are ones where a user may want to trust certain sites with that info. and not others

<npdoty> is curious about the accessibility restrictions for Google Docs, though I'll look into that offline

… we aim to publish first draft of user preferences doc in late June

ack

<Zakim> JoeHallCDT, you wanted to ask about high-security preferences

<npdoty> I think the idea was that screenreader-in-use would likely to be higher privacy because it wouldn't generally needed and might be very sensitive

npdoty: some things, captions, are things that can be done on the client side

… the server may not need to participate in this

… have we thought about which of these cases need to have the server knowing prefs?

jcraig: all is happening on client-side, so up to web applications

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#userMediaSettings

<npdoty> (was unprecise in describing "server" when web app JavaScript is also a case)

<jcraig> 5.3.1 Key: subtitles

<jcraig> Web authors using a native video player should allow subtitles to be displayed natively. Web authors using a custom subtitle view should display the custom-rendered subtitles based on this setting.

… the use case npdoty talks about is only when you use an HTML5 <video> which is not always possible

<npdoty> another reason to switch to HTML5 video!

Christine: want to hand it over to james to talk about how he's dealt with tracking and fingerprinting

<npdoty> I guess I think we should be careful about what a11y features we add for native/plugins, rather than noting those as bugs with the HTML features

jcraig: please read Section 4 of the draft linked about about the privacy model

… we don't restrict access to things that are already figure-out-able

… we've talked about solutions for more high-security prefs

… https, restrictions, etc.

… this is why we want to put certain things, like assistive tech, behind a prompt

<Zakim> jcraig, you wanted to discuss fingerprinting

npdoty: we are trying to get common guidance on fingerprinting

… it is good to consider what things are likely to be useful for fingerprinting

… rather than (something I missed)

<npdoty> don't particularly see HTTPS as more important than usual here

<npdoty> and observability can be useful regarding fingerprinting as well

<npdoty> and we should follow up over email as well :)

Christine: thanks them for being so careful about privacy

Katie: are you hoping that any interaction that involves fingerprinting should be behind https?

<npdoty> I don't think FPWD needs to wait on our group; a first draft is a great thing to get out there, and can get good feedback (including on privacy)

me: don't get it, https doesn't protect things from the other end!

… the thinking behind https, just in case the web app wants to store some prefs on the server, they'd have to send via https

… barrier to entry to using https

… could be a barrier to uptake of the API

<npdoty> hopes blog sites will be using HTTPS, and that it'll be easy for them to do so

yes!

Christine: TPAC

TPAC

… how can we useful use the time we will have at TPAC?

<jcraig> Thank you all. Dropping off the call. I'll remain on IRC.

Guidance

Privacy Considerations Document

Christine: npdoty has sent comments, Joe plans to, Christine is in planning stages to plan to

… let's have an informal task force to work on this document?

… suggesting hannes, joe, nick, and Christine

love it. agreed.

hannes: read through Nick's review...

… can definitely make some changes based on that

… put it in w3c github, maybe npdoty can do that

<npdoty> ACTION: doty to move Privacy Cons. doc to w3c github organization [recorded in http://www.w3.org/2014/05/29-privacy-minutes.html#action01]

<trackbot> Created ACTION-6 - Move privacy cons. doc to w3c github organization [on Nick Doty - due 2014-06-05].

Christine: pretty please, get that going

<npdoty> Nick has taken an action item. :)

hannes: there are still a few process-related items in that document

… want to consolidate and pull that out

<npdoty> yrlesru/Frank has been handling process stuff in the Specification Privacy Assessment document

yrleru: also, we had an informal meeting about this in March at CDT, Joe sent an email

… we identified some deep issues: if you do privacy considerations after chartering, hard to get that back in

… need to think about potential footprint of privacy and security in chartering

me: this speaks to more changes across w3c process than simply advice to WGs and chairs

… not sure how to process that

… Joe may have some good idea

<npdoty> hmm... that was earlier than I was imagining, but I'd be happy to discuss how we can do better at noting things during charter process

yes, this is part of the conversation and I hope part of this nascent task force

<yrlesru> Sure!

they can't be the same thing

?

<npdoty> are people going to be in DC in June for PLSC?

I am!

<tara> I am !

<npdoty> I am!

<npdoty> http://www.w3.org/blog/TAG/2014/05/22/capability-urls-feedback/

npdoty: three things PING might want to be aware of:

<npdoty> http://www.w3.org/TR/capability-urls/

… 1) capability URLs, the TAG has been working on this document and best practices… very much a privacy use case

… asking for feedback

… 2) Do Not Track work is in Last Call… part of it, at least

<npdoty> http://www.w3.org/TR/tracking-dnt/

… TPE is in last call (this is the technical signal) June 18

… 3) Web Security Group is looking into some process for reviews

<wseltzer> Please review; http://www.w3.org/Security/wiki/IG/W3C_spec_review

neat!

<wseltzer> s/Please review:/Web Security IG is looking for review of guidelines,/

Christine: how is 26 June?

wfm

<tara> Looks good so far...

<npdoty> the Web Security Interest Group review process might be particularly relevant if we want to coordinate with a privacy review, which I think is generally a good idea

ok, we lost Christine

<yrlesru> Bye folks!

woo!

<npdoty> [adjourned]

<npdoty> trackbot, end meeting

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/spec shelved/reverse address lookup feature was shelved/
Succeeded: s/us it/use it/
FAILED: s/Please review:/Web Security IG is looking for review of guidelines,/
Found ScribeNick: npdoty
Found ScribeNick: JoeHallCDT
Inferring Scribes: npdoty, JoeHallCDT
Scribes: npdoty, JoeHallCDT
ScribeNicks: npdoty, JoeHallCDT
Default Present: tara, hober, Katie_Haritos-Shea, gmandyam, +1.214.566.aaaa, WSeltzer, [CDT], +44.793.550.aabb, npdoty, terri, Michael_Cooper_(IndieUI), fjh, jcraig, janina, christine, +1.214.566.aacc
Present: tara hober Katie_Haritos-Shea gmandyam +1.214.566.aaaa WSeltzer [CDT] +44.793.550.aabb npdoty terri Michael_Cooper_(IndieUI) fjh jcraig janina christine +1.214.566.aacc Frederick_Hirsch Hannes_Tschofenig yrlesru

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 29 May 2014
Guessing minutes URL: http://www.w3.org/2014/05/29-privacy-minutes.html
People with action items: doty

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.