See also: IRC log
<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
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
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
... 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
richt: editors' draft best for review (includes CORS)
<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
<richt> thank you everyone.
<bblfish> np :-)
christine: question about group status.
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
<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
tara: various documents in
different stages of status
<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
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
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
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
... 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
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/ndoty/npdoty/ Succeeded: s/alwasy/always/ Found ScribeNick: npdoty Found ScribeNick: npdoty Found ScribeNick: npdoty Found ScribeNick: npdoty Inferring Scribes: npdoty Default Present: npdoty, tara, richt, karima, christine, fjh, [CDT], Ashok_Malhotra, +1.469.242.aaaa, FrankDawson, bblfish, Clarke, +1.214.566.aabb, yrlesru Present: npdoty tara richt karima christine fjh [CDT] Ashok_Malhotra +1.469.242.aaaa FrankDawson bblfish Clarke +1.214.566.aabb yrlesru Frederick_Hirsch Clarke_Stevens Regrets: wseltzer Found Date: 30 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/30-privacy-minutes.html People with action items:[End of scribe.perl diagnostic output]