<trackbot> Date: 24 August 2015

<bhill2> +present bhill2

<DanKaminsky> IRC LIVES

<rbarnes> DanKaminsky: more so than you might think

does the present+ syntax require a name after?

<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-07-27-webappsec-minutes.html

Minutes Approval

wseltzer: I can try

<bhill2> hearing in objection, minutes unanimously approved

bhill2: hearing no objection minutes approved

News

scribenick dveditz

scribe: we have a number of specs going into candidate rec., mixed content and CSP2
... actually CSP2 is going to proposed recommendation. testsuite looking pretty good, can always use more tests
... and some latebreaking 1.1/2 features not covered in there
... have some outstanding PR that need review
... I'll be preparing a transition request for CORS to make some revisions and then it will go back to recommendation status

<wseltzer> TPAC

scribe: TPAC is in Sapporo Japan this year
... WASWG is meeting on Thursday and Friday

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

Future Spec Rotation

bhill2: next topic is future spec rotation
... we've been doing well with our current call configuration, focusing on one or two specs at a time

<bhill2> https://docs.google.com/spreadsheets/d/1_mZc32kZpuGY7miKbfR7FYybU1zQ7RUFg2Vj-UJlzlg/edit#gid=0

bhill2: we could go ahead and restart the rotation in the same order (see spreadsheet)
... that seemed to work well, and SRI is close to ready so it'd be good to jump into that

UI Security and Iron Frame

bhill2: please let me know if you're an editor or involved in a spec and those dates don't work for you
... brief introduction and history...
... when this group was chartered 5 years ago clickjacking was a big unsolved problem
... it's still an unsolved problem
... we have a spec that proposes heuristics of checking view ports and such based on Clear-click

<wseltzer> http://www.w3.org/TR/UISecurity/

bhill2: we were never able to muster a lot of implementation interest on account of performance impacts and complexity. been stale for about a year

<rbarnes> wseltzer: thanks!

bhill2: Happy to introduce Dan who has been doing research and work in this area

<gmaone> http://dankaminsky.com/

<wseltzer> http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickjacking/

<bhill2> http://www.slideshare.net/dakami/i-want-these-bugs-off-my-internet-51423044

DanKaminsky: slides are on dankaminsky.com, wasn't planning on talking through the slides but they can be a useful starting point
... looking for a good first slide...... go to slide 36
... as brad mentioned most approaches to solving clickjacking have focused on pixel comparisons, which is never going to work
... browsers don't know what pixels they're rendering -- they send commands to the graphics systems and say "you figure it out"
... reversing that would be prohibitive, all the way down to the hardware
... instead, browsers do know what they're trying to render, so we can play "jenga" with the layers we're drawing
... not changing the DOM, but at the rendering layer
... initial implementation is in blink, but have talked to graphics engineers at Mozilla and (formerly at) MS
... there's no technology that can see overlays and transformations
... [starting at slide 36 describes different transforms that have been tested and correctly detected]
... current implementation shows this works and is fast enough. I'm sure it will be totally rewritten as it goes into browsers
... any questions?

rbarnes: could you describe the spec interop here? what features are we exposing

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

<bhill2> Here are some old-school requirements and threat modeling we did back in 2011:

<bhill2> http://www.w3.org/Security/wiki/Anti-Clickjacking_Requirements

<bhill2> http://www.w3.org/Security/wiki/Clickjacking_Threats

DanKaminsky: same for facebook. we'd _like_ to have foreign content embedded in our page safely

<bhill2> (sorry 2012)

<slightlyoff> oh hai DanKaminsky! (lurking on your call) w/ estark and jww

DanKaminsky: this feature guarantees either the content is fully visible or it isn't, don't make any claims about the middle states

rbarnes: <missed question>

DanKaminsky: I'm just sending events to frames about how visible it is, "you figure it out"

<tanvi> so essentially tells frames the visibility hierarchy and where they are

<tanvi> ?

DanKaminsky: twitter would use this, facebook would, advertising

<KristijanBurnik> Any reference/link to the Blink implementation mentioned?

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?

DanKaminsky: you need to describe the relative position, so we can detect scrolling and mouse positioning correctly
... this gets you around a bunch of more annoying clickhacking attacks: it was visible, but only for a millisecond before the click

bhill2: if we look in terms of existing proposed set of CSP directives it looks like input protection selectors would have to go

DanKaminsky: granularity I'm interested in is the entire area of the iframe, not individual elements
... 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

bhill2: a DOM selector would still be supplied as part of gmaone

DanKaminsky: the element to be selected needs to be the entire doc in my mental model
... the only exception might be a flash object because that has it's own model for protection (if we want to support that)

terri: if there's a malicious add injected here would it gain any additional tools for the attacker?

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
... there are a couple of rough edges. Drop shadow overlays different element. currently I'm popping _over_ the drop shadows
... I don't like breaking people's design, but I don't know how to do this yet
... code for this for people to play with should be out shortly

bhill2: as much as I'd like to see this implemented, how applicable to various graphics systems will this be?
... when we started UI Security pixel scraping seemed to work in Firefox, but then they changed their drawing strategy
... if we re-run in time 5 years is this still a reasonable strategy to implement in that approach (for instance)

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
... we've looked at different ways to collect "what % of an element is viewable". Dan's approach makes it cheap to calculate
... this works well for ads, may not work so well in other cases like "infinite scrollers"

DanKaminsky: infinite scrollers?

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
... we're working on a Position Observer API, and when we have that ready we'll bring it to this group

<bhill2> https://github.com/slightlyoff/PositionObserver/blob/master/explainer.md

DanKaminsky: any questions?....
... my first foray into standards making

gmaone.: is there any way to use this without scripting?

DanKaminsky: yes, if you delivered a policy over CSP you would still get reporting at least, even without scripting

<gmaone> it was me

(sorry, don't recognize your voice anymore)

bhill2: if I were to incorporate this into the UI Security spec would you have any obection Giorgio (as editor)?

gmaone: that's fine

<KristijanBurnik> Any reference/link to the Blink implementation mentioned?

bhill2: we'll talk to everyone in two weeks then. thanks Dan

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/would anything protect that/would it gain any additional tools for the attacker/
Succeeded: s/@@/Observer/
Succeeded: s/@@/gmaone./
Succeeded: s/@@/gmaone/
No ScribeNick specified.  Guessing ScribeNick: dveditz
Inferring Scribes: dveditz
Present: wseltzer bhill2 gmaone terri Dan Kaminsky mkwst crispin Francois rbarnes kristijan tanvi dveditz jww estark francois DanKaminsky
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0092.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 24 Aug 2015
Guessing minutes URL: http://www.w3.org/2015/08/24-webappsec-minutes.html
People with action items: