Privacy Interest Group Teleconference -- 30 Jan 2014

<trackbot> Date: 30 January 2014

<tara> Hi everyone. Waiting for a few more folks to join.

<scribe> scribenick: npdoty

<JoeHallCDT> alas, I cannot scribe today but promise next time

richt: Rich Tibbet from Opera, patches for Chromium/blink and work in standards, Network Services Discovery

<bblfish> hi

Network Service Discovery

<christine> http://www.w3.org/TR/discovery-api/

richt: at a high level, connecting to devices / services on your network
... UPNP/Zeroconf, which you may know as Bonjour
... these protocols expose endpoint urls that speak http
... tried to get to a point where a developer can request a well-known service type so they can communicate with services on different devices
... layered on top of HTTP, can use XHR
... 1.5 years in; lots of feedback from implementer mailing lists, like from Mozilla / Chromium
... some concerns about privacy and security, worry about exposing unsafe devices
... extremely wide range of different devices and services
... change volume on your speaker, but also can change configuration of your router
... in terms of security, added a requirement to the specification that services that want to be exposed, need to implement CORS
... expose HTTP headers that those services have been audited/cleared for sharing with web pages
... that's the main mechanism for security
... the other major part is how the user interacts

<Clarke> Clarke Stevens from CableLabs just joined. I'm on the phone too.

richt: a permissioning prompt where the user selects the services they want to share, like how we do geolocation
... a certain degree of privacy and security, but looking for more input
... any other ideas of what we can do, and an audit of how it works or whether anyone considers it unsafe
... happy to answer questions

http://www.w3.org/TR/discovery-api/

<christine> +q

christine: appreciate your taking the time. forgive my introductory questions
... permission prompt point -- what's the granularity or persistence of those permissions?

richt: have a prototype, but haven't actually built the UI; have some experience with WebRTC and Geolocation previously
... site requests a particular type of service, browser searches for a list of candidates, candidates are displayed to the user and can click share
... specification describes longevity, that permissions have to be asked again after next loading of a page

fjh: for CORS, how do you know which origin corresponds to what?

richt: look for the existence of CORS headers, looking for wildcard matching
... no particularly good way for CORS to specify a local IP address which you don't know ahead of time
... indicate to browsers in a general way that they're web-ready
... as a user you could whitelist certain device types in your browser
... in that case you could connect to legacy devices and services
... likely to be an advanced option for users
... or browsers could blacklist certain services, like routers, even if the user tries to whitelist them
... a remedy for browser-makers to ensure user security

fjh: how would you blacklist a router? what do you need to know?

richt: there are well-known service types (defined by upnp), well-known strings

<Zakim> npdoty, you wanted to ask about persistence and to ask if that's how CORS is intended

<richt> please refer to the editor's draft: https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html

<richt> The CORS mechanism has not yet been published in the TR version.

<fjh> npdoty: is asking for permissions repeatedly intended usage of CORS

<fjh> richt: this approach is necessary, e.g. don't want automatic connection after a delay, e.g. 30 days

<fjh> npdoty: another question, is this intended use of CORS header or are you just taking advantage of it

<yrlesru> zakim aabb is yrlesru

<fjh> richt: once have service endpoint URL it is a resource, so CORS is appropriate, browser enforces CORS mechanism

<fjh> … using as specified

<fjh> … but in discovery sending HTTP OPTIONS request, using response to see if CORS supported and has headers

<fjh> … not changing CORS

<fjh> … potential issue with CORS regarding limit of exposure to local IP addresses, using wildcards

<fjh> … when searching, knowing requesting web page and origin, check that in service responses so wildcard not needed always

<fjh> … but sub domains might be an issue (???)

<scribe> scribenick: npdoty

tara: any points that haven't been asked about yet?

richt: CORS, user-whitelisting or ua-blacklisting
... different ways we could approach this problem -- building on top of existing APIs like XHR and WebSockets
... powerful, but low-level
... right now talking XML, but could next be JSON or WebSocket -- not very specific to UPNP, for example

<fjh> npdoty: common issue is unique identifiers can be used to correlate activity or re-identify user in unexpected manner

<fjh> … is identifier being given to endpoint

<fjh> … can two web services correlate activity?

<fjh> richt: spec does not deal with this, open DAP issue

<fjh> … endpoint URL likely to have numeric component, exposing and leaking local IP configuration

<fjh> … this is a concern

<fjh> … discussing how to obfuscate local IP addresses, would appreciate PING feedback on this

<fjh> … might be also an issue in WebRTC?

<fjh> … probably not a good practice.

<fjh> … obfuscating may create issue with responses containing IP addresses for media resources etc, so some thought required

<fjh> … please give feedback on importance of issue and approaches

<fjh> npdoty: will think about it

<scribe> scribenick: npdoty

tara: may all need a bit more reflection over material from today

richt: we've concisely covered our issues. leaking IP address configuration is a key issue for feedback

<christine> +q

richt: editors' draft best for review (includes CORS)

https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html

<yrlesru> Would an alternative to persistent local IP address be capability for renewal of the identifier at user control?

richt: any improvements for user privacy or security would be great

fjh: what's the schedule for review?

richt: as long as it's not multiple months; blocker on implementation and want to calm concerns about security
... privacy and security review takes as long as it takes and implementation is blocked until it's finished

christine: the sooner the better but not overly demanding schedule
... mentioned discussions of IP address leakage and obfuscation within DAP group
... could you share the different possible mitigations?

<yrlesru> 2nd time to express my thoughts. Would an alternative to obfuscation of IP address be ability for user, on demand, to renew their identifier.

richt: can obfuscate the endpoint URL easily, like a transparent proxy; the hard part is intercepting and rewriting the HTTP responses
... any alternatives would be helpful

