Privacy Interest Group Teleconference -- 14 May 2015

<trackbot> Date: 14 May 2015

yo yo yo

zakim i am aacc

Zakim I am aacc

<Ian> Nick..let me know when to join

Im 202.407.aacc

don't know how to do that

thanks!

happy to scribe

<npdoty> scribenick: JoeHallCDT

certainly!

<tara> Much thanks!

subresource integrity

<bhill2> http://w3c.github.io/webappsec/specs/subresourceintegrity/

Brad Hill is here to talk about SRI

Christine: brad will give an introduction and talk about the four areas where they'd like feedback

… it's a great, readable spec

bhill2: SRI spec is relatively straightforward

… today would consider this to be the first step of a journey

… we want to be able to integrity tag resources on the web

… e.g., anchor links for downloads

… particularly interested in dynamic resources, CSS, JS

… we've seen some CDN compromises, which allows compromise of all the other applications mediated by the CDNs

… provides control around single points of failure

… allows adding an integrity attribute to a <link> or <source> tage

… UAs check that resources against that hash before including it in the DOM

… it's an experiment, becasue we're going to have to see how this works, how useful vs. how big of a burden

… also introduces some brittleness… a resource can evolve over time and if that goes out of sync with tag, can break things

… we expect this to be especially useful with libraries where the tag would be stable over a version of the library

… we fully plan this to be used in HTTP

… not protection from network attackers

… [lost the last bit]

… does not change the state of mixed content or privledged features

… doesn't change UA determinations that somethings is mixed content

… we want to maintain privacy guarantees of HTTPS

… not interest in a third UI state of integrity without privacy

… PING can help in a few ways

… concerned about cross-origin leakage of information

… if you know the enumeration of [] states, you could create tags for each state and be able to tell if someone is logged into a privilged context

<bhill2> http://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligible-for-integrity-validation

… we require resources that are integrity-checked are same origin or using CORS

… additionally, we refuse to allow integrity-verification of documents with a refresh header [did I get that right?]

… may be other paths to leakage that we have missed

… certainly timing channels that are present

Christine: anything else to add?

bhill2: we're interested in an evaluation of the privacy properties of this spec, thanks!

npdoty: curious about the last validation check you talked about...

… check for certain headers to prevent the case where some script can check hashes and see if there is a failure to check for log in

… does this typically cover all the logged in resources cases?

bhill2: that's correct, but for non-same origin resources have to use CORS mode

… not trying to eliminate all side channels for detecting user logged in

… we just don't want to introduce new side channels

… SRI provides syntatic sugar around verifyuing that content before DOM load

<npdoty> JoeHallCDT: why sha256 as the hashing algorithm and not 512?

bhill2: examples use Sha256 because it's compact for the spec

… secion 3.2 mandate that you support sha256, sha384, sha512

… UA will select the set of algos that are the strongest and check the hashes against those

Christine: any more Qs?

… thanks a ton bhill2

… you want input before 26 May

bhill2: that would be great

<npdoty> added to our wiki list

… let's get comments we can get to them before that

<npdoty> if someone wants to shepherd or gather the comments, that'd be great

<bhill2> thank you all for your time and consideration!

web payments

Ian: on the w3c staff, as of Feb. head of web payments activity

<Ian> http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/

… sent a note to a few groups in the WPIG charter

… want to tell you about the document and the broader plans we ahve

… launched last Oct

… working on a timeline to have a WG started before TPAC

… one or more charters proposed to members by August

… in June's meeting, we'll have to reach a decision on scope of work

… we are going about this by publishing first use cases

… goal over all is to make web payments more secure, and sharing only information necessary to conduct a transaction

… document is intended to be approachable and describe what we have in mind for any payer to payee flow in a transaction

… from when you decide to make the purchase, to how the guts work, to transaction completion

… in Section 6, we have very small statements of use cases that we'd like a web payments architecture to address

… you can read the little scenarios and think about whether the privacy considerations are sufficient

… we're early enough where that is a valuable piece of work where we could use PINGs help

… at the next stage when we want to describe the specific functionality, there will be more privacy considerations still

… but we haven't published that yet

christine: could you take one of the use cases that has privacy considerations and walk us through it?

<npdoty> cool, I'm not sure we've looked at a separate use cases document before, or a document written with this annotated style

ian: sure, we wrestled with this document quite a bit...

… btw, I'm new to payments world, and we worked hard to eliminate assumptions specific to the payments world

… makes the use cases document easier to read and more modular

… one example

… Section 6.1.1

… doc is organized as a flow for a common payment

… first phase is "discovery of offer"

… point of sale kiosk

… Corey shopping for groceries as ChowMart, ...

… privacy consideration is giving the user control over how much information they want to share with merchant

… classic case of merchant that may want to exchange discount for information about purchasing habits

… there is a robust desire on the merchant side to have this kind of purchase history

… we aren't proposing this, but we expect to work on it in a WG

<npdoty> just calling out for the next level down, for the implementation in later spec work -- interesting

… there's one further own about pre-authorization

… there are cases wehre the best UI is no UI, can be accomplished by pre-auth

… use the use case of a smart vehicle communicating with a petrol pump

… one way to think about this document is to tee up privacy considerations for later work

<Ian> (Best way to send comments is to -> public-webpayments-comments@w3.org )

<Ian> (Also happy to chat about them here)

<npdoty> JoeHallCDT: cases of collapse between real world and virtual world identifiers and metaphors

<npdoty> ... like loyalty cards vs. branded credit cards

