15:49:58 <RRSAgent> RRSAgent has joined #webappsec
15:49:58 <RRSAgent> logging to http://www.w3.org/2017/06/21-webappsec-irc
15:50:00 <trackbot> RRSAgent, make logs world
15:50:00 <Zakim> Zakim has joined #webappsec
15:50:02 <trackbot> Zakim, this will be WASWG
15:50:02 <Zakim> ok, trackbot
15:50:03 <trackbot> Meeting: Web Application Security Working Group Teleconference
15:50:03 <trackbot> Date: 21 June 2017
15:50:11 <wseltzer> regrets+ wseltzer
15:50:35 <wseltzer> regrets+ gmaone
15:53:17 <natasha> natasha has left #webappsec
15:56:32 <bhill2> bhill2 has joined #webappsec
15:56:42 <bhill2> trackbot, prepare conference
15:56:45 <trackbot> RRSAgent, make logs world
15:56:48 <trackbot> Zakim, this will be WASWG
15:56:48 <trackbot> Meeting: Web Application Security Working Group Teleconference
15:56:48 <trackbot> Date: 21 June 2017
15:56:48 <Zakim> ok, trackbot
15:57:42 <bhill2> test
15:58:10 <bhill2> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0024.html
15:59:51 <bhill2> present+
15:59:57 <bhill2> present+ Brad Hill
16:00:08 <bhill2> RRSAgent, begin logging
16:00:08 <RRSAgent> I'm logging. I don't understand 'begin logging', bhill2.  Try /msg RRSAgent help
16:00:23 <bhill2> lgtm, thanks @wseltzer
16:01:54 <dveditz> present+
16:02:29 <denis> denis has joined #webappsec
16:02:41 <mkwst> present+
16:03:13 <wseltzer> wseltzer has changed the topic to: Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0024.html
16:03:17 <denis> denis has left #webappsec
16:03:37 <bhill2> thanks wseltzer, still learning my new irc client and it didn't want to change topics
16:04:04 <JohnWilander> JohnWilander has joined #webappsec
16:04:12 <aj> aj has joined #webappsec
16:04:31 <bhill2> Prior minutes: https://www.w3.org/2011/webappsec/draft-minutes/2017-05-17-webappsec-minutes.html
16:04:52 <bhill2> hi, JohnWilander, will you be dialing in?
16:05:06 <JohnWilander> (I'm also on the call but I can't remember the cool way of telling you that here.)
16:05:17 <bhill2> present+ JohnWilander
16:05:52 <dveditz> what's the diff between that link and https://www.w3.org/2017/05/17-webappsec-minutes.html
16:07:25 <bhill2> TOPIC: minutes approval
16:07:28 <dveditz> Zakim, who is here
16:07:28 <Zakim> dveditz, you need to end that query with '?'
16:07:31 <dveditz> Zakim, who is here?
16:07:31 <Zakim> Present: bhill, Brad, Hill, dveditz, mkwst, JohnWilander
16:07:33 <Zakim> On IRC I see aj, JohnWilander, bhill2, Zakim, RRSAgent, timbl, MattN, Agent_Smith_BR, terri, crakrjak, dbaron, dveditz, jkt, timeless, battre, lfaraone, jww, mkwst, ojan,
16:07:33 <Zakim> ... slightlyoff, Josh_Soref, hadleybeeman, jyasskin, tobie, sangwhan, Domenic, jochen___, adrianba, wseltzer, mounir, Jb, jcj_moz, trackbot, gszathmari
16:07:42 <Ao> Ao has joined #webappsec
16:07:57 <bhill2> minutes approved by unanimous consent
16:08:00 <bhill2> TOPIC: agenda bashing
16:08:21 <ArturJanc> ArturJanc has joined #webappsec
16:08:47 <francois> francois has joined #webappsec
16:09:52 <bhill2> TOPIC: Signatures in SRI proposal
16:09:58 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0000.html
16:10:06 <mkwst> https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown
16:10:41 <bhill2> mkwst: hashes exist for SRI, often what you want
16:10:54 <bhill2> ... our experience at google has been that hashes are more difficult than expected to maintain
16:11:03 <bhill2> ... and use as a deployment mechansim for things that change often
16:11:27 <bhill2> ... signatures give a different set of related properties but can be much simpler to deploy
16:11:43 <bhill2> ... proposal in explainer document lays out a statement that signatures may be able to solve
16:12:04 <bhill2> ... create public/private keypair, public key in integrity attribute, signature over content in header
16:12:49 <bhill2> ... dev at dropbox is enthusiastic, rsleevi at google less so
16:13:11 <bhill2> ... my opinion is that it offers different things: allows validating trust vs. integrity
16:13:24 <bhill2> ... useful for stuff that gets versioned
16:13:58 <bhill2> dveditz: moz folks who've looked aren't keen, worried it will be slow to use
16:14:09 <bhill2> ... not sure how it is an advantage over just using tls on the connection
16:14:49 <bhill2> mkwst: with dynamic signing this is not useful, scenarios I am interested in are all offline signing as part of a deployment process
16:14:57 <bhill2> ... for things like CDNs
16:15:31 <mkwst> bhill2: <facebook>This seems useful. Roundtrip latency means that the signing key for certs is out as close to customers as possible.
16:15:42 <mkwst> ... CDNs might not be as trustworthy as you might like.
16:15:46 <mkwst> ... Offline signing is useful.
16:16:02 <jeffh> jeffh has joined #webappsec
16:16:08 <mkwst> ???: Edge feels similarly to Mozilla.
16:16:20 <mkwst> ... But these sound like interesting scenarios to explore.
16:16:34 <mkwst> bhill2: Also introduces a new kind of primitive that we can use to build useful things later.
16:16:41 <mkwst> ... Strawman ideas for verifiable applications.
16:16:56 <mkwst> ... Know that you're loading the same version of an app as someone else.
16:17:07 <mkwst> ... Tends to rely on some trusted core with a signature-based model.
16:17:35 <bhill2> mkwst: would be great to hear from mozillans that have questions or concerns on list or directly
16:18:04 <bhill2> dveditz: feedback I got was from freddyb, editor of SRI, but carrying from a crypto person in Berlin office
16:18:16 <bhill2> ... personally I think it is interesting but official moz position is skeptical
16:18:36 <bhill2> ... we do have a kind of home-rolled content signing mechanism for data downloaded into the client, wouldn't have needed to invent our own thing if we had this
16:18:44 <bhill2> mkwst: any docs on that?
16:19:02 <bhill2> dveditz: similar to what Martin Thompson posted
16:19:30 <jeffh> present+ jeffh
16:19:34 <rachel> rachel has joined #webappsec
16:19:51 <bhill2> mkwst: would be good to hear a broad thumbs up or down on whether this could end up in the platform with compatible implementations
16:20:18 <bhill2> dveditz: a differnece is whether we know key inherently (for browser content) vs. for any web content
16:21:33 <bhill2> JohnWilander: should we offer the page to pin a specific signature, that looks like today's SRI?
16:22:34 <bhill2> mkwst: also interested in being able to have a policy for a page about what keys to trust
16:23:13 <bhill2> JohnWilander: not interested in pinning the signature?
16:23:19 <bhill2> mkwst: if you want that, you can use a hash now
16:23:35 <bhill2> ... not content based
16:23:50 <bhill2> ... validating originator of content, not content itself
16:24:17 <bhill2> dveditz: might be interesting to extend to download links
16:24:53 <JohnWilander> (Pinning a signature protects against a hash collision attack but I'm not going to open that can on the call. :)
16:24:54 <mkwst> bhill2: Key rotation is hard.
16:25:17 <mkwst> ... Perhaps we could somehow prevent these kinds of dependencies in some way?
16:25:22 <mkwst> ... Only send signature to certain hosts?
16:25:47 <JohnWilander> (Or maybe not. I have to look at how the signature is made.)
16:25:57 <bhill2> mkwst: rsleevi raised this and there is good discussion on the thread
16:26:15 <bhill2> TOPIC: Compositional CSP proposal
16:26:22 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0012.html
16:27:22 <mkwst> bhill2: Perhaps some overlap with SRI signatures?
16:27:33 <mkwst> ... Whitelist a key in your policy, allow you to define some interesting extensions.
16:28:38 <bhill2> mkwst: would absolutely expect you'd be able to define a key as a source expression in CSP
16:29:14 <mkwst> bhill2: I wonder if SRI signatures would address similar needs to what compositional CSP aims to solve.
16:29:32 <mkwst> ... They note that 'strict-dynamic' perhaps allows more things than you'd like, as aaj noted.
16:29:48 <mkwst> ... Perhaps composing signatures would get us closer to a good outcome.
16:30:03 <bhill2> artur: my first impression is that if we switched to a signature model you would end up in a similar position to whitelists
16:30:46 <bhill2> ... the granularity of signed resources would end up quite similar to the granularity of whitelists, so not sure if it fits with what we are trying to do with the nonce-based side of things
16:31:00 <dveditz> q?
16:31:04 <dveditz> q+
16:31:10 <bhill2> ack dveditz
16:31:51 <bhill2> dveditz: in some ways it almost sounds like what they've done is address the objection I had at first with strict-dynamic (which I have been mollified somewhat by the suggestion that one can send two headers)
16:32:29 <bhill2> ... might work for a site that knew what they were doing within their own domains
16:32:45 <bhill2> artur: my guess it that starting point for the research was not really the nonce oriented or sri signature angle
16:33:02 <bhill2> ... but coming back to original proposals of CSP where author of page is responsible for creating the whitelist
16:33:18 <bhill2> ... every author that uses a google widget has to anticipate all the origins from which it may load resources
16:33:31 <bhill2> ... goal was to put burden onto the provider of the widget
16:34:11 <bhill2> ... if we'd started here in the whitelist world, perhaps ...
16:34:18 <bhill2> (sorry my call dropped, rejoining)
16:34:45 <bhill2> ... from where we are, its hard to address
16:34:47 <mkwst> ... folks would be able to whitelist widget URLs, which would set the correct policies for themselves.
16:35:38 <bhill2> TOPIC: cookie changes in Safari
16:35:48 <bhill2> JohnWilander: are there specific questions?
16:36:09 <mkwst> bhill2: There's a lot of value in single-sign on systems.
16:36:15 <mkwst> ... Supplement, replace passwords.
16:36:22 <mkwst> ... "Sign in with X"
16:36:39 <mkwst> ... The changes I'm aware of in Safari will make some of those systems harder to work with.
16:36:55 <mkwst> ... Perhaps discuss what the changes are, discuss how they impact these kinds of systems folks rely on for security.
16:37:08 <bhill2> JohnWilander: with changes that go under name of Intelligent Tracking Protection
16:37:27 <bhill2> ... there should only be website data and cookies for sites that the user "uses" currently defined as a user gesture
16:37:42 <bhill2> ... those cookies should only be available in a 3rd party context for sites that the user uses often
16:38:01 <bhill2> ... we did think a lot about the single sign on cases, which is a reason why there is a 24 hour window
16:38:27 <bhill2> ... where you can interact with an identity provider, e.g. example.com, so example.com will be available as an identity when you go to a new site
16:38:36 <bhill2> ... not ideal, we are building on existing web behavior and APIs
16:38:55 <bhill2> ... would like to get to a situation where sign on is two different things
16:39:11 <bhill2> ... which is why we have been talking about what we've called associated domains
16:39:29 <bhill2> ... which would allow related sites to exempt themselves within the scope of one organization from these restrictions
16:39:47 <bhill2> ... because SOP is not an accurate reflection of the real state of things in terms of what domains are the same organization
16:39:57 <bhill2> ... the other case is where unrelated organizations want to do SSO
16:40:24 <bhill2> ... would like to come up with a way (help from this group?) to come up with a way, like a user gesture, to ask for permission to access cookies in the 3rd party context
16:40:46 <bhill2> ... if there is a user gesture in a frame that has maybe a social plugin, that would allow for the true 3rd party to ask for permission to use it's cookies
16:40:54 <bhill2> ... and we could remember and allow that to happen
16:42:07 <bhill2> mkwst: in terms of the way this is being deployed, it would be useful if there was better debugging
16:42:15 <bhill2> ... waiting a day is not great
16:42:49 <bhill2> ... and I think devtools in webkit is not showing the partitioned cookies for a request, only 1st party or no cookies in cases where it should show partitioned cookies
16:43:03 <bhill2> ... we will file bugs to help you give developers the data they need to make this work
16:43:20 <bhill2> ... larger question I have is about 2nd order effects of removing cookies from things that developers can expect to have on the web
16:43:28 <bhill2> ... it seems to me the goal of this feature is great
16:43:51 <bhill2> ... in an ideal world, ensuring that data is present on a user's computer when that user is interacting with the owner of that data
16:43:57 <bhill2> ... seems like a reasonable goal
16:44:18 <bhill2> ... a problem is that cookies are not the only mechanism that exists, and a benefit is that users have control and are aware of those controls
16:44:46 <bhill2> ... the statement I would make is that the folks that you would like to prevent from tracking users are unlikely to be completely deterred from tracking users
16:45:00 <bhill2> ... and it may create an impetus in the market to move to tracking users by means over which they have less control
16:45:23 <bhill2> ... and I am concerned that we will end up worse than status quo, both in terms of "ickiness" in what will be done and lack of user control
16:45:39 <bhill2> ... curious what you think about these second order effects and how these will play out
16:45:48 <bhill2> ... and if there are plans to combat these effects
16:46:11 <bhill2> JohnWilander: are you talking about stateful thing or stateless things, known as fingerprinting
16:46:19 <bhill2> mkwst: let's assume you've taken care of all stateless stuff
16:46:29 <bhill2> ... folks will move to fingerprinting
16:46:42 <bhill2> JohnWilander: this has come up as we did research and implementation of the feature
16:47:11 <bhill2> ... our position is that even though there are other ways to achieve some level of tracking we are not going to shy away from trying to do something about the things we know are being abused today
16:47:27 <bhill2> ... we are going to monitor what happens, new ways to track will be invented
16:47:32 <bhill2> ... and take it from there.
16:47:43 <bhill2> ... if all move to fingerprinting, we will move focus to anti-fingerprinting
16:49:16 <bhill2> anti-fingerprinting may be easier for apple to do than others
16:52:57 <bhill2> JohnWilander: if fingerprinting is great, why are we seeing trackers use stateful mechanisms?
16:53:22 <bhill2> mkwst: I think people use the mechanisms that exist because they exist because they have very high levels of correlation
16:53:28 <bhill2> ... and they have user controls understand
16:55:34 <bhill2> JohnWIlander: we realize that stateful mechanisms are the golden standard and that's why we go after them
16:55:49 <bhill2> ... user control is part of the feature - we believe the user shows intent by interacting
16:56:32 <mkwst> http://www.scitepress.org/DigitalLibrary/PublicationsDetail.aspx?ID=UoE90ECay/Q=&t=1
16:56:37 <bhill2> TOPIC: future agendas
16:56:49 <bhill2> mkwst: origin attributes paper from Mozilla
16:57:06 <bhill2> ... we are interested and enthusiastic, a good topic for the future
16:57:21 <bhill2> http://www.scitepress.org/DigitalLibrary/PublicationsDetail.aspx?ID=UoE90ECay/Q=&t=1
16:58:06 <mkwst> \o/
16:58:14 <ArturJanc> congratulations!
16:58:20 <JohnWilander> Congratulations, Brad!
16:59:23 <bhill2> bhill2: would be nice to see a proposal for user consent gestures from Apple at TPAC
16:59:30 <bhill2> mkwst: and site affiliation stuff
17:00:17 <bhill2> artur: origin attributes and suborigins could be good to discuss again next month with feedback from mozilla
17:00:48 <bhill2> trackbot, end meeting
17:00:48 <trackbot> Zakim, list attendees
17:00:48 <Zakim> As of this point the attendees have been bhill, Brad, Hill, dveditz, mkwst, JohnWilander, jeffh
17:00:56 <trackbot> RRSAgent, please draft minutes
17:00:56 <RRSAgent> I have made the request to generate http://www.w3.org/2017/06/21-webappsec-minutes.html trackbot
17:00:57 <trackbot> RRSAgent, bye
17:00:57 <RRSAgent> I see no action items