See also: IRC log
<bhill2> bridge is open for anyone who wants to dial-in
<bhill2> we will be starting in five minutes or so
<bhill2> can those on the phone hear us?
<bhill2> any better on call mic volume?
<gioma1> just static noise and silence for me
<gioma1> it was me trying to say I heard someone
<scribe> scribe: Josh_Soref
<scribe> scribenick: timeless
<bhill2> we will pass around the wireless mic and we are lucky to have the W3C's best scribe at hand
<bhill2> we will pass around the wireless mic
<bhill2> and are lucky to have the top W3C scribe in the room
bhill2: Brad Hill, Pay Pal, Co-Chair
puhley: Peleus Uhley, Adobe
DanD: Dan Druta, AT&T
dveditz: Dan Veditz, Mozilla
ekr: Eric Rescorla, Co-Chair
<JeffH> can u hear gioma1?
<gioma1> no I cannot
Arno_: Arnaud Braud, France Telecom, observer
<JeffH> hear better ?
JeffH: Jeff Hodges, PayPal
Josh_Soref: Josh Soref, RIM, observer, scribe
<bhill2> Clickjacking Threats
<JeffH> it's Jeff Hodges
puhley: for those on the phone, there's a click jacking page
[ puhley describes the Clickjacking Threats page ]
[ Content overlays ]
puhley: overlay attacks
... transparent overlay attacks
... there are basically 4 different attacks
... flash player has a screen scraping solution
... it'll write out a dialog to the screen
... and then it will ask the renderer what's actually
shown
... to see if it's really showing
... but as we add content separation
... we don't want to allow content to screen scrape
... other solutions include X-Frame-Options
... Frame Busting
... etc.
... another type of attack is Scrolling attack
... in this, the victim content is completely visible
... top layer of content
... but you scroll it offscreen so only the answers are
visible
... but you put a fake question to the left
... "Do you like chocolate"
[ Everyone likes chocolate ]
puhley: a downside
... of the solution of putting questions in the center of the
page
... is that users think it's coming from the system
... which means that users trust the question more than it
should
dveditz: there are two kinds of
questions
... the browser can relatively easily ensure its content won't
be click-jacked
... but it's harder to protect the correct conveyance of two
different web contents
puhley: does the user need to
know the origin of content?
... and making sure the question is tied to the piece of
content with which it's associated
... a reason that flash renders itself
... instead of a modal dialog
... is if you're on a page with ads on the side
... you don't want a malicious ad on the side to convince the
user that it's CNN
... another attack is rapid content replacement
... make a dialog fully visible, but only for a fraction of a
second
... convince a user to click rapidly
... then swap in the attack for a short period
... a countermeasure
... is to require a dialog be visible for a set number of
seconds
... (Flash Player)
... it creates a problem for users
dveditz: Mozilla has a counter visible
puhley: there are tradeoffs in
any solution
... another version is repositioning the trusted window
... you're doing screen scraping
... the window is visible for 3 seconds
<dveditz> (the impt point was that users complain about that kind of solution)
puhley: but in the right hand
corner
... and then you scroll it to the center of the screen
... and then back to the corner
... one thing David brings up in his paper is Phantom mouse
cursors
... i'm not sure he sent a link to the demo to the list
... basically you create a floating div tag with a mouse
cursor
... which is at a fixed offset from the real mouse cursor
... and the real mouse cursor has an invisible cursor
... and you get the real mouse cursor over the dangerous
dialog
... but the fake one is over "Do you like chocolate?"
... Another attack is Drag and drop
... this is more specific to certain victim windows
... one of the top 10 web attacks from last year included a DnD
attack
... for people doing frame busting, people play tricks with
event handlers
... using 204 event codes
... tell the browser "No Content"
... try to use malicious event handlers
... if the browser creates a super window
... can i create a listener to it?
... Trusted Dialog extensions
... Say the dialog is bright yellow
... you render yellow on the page around it
... and it looks like your content is part of the trust
... maybe extending the two lines into a longer fraction of a
paragraph
... Trusted User interfaces
... any solution needs to be careful about how much trust it
conveys
... that something isn't equivalent to the SSL dialog
... Brad posted that there's no distinct level of trust
... for the last one, i recorded a general thing "does the user
understand what they're looking at?"
... I list some possible solutions for some of them
... this is designed to be the aggregation of ideas
JeffH: this is the problem space
bhill2: status codes and event
handlers
... people are afraid of being able to turn off scripting in
iframes
... since it turns off frame-busting
<bhill2> gioma1: would you like to discuss your submission, either voice or here on irc?
<bhill2> I can project the irc channel for the room
<bhill2> or we can just go over the paper ourselves
<gioma1> I'm unable in voice, I hear very badly. But I'm open to any question about the paper in IRC.
bhill2: There is another
attack
... where you can use the rapid click attack
... in the context of two browser windows
... or opening a dialog in the browser context
... trusted-window underneath untrusted-window
... and that allows bypass of X-Frame-Options
<bhill2> gioma1: we'll review the paper here voice, then, and ask questions on irc
bhill2: probably most of us here
are familiar with NoScript
... most prominently it offers the ability to turn off scripts
per context
... it's popular among security conscious individuals
... it also has ClearClick
... and it's the most prominent implementation
... Flash Player has something specific
... but ClearClick is more general
... The ClearClick WAS 2012 paper
... proposes an on-by-default mechanism
<gioma1> ClearClick WAS 2012 paper
bhill2: the ClearClick technology
is implemented mostly in terms of HTML5 technology
... and requires very few browser hooks
... ClearClick works by registering a listener that captures
mouse/keyboard/dnd events
... so it can see them before they're delivered to browser
content
<scribe> ... done with a mozilla specific event
UNKNOWN_SPEAKER: the second stage
is a Fast-track bypass
... to check if the window is unlocked
... i.e. Trustworthy against itself
... Parent chain check
... [PlaceHolder]
... Rapid Fire check
... [PlaceHolder2]
... Obstruction check
... takes a screenshot of reasonably sized (roughly
300x200px)
... and comparing the content the user clicking
... with the rendering the user sees
bhill2: there's no policy-channel between the server and the plugin
ekr: the larger the window the
less good things get
... if all i'm changing is the price
<gioma1> I'd like to clarify
<gioma1> that the size of the screenshot has an upper bound
<gioma1> of 320x200 for perf reasons,
<gioma1> but the lower bound is set by the document's inherent size
<gioma1> (so very tiny button gadgets like "Like!" work)
ekr: the case i'm thinking
of
... Amazon Purchasing
... the thing being obscured is quite large
bhill2: in the case of a PayPal
dialog
... you could change just the price or the name of the user
ekr: this style strategy seems to
require site interaction
... indicating how much tolerance it has
<gioma1> btw, the size grows in case of a form to include the whole form
bhill2: that's less of an oversight on the part of ClearClick
Josh_Soref: what tolerance does
one get if it's the size of the form
... is it still x%?
... the concern is that if only a few pixels (the $$ number)
are changed
... and the form is "very big"
... then %-wise relative to the protected pixel area, the
variation may be below the threshold
<gioma1> it used to be no tolerance
<gioma1> At-the-moment (3 or 4 weeks) it's 18%, configurable.
<bhill2> configurable by you, or by the target content?
<gioma1> By the tool even at runtime, so currently by me but...
<gioma1> a policy channel would be a benefit for several site-customizations which
<gioma1> would increase both accuracy and sensitivity
bhill2: an additional check
gioma1 sent on the mailing list, after he sent the paper.
... is for phantom-cursor, is that if the cursor has been
changed, it triggers
... ClearClick
... Generally, when the difference is significant, ClearClick
presents the user with a comparison dialog
... where the user can choose to proceed or stop
... he's also looking into mozAfterPaint
... in order to address timing based attacks
... I'll read his conclusion:
... The ClearClick module included in the NoScript add-on for
the Mozilla Firefox browser is currently the most effective
client-side protection against various forms of UI Redressing
attacks. It is enabled by default (independently from web
author's opt-in), protects plugin content as well as embedded
documents and doesn't impose origin restrictions on the nesting
hierarchy. Unfortunately its main issue is the relative
complexity of its implementation, which depends on a few
Mozilla specific platform features, even though it's entirely
written in JavaScript and mostly relies on portable HTML 5
features.
<bhill2> I asked the room who uses ClearClick
<bhill2> several hands went up
<gioma1> :)
<bhill2> people agreed that "used to see false positives a lot, lately it is very very good, don't see them anymore"
<bhill2> timeless is trying to generate a warning on bugzilla where he had previously seen them
<gioma1> in facts, it's the effect of the recent tolerance introduction and other tweakings regarding viewport decoration detection.
bhill2: that we haven't seen
false positives in a long time
... is fairly encouraging
... and then having a way for a site being able to specify what
it wants protected
... we could standardize this
<bhill2> alternate download: http://lists.w3.org/Archives/Public/public-webappsec/2012May/att-0021/ClearClick_WAS2012.pdf
<bhill2> we will take a 10 minute break
<bhill2> back at 32 after the hour
<bhill2> thanks gioma!
gopal: Gopal Raghavan, Nokia
tanvi1: Tanvi Vyas, Mozilla
s/tnavi1/tanvi/G
bhill2: this is another approach
i proposed on the list a couple of months ago
... it's much less comprehensive than ClearClick
... the basic idea is that
... the Web Application could declare -this control is
clickjacking protected-
... it could have a countdown, or a slider
... while it's being interacted with, it would have to be
topmost
... visible, stationary
... examples could be a new element type, or add a new
attribute
... examples of how this might work
... the action the user needs to do to confirm the action is
Slide
dveditz: that's a problem for a Screen Reader
bhill2: i think a lot of these
attacks aren't applicable to screen readers
... luckily/unluckily they aren't a target
... but there would be the ability to degrade gracefully
... it could act as a normal button
... or the AA could support the feature
DanD: what happens if you have two competing protected elements
bhill2: they only have to be topmost while your click is being delivered to an element
<JeffH> what is link to list of this meeting's reg'd attendees ?
bhill2: the click is only being delivered to one element at a time
<JeffH> Clickjacking Protected Interactive Elements
ekr: i'm just starting to think
about the underlying theory of the mechanism
... it seems to be force the user to take some time to see
it
... and take some time to watch it
bhill2: yes, and have the ability to abort
ekr: i wonder how much drop off you'd get
bhill2: i don't have user studies
on this yet
... what would be feasible, and what would UAs be willing to
do
... it isn't applicable to everything
dveditz: it doesn't fix DnD
bhill2: right
... but it has low battery/perf overhead
puhley: for an html element
... you set up a div tag
... with content in it
bhill2: you could have a new
request
... but if you're on a laggy network
... you don't want to click and wait for a resource
paulc: as your host, i'm noting
there are sweets outside
... and once the html group gets there, they'll be gone
ekr: are there other legitimate
reasons
... for why it would be obscured
... it almost seems like
... if it would have changed when i click the control
... it's probably a bad case
bhill2: the difference is
... you have less complexity
... i was trying to have to do constant monitoring
... constant screen shots
... that's an unacceptable requirement
... on a mobile device
ekr: i put my finger on this
slider
... and you do a Reflow
... you redraw that section of the screen
... and we expect the user to figure out what changed
Josh_Soref: that's sort of like what clearclick's compare-dialog does
[ bhill2 scrolls to example 2 ]
bhill2: here there's a clown
store text with a like below
... but clicking the like button
... then can show "Slide to like Acme Inc."
ekr: in this case, there's a reason why we'd want to change the content
DanD: you may have a different
approach, as a two factor user interaction
... using two actions
bhill2: why couldn't an overlay site train you to do that?
DanD: i'd be happy to have
something that surfaces out of an overlay
... the user would hopefully say "i won't trust that
page,
... if the trusted element is different"
puhley: if the slider slides
instead of the finger
... is that trusting?
bhill2: we had comments from michal zalewski
dveditz: what if who changes
it?
... we can only protect mixed origin
... if we only have one origin, and that page moves
... in current browsers, you can create a dragging attack
bhill2: my requirements forced
the control to be stationary
... now, what if the protected element is rendered
offscreen?
dveditz: the nice thing is that the browser could have a hint about how to re-render
gopal: are you also considering orientation changes?
bhill2: does it shift while your finger is down?
gopal: no
bhill2: I proposed we could take you to a lightbox experience
dveditz: that's fine with
checking out
... but if it's a like button
... or click an ad
... then it's more disruptive
... but those probably aren't using forms
... click fraud on an ad wants to get you there as fast as
possible
bhill2: having backchannels with the site communicating what it wants to protect
DanD: did you do user studies?
bhill2: i have not yet
dveditz: those slides don't appear to be on the archive
bhill2: let me send that out
[ Drawbacks of X-Frame-Options ]
bhill2: sometimes you don't want
to share information to some parties
... Allow-From doesn't help
... the merchant that could generate a clickjack
... is the same that would be generating a sale
... the person embedding the +1/like button
... is the person who benefits
dveditz: can you embed a like for someone else?
bhill2: i think you can
... sometimes iframes are better
... the screenshot approach is sometimes nice
... but sometimes your attention is elsewhere
... there's a problem with false positives
... that can be reduced
... and interactions are hard
... we tolerate ClearClick compare dialogs
... but people outside this room have no idea what it
means
... we have low deployment rates
... ClearClick probably has 1‱
... it's very small
dveditz: if ClearClick was split out from NoScript, it could probably have higher deployment
bhill2: Adaptive UI
randomization
... click jacking depends on same-origin
... it depends on consistent layout
... if you randomize the UI
... you can impinge the ability of the attacker
... that was proposed by Bill Curry (PayPal)
... one of the first proposals to the list
... but the attacker can send clicks to multiple locations
dveditz: deployment on NoScript is a bit over 1%, but less than 2%
bhill2: that's quite
impressive
... and successful attacks in 1% of cases is still a profitable
business
... Refining Randomization
... we can do recording of clicks
... and do analysis to detect fraud
... / clickjacking
... on the backend we create a bucket based on target
<dveditz> the most popular "user-chosen" add-on has around 10% deployment
bhill2: for like, the likee
... for pay, the payee
... look at first click miss rates bucket-by-bucket
<dveditz> there are some ride-along add-ons that are more popular, that users didn't really select. e.g. the Java Console add-on
bhill2: assume some natural
rate
... this protects against popunder and close attacks
... we can't distinguish one-off attacks from random
noise
... but we can identify campaigns
... if they start doing click jacking
... we'll see the first click rates jump
<dveditz> don't quote me on the numbers, I'm not one of our metrics guys. Just trying to eyeball the published "users" number on addons.mozilla.org but I don't know if they're measured the same way we measure Firefox users
bhill2: Sensitivity of Detection
[ Graphic: Sensitivity of Clickjacking Detection ]
dveditz: this isn't preventing fraud
bhill2: it's detecting after the fact
Josh_Soref: they can do
more
... they can reverse the charges/likes
... and penalize the account
ekr: the enclosing page can track the mouse
bhill2: if the user doesn't see
this interface
... they're seeing an overlay
... they'll have a 66% miss rate
... if it's only getting clickjacks
... and we can distinguish at the backend
DanD: this is an analytics capability
bhill2: Results
... assuming everything else works
... you can reduce the natural conversion rate to as little as
1% through clickjacking
... with 3 or 4 positions
... Adaptive Responses
... what if i try to put my competitor's store into the dog
house?
... If you detect this, you can have a graduated response
... popup with X-Frame-Options
... Add a CAPTCHA or re-verify credentials
dveditz: do you guys check
referers?
... i'm curious as to whether a reliable origin header is
useful
... if you're trying to attack a rival
bhill2: the button would have to encode the refering frame
dveditz: you may or may not get a referer on that today
Josh_Soref: if there's no referer, the server can require more UI
bhill2: you can't use this for
WebMail, or the FlashControlPanel
... or Nascar
... if you can't bucketize your targets
... for webmail/flashcontrolpanel
... it's expensive, you need to be able to do the analytics
JeffH: or already have it existing
bhill2: a lot of the targets
already have the capabilities in house
... david hong said the attacker could try to disperse the
attack
... some of this involves determining the natural misclick rate
independently
... instead of case-by-case calculation
... the biggest attack is the partial reveal attack
... "Click the Sleepy Frog to Win"
... but ClearClick will find that in a heartbeat
... combining the statistical backend bucketization
... and apply it to clearclick
... the page could say "if you think you're going to have a
ClearClick warning"
... "send the report to a feedback URI"
... a policy hint saying "report clickjacking to url" where the
url encodes the transaction
... Advantages:
... that makes false positives disappear
... you never stop users from interacting
... they can learn
... no confusing dialogs
... small install base can protect everyone
... penalize the account commiting fraud based on highly
sensitive information
... Conclusions:
... randomization isn't for everyone
... high cost, only usable in certain UIs
... primary targets are in its "sweet spot"
... Combines well with client-side techniques
... reporting loop + backend- fraud analysis approach can
remove some weaknesses of heuristic client-side techniques
DanD: it could be chatty
bhill2: it could be pretty
simple
... instead of a dialog in ClearClick
... it's a single Ping with a unique identifier
dveditz: a META with a report URI
bhill2: META clickjack-report uri
dveditz: browsers that know do
it
... browsers that don't ignore it
bhill2: the report isn't much
difference from CSP
... we only ship on violation
... that hasn't been a problem in bandwidth
puhley: we're assuming a page
that has already CSFP
... for PayPal, you have 1-click buys
... what does paypal need to encode?
bhill2: payee, amount
... the no-opt-in has the high bar
... the web is complicated
... how do we know we aren't breaking a large part of the
web
... does gioma1 have telemetry on false positives?
puhley: for the submit button/slider
<dveditz> I doubt it, people would scream about tracking or somesuch
puhley: the page would have to be designed to fit the slider protection
<gioma1> I've got *voluntary* reports, could try to extract some stats for next meeting.
<dveditz> the population of people interested in NoScript is almost exactly the sort that would notice and complain about extra connection attempts unrelated to their task at hand
bhill2: gioma1, it would be
really cool if we could get the overall rate of warning
dialogs
... what percentage of sites generate warning dialogs
... and how many times / year does the average (opt-in) user
see a dialog
<gioma1> bhill, I could extrapolate from people who uses the "Report" button
<dveditz> that kind of non-specific telemetry is generally accepted
<gioma1> are you suggesting to instrument current ClearClick to send anonymous usage stats?
puhley: for the use case
... who would use it
... we didn't define a User Persona
<JeffH> gioma1: i think the short answer is "sure"
puhley: we were talking about
<input type
... ....
... you have a PayPal page
... and a pay now button
... the assumption is the attacker is using an iframe
... the victim page is by definition iframed
... how does the page define that it's opting into the
click-jack protection
... it could just be a header
... but the page has to define which button is click-jack
protected
... would <input type="clickjackprotected">
... be sufficient instead of a page header
... there are pay now buttons on very large pages
... with full receipts
... in clickjacking, a fraction of the page has been
rendered
dveditz: are we only talking
about opt in at this point?
... the nice thing about ClearClick is that it doesn't require
opt in
... only Facebook/PayPal will do it
puhley: we have 3 levels
... optin
... slider
... server side
... 1. clearclick - browser for all pages
... 2. opt in "this is a sensitive page"
... -- slider
... 3. server side with heuristics
bhill2: 1.5, opt in for all
pages, with policy channel to refine it
... not sure if there's a precedent for @w3 level
... a compatibility list like ie8
... deliberately fallback to ie7 mode
... i wonder if we could identify that certain sites always
generate warnings
... and opt them out
... i'm tossing ideas out
DanD: the challenge is to educate
the user community
... on the real
JeffH: that will never happen
DanD: having multiple options with UI implications will have user confusion
puhley: https in the location bar
is an indication
... we changed once every 5 years and still confuse users
DanD: the protected element
... is a good way to give to a developer
... but it can be abused
... someone may overuse it
... and not realize they're causing harm
bhill2: that just means genuine
sites get to show their own ui
... but it doesn't protect
... fraud sites
... the risk is that the end user will assume the right site is
involved
dveditz: most click jacking is
based on size of frame
... could we do something based on frame size?
... if the page is too small
... it might play with protected content
... it could be in CSP
bhill2: something like ClearClick
with Hints+Policy+Feedback
... we could get very good for the whole web
... but what do you do when there's the "This is BAD"
... that's fine for PayPal/Facebook
... we could have the dialog for ClearClick
... i love the technology
... i hate the failure mode
puhley: i could say "deliver+give report"
<bhill2> Josh_Soref: instead of showing a warning, redirect to a browser-hosted page that can't be attacked, which explains the situation
<bhill2> Josh_Soref: there is no harm
<bhill2> bhill2: unless it's a false positive, then the user is really freaked out
<bhill2> Josh_Soref: browser vendors can use that to improve huristics
bhill2: if we do ClearClick and
opt in
... that's a tiny percentage of the web
... if we opt everyone in by default
s/redirect to/redirect framed page to/
scribe: is there a way we
can
... Could we have browser manufacturers to investigate false
positives?
... or just add a hard block?
puhley: i haven't used ClearClick
enough
... majority of pages are simple
... it's just Hulu/Gaming sites
<gioma1> the default tolerance (in ClearClick terms) for opt-out standalone deployments could be set relatively high
<gioma1> (like the current 18%, which looks to be doing very well)
<gioma1> and websites who care could tweak it to be stricter
gopal: does the slider consider touch events?
<bhill2> Josh_Soref: it's a mock-up, browser implementer could choose how to do that
JeffH: how big a problem is
clickjacking per se?
... puhley notes that most web pages are "simple"
... how much this is an issue on a global issue should inform
this
bhill2: maybe it's nice to opt in
by default
... but maybe the only people who care would be willing to opt
in
puhley: there's a small number of
sites who are concerned
... but they have a large number of users
JeffH: but that can inform how
it's approached
... thinking about the userbase and the entire set of
sites
... v. scoping to high value/high expertise sites
... and what's sufficient to hand them
... may be less work for a group such as this
... if this is a tangled mess
bhill2: how conservative do we have to be in terms of not breaking anything else out there?
dveditz: relatively
bhill2: i lean to very
... we could certainly lean to a mechanism that is only opt
in
... and maybe we could later apply by default
dveditz: if we had an opt in mechanism, we could get pretty radical
bhill2: you could monitor but not
enforce for all pages
... and you could get a ton of data
<dveditz> (and if it sucks then people won't opt-in)
bhill2: and calculate false
positive rates
... if you already have to build the technology for some
sites
dveditz: gioma1 mentioned he has
an 18% tolerance
... he could track what it would be at 5% / 10% / 20% /
...
... and he wouldn't need to collect the sites
... just "of the sites i fired, how many would i have fired at
this level"
<gioma1> how? by randomizing the tolerance?
<JeffH> can u hear dveditz's verbal response?
<bhill2> dvetitz: assume you compare, get a number and compare to your tolerance
<bhill2> dveditz: report what the difference rates are as a population
s/dvetitz/dveditz/
<gioma1> No I didn't hear. oh, I get it, by recomparing at different rates.
<gioma1> (maybe in background)
<dveditz> I assume you compare once and get a "difference number"
<bhill2> so we could start the technology as opt-in and only apply it to sites that provide policy/hints
<gioma1> ok
<gioma1> clear
<dveditz> which you then say "if (diff < tolerance) warning();"
<dveditz> but you can save that diff in buckets
<bhill2> but run it in the background and get really large telemetry numbers on how often it would trigger on the rest of the web
<bhill2> at different sensitivities
<bhill2> and use that to later make a decision as to whether to opt-in the entire web, and at what sensitivity
<bhill2> and perhaps collect, voluntarily, what sites would break and have a compatibility opt-out list baked-in
<gioma1> bhill2, wait, someone did something similar
<gioma1> let me find the paper...
s/diff < tolerance/diff > tolerance/
<gioma1> http://www.iseclab.org/papers/asiaccs122-balduzzi.pdf
<gioma1> these guys built a scanner based on ClearClick to analyze Clickjacking's prevalence on the web
<gioma1> (I discovered it last night while refining my references)
<bhill2> so giorgio, would you be willing to begin working on a w3c draft describing the clearclick technology in a browser-agnostic manner
<JeffH> good paper to reference, thanks gioma1
<bhill2> with mechanisms for resource owners to provide hints/policy to the enforcement mechanism, and a way for the mechansim to report back to the resource owner
<gioma1> bhill2, I'd like it (be soft on deadline, though :) )
<bhill2> :)
<bhill2> we can look for a co-editor - that's usually a good idea, anyway
<gioma1> bhill2, you?
<bhill2> I'd be willing to do it, but have to consult w/w3c staff on whether that is a conflict with my job as co-chair
<bhill2> so we are going to break for lunch for the moment
<bhill2> I think we should summarize this on the list, make a proposal
<bhill2> and I'd like to propose gioma1 as an initial editor, and find another co-editor
<bhill2> I think a browser person might be a better choice than myself since they'd know the guts of the implementation details
<bhill2> but let's solicit on the list. David Huang might also be a better choice than I if he's free.
<bhill2> thanks very much, Giorgio.
<gioma1> bhill2, my pleasure
<bhill2> we're going to be doing test development following lunch, so you can get some sleep if it's' that time of day there.
<bhill2> :)
<scribe> scribe: bhill2
<tanvi> i'm working on the csp tests
<gopal> https://dvcs.w3.org/hg/webappsec
<puhley> I am working on converting CGIs to PHP. I started on the bottom of the list and I am working my way back up.
<odinho> http://w3c-test.org/webappsec/tests/cors/submitted/cors1.0/cors-tests.html
<odinho> Hmm
<odinho> wrog
<odinho> https://bitbucket.org/ms2ger/test-runner/src
<odinho> s/Hmm//
<odinho> s/wrog//
<odinho> s|http://w3c-test.org/webappsec/tests/cors/submitted/cors1.0/cors-tests.html||
<odinho> s|https://bitbucket.org/ms2ger/test-runner/src|-> https://bitbucket.org/ms2ger/test-runner/src Ms2Ger's testharness.js testrunner
<odinho> RRSAgent: draft minutes
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s|\|| Succeeded: s/I'm heading out now, expect me there in about 15.// Succeeded: s/rrsagent make minutes// Succeeded: s/is today's agenda available?// Succeeded: s/thanks bhill2// Succeeded: s|http://www.w3.org/Security/wiki/Clickjacking_Threats|-> http://www.w3.org/Security/wiki/Clickjacking_Threats Clickjacking Threats| Succeeded: s/Chair: BradH/Chair: BradH, ekr/ Succeeded: s/Jeff Hill/Jeff Hodges/ Succeeded: s/it/it?/ Succeeded: i/for those on/Topic: Clickjacking threats overview Succeeded: i/Brad Hill, Pay Pal/Topic: Introductions Succeeded: s|http://noscript.net/downloads/ClearClick_WAS2012.pdf|ClearClick WAS 2012 paper| Succeeded: s/Trusted/Trustworthy against itself/ Succeeded: s/ATM/At-the-moment/ Succeeded: s/[Conclusion]/[Paper-Section-5]/ Succeeded: s/[Paper-Section-5]/The ClearClick module included in the NoScript add-on for the Mozilla Firefox browser is currently the most effective client-side protection against various forms of UI Redressing attacks. It is enabled by default (independently from web author's opt-in), protects plugin content as well as embedded documents and doesn't impose origin restrictions on the nesting hierarchy. Unfor/ Succeeded: s|tunately its main issue is the relative complexity of its implementation, which depends on a few Mozilla specific platform features, even though it's entirely written in JavaScript and mostly relies on portable HTML 5 features./|| Succeeded: s/Unfor/Unfortunately its main issue is the relative complexity of its implementation, which depends on a few Mozilla specific platform features, even though it's entirely written in JavaScript and mostly relies on portable HTML 5 features./ Succeeded: s/+gopal// FAILED: s/tnavi1/tanvi/G Succeeded: s/static(unmoving)/stationary/ Succeeded: s/changed my nick back to tanvi// Succeeded: s|and is there a link to what Brad is presenting now ?|-> http://www.w3.org/Security/wiki/Anti-Clickjacking_Protected_Interactive_Elements Clickjacking Protected Interactive Elements| Succeeded: s/thx// Succeeded: s|http://developers.facebook.com/docs/reference/plugins/like/|| Succeeded: s/bit/beat/ Succeeded: s/analsysi/analysis/ Succeeded: s/iframes/iframed/ Succeeded: s/reciepts/receipts/ Succeeded: s/timeless:/Josh_Soref:/G FAILED: s/redirect to/redirect framed page to/ FAILED: s/dvetitz/dveditz/ FAILED: s/diff < tolerance/diff > tolerance/ FAILED: s/Hmm// FAILED: s/wrog// FAILED: s|http://w3c-test.org/webappsec/tests/cors/submitted/cors1.0/cors-tests.html|| FAILED: s|https://bitbucket.org/ms2ger/test-runner/src|-> https://bitbucket.org/ms2ger/test-runner/src Ms2Ger's testharness.js testrunner| Found Scribe: Josh_Soref Found ScribeNick: timeless Found Scribe: bhill2 Scribes: Josh_Soref, bhill2 Present: Josh_Soref WARNING: Fewer than 3 people found for Present list! Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2012Apr/0017.html Got date from IRC log name: 03 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/03-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]