<npdoty> gnorcie: loyalty card, branded credit card, rewards-based credit card -- the meaning of "loyalty card" used differently in different contexts in the document

<npdoty> Ian: +1, thanks, good to note

<npdoty> Ian: discussion in webappsec about same-origin policy

<npdoty> ... browser vendors in the group; know it will be important to work through with the use cases

<npdoty> JoeHallCDT: a couple cases where the payer seems to be transmitting all of their payment options, rather than the merchant providing the range and the user selecting one

<npdoty> ... client-side verification or sending attestations, in a zero-knowledge client-side approach

<npdoty> Ian: does there need to be a negotiation at all between different groups of payment instruments?

<npdoty> ... hearing that people have use cases for verification on both the server and the client side

<npdoty> ... credentials vs. assertions, what are the credentials requirements? credentials community group has a general purposes infrastructure for attestations

<npdoty> scribenick: JoeHallCDT

<Ian> +1 to making comments!

christine: bit thanks to Greg, Joe, Kaeping for providing comments

<npdoty> yes, on the wiki

<tara> Yes, many thanks!

… npdoty can add this to the wiki: please volunteer to take a look and provide comments

… this is a great high-level way to provide input with use cases

Ian: interested as well from an editorial perspective if the structure we have lends itself to good review

… if you like this, and find it's easy to jot down notes, let's propogate that

<npdoty> JoeHallCDT: really like this style. earliest we can typically give input is the charter, but starting with use cases ahead of time is a good way to incorporate privacy considerations as early as possible

<Ryladog> +1 to that

<Ian> (The next level down is challenging for us....how to extract requirements and how to organize necessary capabilities....stay tuned!)

<Ian> (Cheers!)

media capture

christine: next item, renewed request on privacy and security considerations of MEdia Capture and Streams

<christine> http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#privacy-and-security-considerations

<tara> Katie.

<wseltzer> http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/

http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/

<npdoty> Katie's email from October: https://lists.w3.org/Archives/Public/public-privacy/2014OctDec/0004.html

last call working draft

I was supposed to help with that. very sorry. :/

christine: wendy?

… sent it back to PING's attention because it is in LC

… it could be valuable to look back at it and consider if they've incorporated our feedback

… thanks mucho to Katie for taking a look at that

<npdoty> just to confirm: were these sent to the group already? did the group respond to them?

… we like specs with privacy and security considerations to start

… we should look again, as getUserMedia() is requesting pretty senstitve access to mic and cam

Katie: would love someone else to look at this

christine: Joe?

<npdoty> I think we're on a tight timeline. their Last Call comments is requested by tomorrow

wendy: +1 that we have an obligation to the web to look for privacy and security considerations

… if something has gotten to last call or wide review and is still missing critical elements

… we should be ready to point those out

… still better to capture something in LC (far from a W3C Rec), than to look back on it

me: can't turn it around by tomorrow (when LC comments are due)

wseltzer: process puts special obligations on specs to address comments

… groups are required to respond to reasonably source comments

… so it will still be valuable later

… important spec used by WebRTC, big push for real-time p2p comms

<scribe> … new features are already present in many browsers that are relying on this

… while still in early phases of feature imp., still valuable and important for experts to look at it

Kate: can look by tomorrow to see if my comments were addressed

… had some questions that not sure if they're answered

… would like to get more eyeballs

chrisine: most generous to do that in such a short timeframe, Katie!

… for our call next month, let's put this on the agenda, with the expectation that several people will have looked at it, prepared in advance

… so we can discuss it, decide what we want to do as PING

… others please put your hand up on the wiki

… any thing else on Media streams?

… getting close to time

christine: model for tabular data and metadata on the web

… has anyone had a look at these drafts?

… anyone involved in this sort of work?

… move to the agenda for the next call

… will do some research on how best to deal with privacy requests on several of their documents

… next item: TAG privacy and security review questionaire

npdoty: we [royal we?] met with the TAG in San Francisco where this was discussed

… TAG has been very interested in privacy and security process

… invited npdoty, mikewest, tantek to discuss the questionairre

… they've take it over and put it in their repo

… want it to be a more established state so folks can use it

<npdoty> https://w3ctag.github.io/security-questionnaire/

christine: have a question: would our POC be mnot?

npdoty: not sure there is a single POC… Dan Applequist, Mark and Yan Zhu

was this your questionairre or from scratch?

npdoty: mikewest started this internal to google, from scratch

… part of our work is to merge in some of the questions we had from the wiki

<chaals> [Apologies, I have a conflict from now]

christine: TAG has an interest in this area would be great to combine PING and TAG forces to move this forward

<npdoty> it's also a questionnaire that I used as the basis for the app manifest review

… should move the privacy considerations document into this, fingerprinting doc, and possibly SPA

… we'll get in touch with the TAG to figure out a way to move forward

… we'll leave for the next call should sensors require privileged contexts?

Katie: are we expecting a PING meeting in TPAC in Japan?

Christine: yes, we are.

<tara> Yes she would!

… speaking for Tara, she'd apprecite input and help in organizing it

<tara> (appreciate help/input that is. :-)

… dates for next meeting?

<npdoty> June 11 or June 18 or June 25?

… likely the 18th or 25th

<npdoty> scheduling to be determined on the list

… will send out summary

bye!

<fjh> thanks

<npdoty> trackbot, end meeting

- DRAFT -

Privacy Interest Group Teleconference

14 May 2015

Attendees

Contents

subresource integrity

web payments

media capture

Summary of Action Items

Scribe.perl diagnostic output