See also: IRC log
<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
<Ryladog> Hi, I am Katie Haritos-Shea on IndieUI
<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
… 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
… 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
… 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)
… 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!
<gmandyam> Thanks to PING for inviting me. Thanks for all the good questions. I unfortunately I have sign off now. - Giri
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
… 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
… 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
<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> 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
… 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.
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
they can't be the same thing
<npdoty> are people going to be in DC in June for PLSC?
<tara> I am !
<npdoty> I am!
npdoty: three things PING might want to be aware of:
… 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
… 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
<wseltzer> s/Please review:/Web Security IG is looking for review of guidelines,/
Christine: how is 26 June?
<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!
<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.[End of scribe.perl diagnostic output]