18:52:51 <RRSAgent> RRSAgent has joined #webappsec
18:52:51 <RRSAgent> logging to http://www.w3.org/2015/08/24-webappsec-irc
18:52:53 <trackbot> RRSAgent, make logs world
18:52:53 <Zakim> Zakim has joined #webappsec
18:52:55 <trackbot> Zakim, this will be WASWG
18:52:55 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
18:52:56 <trackbot> Meeting: Web Application Security Working Group Teleconference
18:52:56 <trackbot> Date: 24 August 2015
18:52:58 <wseltzer> agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0092.html
18:57:00 <bhill2> bhill2 has joined #webappsec
18:57:47 <gmaone> gmaone has joined #webappsec
18:58:09 <bhill2> +present bhill2
18:58:41 <willscott> willscott has joined #webappsec
18:58:42 <wseltzer> present+ wseltzer
18:59:06 <bhill2> present+ bhill2
18:59:17 <gmaone> present+ gmaone
19:00:14 <terri> present+ terri
19:01:29 <bhill2> present+ Dan Kaminsky
19:01:32 <wseltzer> present+ mkwst
19:01:39 <wseltzer> present+ crispin
19:01:43 <DanKaminsky> DanKaminsky has joined #webappsec
19:01:50 <jww> jww has joined #webappsec
19:01:55 <DanKaminsky> IRC LIVES
19:02:55 <estark> estark has joined #webappsec
19:03:01 <rbarnes> DanKaminsky: more so than you might think
19:03:10 <bhill2> present+ Francois
19:03:23 <wseltzer> present+ rbarnes
19:03:26 <tanvi> tanvi has joined #webappsec
19:03:29 <dveditz> dveditz has joined #webappsec
19:03:33 <wseltzer> present+ kristijan
19:03:36 <tanvi> zakim, who is here
19:03:36 <Zakim> tanvi, you need to end that query with '?'
19:03:40 <tanvi> zakim, who is here?
19:03:40 <Zakim> sorry, tanvi, I don't know what conference this is
19:03:42 <Zakim> On IRC I see dveditz, tanvi, estark, jww, DanKaminsky, willscott, gmaone, bhill2, Zakim, RRSAgent, rbarnes, freddyb, terri, timeless, tobie, mounir_, mkwst, Josh_Soref,
19:03:42 <Zakim> ... slightlyoff, trackbot, wseltzer
19:03:54 <francois> francois has joined #webappsec
19:04:06 <tanvi> present +tanvi
19:04:16 <jww> present+
19:04:18 <dveditz> present+ dveditz
19:04:20 <DanKaminsky> present+
19:04:23 <jww> present+ jww
19:04:25 <estark> present+ estark
19:04:43 <dveditz> does the present+ syntax require a name after?
19:04:44 <francois> present+
19:04:54 <francois> present+ francois
19:05:16 <dveditz> present+ jww
19:05:22 <dveditz> present+ DanKaminsky
19:05:29 <bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-07-27-webappsec-minutes.html
19:05:32 <bhill2> TOPIC: Minutes Approval
19:05:39 <dveditz> wseltzer: I can try
19:05:53 <bhill2> hearing in objection, minutes unanimously approved
19:05:56 <dveditz> bhill2: hearing no objection minutes approved
19:05:58 <bhill2> TOPIC: News
19:06:13 <dveditz> scribenick dveditz
19:06:23 <KristijanBurnik> KristijanBurnik has joined #webappsec
19:06:39 <dveditz> ... we have a number of specs going into candidate rec., mixed content and CSP2
19:07:00 <dveditz> ... actually CSP2 is going to proposed recommendation. testsuite looking pretty good, can always use more tests
19:07:13 <dveditz> ... and some latebreaking 1.1/2 features not covered in there
19:07:40 <dveditz> ... have some outstanding PR that need review
19:08:25 <dveditz> ... I'll be preparing a transition request for CORS to make some revisions and then it will go back to recommendation status
19:08:36 <wseltzer> -> http://www.w3.org/2015/10/TPAC/ TPAC
19:08:38 <wseltzer> q+
19:08:43 <dveditz> ... TPAC is in Sapporo Japan this year
19:09:01 <dveditz> ... WASWG is meeting on Thursday and Friday
19:09:32 <dveditz> wseltzer: we've worked out some discount rates for new participants to IETF meetings for those who want to stay and attend that the next week
19:09:37 <bhill2> TOPIC: Future Spec Rotation
19:09:40 <dveditz> bhill2: next topic is future spec rotation
19:10:07 <dveditz> ... we've been doing well with our current call configuration, focusing on one or two specs at a time
19:10:22 <bhill2> https://docs.google.com/spreadsheets/d/1_mZc32kZpuGY7miKbfR7FYybU1zQ7RUFg2Vj-UJlzlg/edit#gid=0
19:10:28 <dveditz> ... we could go ahead and restart the rotation in the same order (see spreadsheet)
19:10:45 <wseltzer> q-
19:10:49 <dveditz> ... that seemed to work well, and SRI is close to ready so it'd be good to jump into that
19:11:08 <bhill2> TOPIC: UI Security and Iron Frame
19:11:09 <dveditz> ... please let me know if you're an editor or involved in a spec and those dates don't work for you
19:11:24 <dveditz> ... brief introduction and history...
19:11:44 <dveditz> ... when this group was chartered 5 years ago clickjacking was a big unsolved problem
19:11:50 <dveditz> ... it's still an unsolved problem
19:12:44 <dveditz> ... we have a spec that proposes heuristics of checking view ports and such based on Clear-click
19:12:58 <wseltzer> http://www.w3.org/TR/UISecurity/
19:13:28 <dveditz> ... we were never able to muster a lot of implementation interest on account of performance impacts and complexity. been stale for about a year
19:13:33 <rbarnes> wseltzer: thanks!
19:13:45 <dveditz> ... Happy to introduce Dan who has been doing research and work in this area
19:13:57 <gmaone> http://dankaminsky.com/
19:14:09 <wseltzer> http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickjacking/
19:14:20 <bhill2> http://www.slideshare.net/dakami/i-want-these-bugs-off-my-internet-51423044
19:14:21 <dveditz> DanKaminsky: slides are on dankaminsky.com, wasn't planning on talking through the slides but they can be a useful starting point
19:14:56 <dveditz> ... looking for a good first slide...... go to slide 36
19:15:24 <dveditz> ... as brad mentioned most approaches to solving clickjacking have focused on pixel comparisons, which is never going to work
19:15:53 <dveditz> ... browsers don't know what pixels they're rendering -- they send commands to the graphics systems and say "you figure it out"
19:16:07 <dveditz> ... reversing that would be prohibitive, all the way down to the hardware
19:16:32 <dveditz> ... instead, browsers do know what they're trying to render, so we can play "jenga" with the layers we're drawing
19:16:49 <dveditz> ... not changing the DOM, but at the rendering layer
19:17:33 <dveditz> ... initial implementation is in blink, but have talked to graphics engineers at Mozilla and (formerly at) MS
19:17:55 <dveditz> ... there's no technology that can see overlays and transformations
19:19:45 <dveditz> ... [starting at slide 36 describes different transforms that have been tested and correctly detected]
19:20:35 <dveditz> ... current implementation shows this works and is fast enough. I'm sure it will be totally rewritten as it goes into browsers
19:20:40 <dveditz> ... any questions?
19:21:03 <dveditz> rbarnes: could you describe the spec interop here? what features are we exposing
19:22:04 <dveditz> DanKaminsky: we're controlling what happens to framed content. Twitter can't just have a tweet button because it could be hidden and clickjacked, so twitter has to open a popup or new page. everyone hates that
19:22:12 <bhill2> Here are some old-school requirements and threat modeling we did back in 2011:
19:22:13 <bhill2> http://www.w3.org/Security/wiki/Anti-Clickjacking_Requirements
19:22:18 <bhill2> http://www.w3.org/Security/wiki/Clickjacking_Threats
19:22:24 <dveditz> ... same for facebook. we'd _like_ to have foreign content embedded in our page safely
19:22:37 <bhill2> (sorry 2012)
19:22:51 <slightlyoff> oh hai DanKaminsky! (lurking on your call) w/ estark and jww
19:23:03 <dveditz> ... this feature guarantees either the content is fully visible or it isn't, don't make any claims about the middle states
19:23:12 <dveditz> rbarnes: <missed question>
19:23:48 <dveditz> DanKaminsky: I'm just sending events to frames about how visible it is, "you figure it out"
19:23:54 <tanvi> so essentially tells frames the visibility hierarchy and where they are
19:23:58 <tanvi> ?
19:23:59 <dveditz> ... twitter would use this, facebook would, advertising
19:24:09 <KristijanBurnik> Any reference/link to the Blink implementation mentioned?
19:24:46 <dveditz> bhill2: when you're sending events to a dom about visibility is that for the entire rendered area relative to the resource? or is there a sub-area that can be defined?
19:25:12 <dveditz> DanKaminsky: you need to describe the relative position, so we can detect scrolling and mouse positioning correctly
19:25:46 <dveditz> ... this gets you around a bunch of more annoying clickhacking attacks: it was visible, but only for a millisecond before the click
19:26:26 <dveditz> bhill2: if we look in terms of existing proposed set of CSP directives it looks like input protection selectors would have to go
19:26:52 <dveditz> DanKaminsky: granularity I'm interested in is the entire area of the iframe, not individual elements
19:27:21 <dveditz> ... if you don't have this none of this matters. If it's same-origin then an attacker just reaches in and turns it off
19:27:40 <dveditz> bhill2: a DOM selector would still be supplied as part of @@
19:27:58 <dveditz> DanKaminsky: the element to be selected needs to be the entire doc in my mental model
19:28:26 <dveditz> ... the only exception might be a flash object because that has it's own model for protection (if we want to support that)
19:28:46 <dveditz> terri: if there's a malicious add injected here would anything protect that?
19:29:58 <dveditz> DanKaminsky: I haven't thought of a way to abuse this in an attack scenario, but my main worry has been not making the web slow
19:30:45 <dveditz> ... there are a couple of rough edges. Drop shadow overlays different element. currently I'm popping _over_ the drop shadows
19:30:55 <dveditz> ... I don't like breaking people's design, but I don't know how to do this yet
19:31:08 <dveditz> ... code for this for people to play with should be out shortly
19:31:40 <dveditz> bhill2: as much as I'd like to see this implemented, how applicable to various graphics systems will this be?
19:32:04 <dveditz> ... when we started UI Security pixel scraping seemed to work in Firefox, but then they changed their drawing strategy
19:32:25 <terri> s/would anything protect that/would it gain any additional tools for the attacker/
19:32:41 <dveditz> ... if we re-run in time 5 years  is this still a reasonable strategy to implement in that approach (for instance)
19:33:24 <dveditz> slightlyoff: a little background, we're also concerned about this issue also. ad market has moved to a standard called "viewability". part of the reason to do this is to make "viewability" easier to calculate
19:33:59 <dveditz> ... we've looked at different ways to collect "what % of an element is viewable". Dan's approach makes it cheap to calculate
19:34:19 <dveditz> ... this works well for ads, may not work so well in other cases like "infinite scrollers"
19:34:29 <dveditz> DanKaminsky: infinite scrollers?
19:35:19 <dveditz> slightlyoff: UIs that are a long list of things where you compose things right before they scroll into view, so you care about a visibility area slightly larger than the viewport. but doesn't require high fidelity
19:35:51 <dveditz> ... we're working on a Position @@ API, and when we have that ready we'll bring it to this group
19:35:57 <bhill2> https://github.com/slightlyoff/PositionObserver/blob/master/explainer.md
19:36:11 <dveditz> s/@@/Observer/
19:36:25 <dveditz> DanKaminsky: any questions?....
19:36:38 <dveditz> ... my first foray into standards making
19:37:03 <dveditz> @@: is there any way to use this without scripting?
19:37:28 <dveditz> DanKaminsky: yes, if you delivered a policy over CSP you would still get reporting at least, even without scripting
19:37:48 <gmaone> it was me
19:38:00 <dveditz> s/@@/gmaone.
19:38:09 <dveditz> s/@@/gmaone/
19:38:18 <dveditz> (sorry, don't recognize your voice anymore)
19:38:57 <dveditz> bhill2: if I were to incorporate this into the UI Security spec would you have any obection Giorgio (as editor)?
19:39:10 <dveditz> gmaone: that's fine
19:39:29 <KristijanBurnik> Any reference/link to the Blink implementation mentioned?
19:39:43 <dveditz> bhill2: we'll talk to everyone in two weeks then. thanks Dan
19:39:55 <wseltzer> rrsagent, make minutes
19:39:55 <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/24-webappsec-minutes.html wseltzer
19:40:14 <dveditz> wseltzer: I don't know if I did the scribenick thing correctly
19:40:14 <bhill2> Dan said he'd be open sourcing it shortly
19:40:19 <bhill2> don't think it's public yet
19:40:31 <dveditz> bhill2: open sourcing the code or the spec?
19:40:35 <bhill2> code
19:40:42 <bhill2> there is no "spec" yet
19:41:00 <bhill2> would be an update to UI Security with new non-normative implementation advice
19:41:02 <dveditz> ok, good. thought I was just being stupid at googling the api
19:41:21 <dveditz> or I suppose since I'm at mozilla we "yahoo" for things now
19:41:32 <bhill2> I'll check with David Huang, too.  He couldn't make it today as he is in a very different time zone.
19:42:01 <dveditz> DanKaminsky: is there any more concrete information than the slides?
19:42:24 <dveditz> like the API or events that get sent or any of that kind of specific?
19:43:40 <bhill2> bhill2 has joined #webappsec
19:43:47 <bhill2> bhill2 has joined #webappsec
19:53:26 <DanKaminsky> @dvetiz Right now, it's basically document.requestVisibility() on the iframe, with viewability messages coming in via onerror, but this is getting cleaned up too.
20:10:41 <dveditz> DanKaminsky: we have no end of special events these days, ultimately you want onvisibility or something rather than overloading onerror
20:10:59 <dveditz> (but I get expedient POC hacks)
20:28:50 <DanKaminsky> @dveditz Yes, the original implementation was onvisibilitychange ala page visibility api, but I suspect I'll be implementing position observer or something :)
20:29:21 <dveditz> oh right, I should look at that spec. that was new to me