See also: IRC log
<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
wseltzer: I can try
<bhill2> hearing in objection, minutes unanimously approved
bhill2: hearing no objection minutes approved
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
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
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