<fjh> thanks rich for an excellent overview

richt: thanks all for the discussion and ongoing review

<bblfish> hi

WebID

<christine> +q

<richt> thank you everyone.

<bblfish> np :-)

christine: question about group status.

<bblfish> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html

bblfish: was Incubator, now working as a Community Group

<fjh> is there a link for the CG, participants?

bblfish: would like to finish, publish specs hopefully by the summer

<richt> would like to bring https://2x.io/read/security-by-obscurity to the attention of this group. RE: exposing local IP addresses to web pages in WebRTC (as I mentioned earlier on this call).

<christine> Thanks for the clarification Nick

<christine> No more from me

bblfish: would like to push this up to the next stage, five years of work altogether
... two specifications and an ontology
... Web Identity and, separately, how do you communicate with WebID over TLS
... and then prototypes, for example, using access control for a wiki
... using Linked Data
... have added Privacy/Security Considerations sections to the two specs

<scribe> ... new since we last talked here

UNKNOWN_SPEAKER: looking for feedback on those sections
... authentication over TLS, rather frequently implemented/used in browsers

<Zakim> fjh, you wanted to ask about web id correlation

fjh: what the requirements are; is there an issue here of correlation which would need obfuscation

bblfish: WebID does make it easy to link profiles, it is meant for that specifically to support a decentralized Social Web
... can create p2p social networks over HTTP, reduces centralization which is advantageous, but leakage of links/URIs
... costs are weighed against the benefit of that decentralized social networking

<yrlesru> Was this the reference to use cases and requirements? , https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-ucr.html#maintaining-social-contact-information

bblfish: communicating over SSL can prevent eavesdropping

fjh: just important to make the tradeoff clear

tara: timeline?

<fjh> thanks for clarifying the potential tradeoff between decentralization and potential for Service provider (web application) correlation based on ids

bblfish: not a great hurry, but quick review of privacy and security sections would be helpful

documents in progress

tara: various documents in different stages of status
... fingerprinting?

<fjh> npdoty: regarding fingerprinting, made an update before the last call, had questions about feasibility of addressing the concern

<fjh> … have some ideas but have not had a chance to write up yet

<fjh> … would like some help with reviewing

<christine> Thank you fjh - that would be helpful

<scribe> scribenick: npdoty

<christine> yes, I realised that too late, sorry

tara: comments elicited for EME and getUserMedia

JoeHallCDT: I sent some notes late last year, a very well-considered document already
... lacked a more systematic way of doing a review in a reputable process

<christine> +q

JoeHallCDT: if we want to do privacy reviews in a more standardized way, happy to do that (have more help inside CDT now)

christine: pleased to hear your ability to participate

<bblfish> yrlesru, thanks for the pointer to the WebId use case ( catching up on IRC )

<yrlesru> ISO/IEC 29100:2011 Information technology -- Security techniques -- Privacy framework Is now publicly available at no cost at http://standards.iso.org/ittf/PubliclyAvailableStandards/c045123_ISO_IEC_29100_2011.zip

JoeHallCDT: hoping to have more chance to engage, that PING would be a good place to have those discussions

christine: current status on EME?

<yrlesru> If Nick Doty can note this in minutes. This standard provides a standard privacy framework (terminology, roles, responsibilities, principles, etc) for privacy that is aligned with proposed EU DP Regulation in many ways.

<christine> Thanks for the update re status on EME

JoeHallCDT: a lot of tension, html media group very interested in closing down issues but still quite a bit of principled concern
... also a separate alternative proposal in WHATWG
... need some guidance
... had already done a good job thinking about privacy, in the UA and in the CDMs

<yrlesru> Joe, I would be available for a workshop on the subject during week of CDT Gala and IAPP in DC.

JoeHallCDT: settle on a coordinated systematic way for doing a privacy review when someone comes up to PING
... can't wrap it up without knowing what the framework should be

<christine> +q

JoeHallCDT: is "already looks good" an appropriate response?

yrlesru: tried offline to start reviewing a number of specs
... a number of framework approaches you can take -- classically, look at the data flows from the applicable privacy principles
... or look at collection/storage/transfer/processing/
... Hannes had proposed an approach that was a standard list of principles and threats, a potential checklist
... 1) people come to us after the fact, a checkbox so that they can go to the next phase of implementation
... or 2) talk to people earlier during the design alternatives phase, where we think through systematically the different ways we could think through
... an ISO standard on privacy principles is now publicly available and may be useful

http://standards.iso.org/ittf/PubliclyAvailableStandards/c045123_ISO_IEC_29100_2011.zip

yrlesru: if we want to meet up in person around CDT event and try with a whiteboard, would work for me

JoeHallCDT: can talk offline; IETF is a potential conflict

tara: running out of time at this point, wrapping up comments

<christine> quick point Tara before you close

yrlesru: one problem that's come up: do we have a clear understanding of what the use cases are for an API?
... have seen that same problem crop up on other specs

<bblfish> cool please let me know what questions we need to look at, answer :-)

christine: really appreciate the enthusiasm to work out a structured way for PING to do privacy reviews
... a key goal is to develop guidance and to develop the system for reviews
... what we've been doing is having informal privacy reviews even while we're in process for developing guidance

next call -- March 13th?

(later than the first week of March, because of the IETF conflict)

<christine> I'll also suggest a PING meeting at IETF on the mailing list

<bblfish> thanks a lot

tara: thanks all

- DRAFT -

Privacy Interest Group Teleconference

30 Jan 2014

Attendees

Contents

Network Service Discovery

WebID

documents in progress

Summary of Action Items

Scribe.perl diagnostic output