WebAppSec F2F -- 03 May 2012

<scribe> scribe: Josh_Soref

<scribe> scribenick: timeless

<bhill> we will pass around the wireless mic

<bhill> and are lucky to have the top W3C scribe in the room

Introductions

bhill: Brad Hill, Pay Pal, Co-Chair

puhley: Peleus Uhley, Adobe

DanD: Dan Druta, AT&T

dveditz: Dan Veditz, Mozilla

ekr: Eric Rescorla, Co-Chair

Arno_: Arnaud Braud, France Telecom, observer

JeffH: Jeff Hodges, PayPal

Josh_Soref: Josh Soref, RIM, observer, scribe

gioma1: Giorgio Maone (on phone)

Clickjacking threats overview

<bhill> Clickjacking Threats

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

bhill: status codes and event handlers
... people are afraid of being able to turn off scripting in iframes
... since it turns off frame-busting

<bhill> gioma1: would you like to discuss your submission, either voice or here on irc?

<bhill> I can project the irc channel for the room

<bhill> 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.

bhill: 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

<bhill> gioma1: we'll review the paper here voice, then, and ask questions on irc

bhill: 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

bhill: 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
... implemented with a mozilla specific event
... the second stage is a Fast-track bypass
... to check if the window is unlocked
... i.e. Trustworthy against itself
... Parent chain check
... Rapid Fire check
... Obstruction check
... takes a screenshot of reasonably sized (roughly 300x200px)
... and comparing the content the user clicking
... with the rendering the user sees
... 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

bhill: 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

bhill: 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.

<bhill> 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

bhill: 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.

<bhill> I asked the room who uses ClearClick

<bhill> several hands went up

<gioma1> :)

<bhill> people agreed that "used to see false positives a lot, lately it is very very good, don't see them anymore"

<bhill> 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.

bhill: 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

<bhill> alternate download: http://lists.w3.org/Archives/Public/public-webappsec/2012May/att-0021/ClearClick_WAS2012.pdf

<bhill> we will take a 10 minute break

<bhill> back at 32 after the hour

<bhill> thanks gioma!

Introductions continued

gopal: Gopal Raghavan, Nokia

tanvi: Tanvi Vyas, Mozilla

Protected Interactive Elements

bhill: 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

bhill: 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

bhill: 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 ?

bhill: 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

bhill: yes, and have the ability to abort

ekr: i wonder how much drop off you'd get

bhill: 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

bhill: right
... but it has low battery/perf overhead

puhley: for an html element
... you set up a div tag
... with content in it

bhill: 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

bhill: 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

[ bhill scrolls to example 2 ]

bhill: 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

bhill: 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?

bhill: 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

bhill: 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?

bhill: does it shift while your finger is down?

gopal: no

bhill: 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

bhill: having backchannels with the site communicating what it wants to protect

DanD: did you do user studies?

bhill: i have not yet

Server-side approaches to clickjacking detection

dveditz: those slides don't appear to be on the archive

bhill: let me send that out

[ Drawbacks of X-Frame-Options ]

bhill: 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?

bhill: 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

bhill: 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%

bhill: 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

bhill: 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

bhill: 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

bhill: Sensitivity of Detection

[ Graphic: Sensitivity of Clickjacking Detection ]

dveditz: this isn't preventing fraud

bhill: 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

bhill: 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

bhill: 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

bhill: 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

bhill: 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

bhill: 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

bhill: 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

bhill: META clickjack-report uri

dveditz: browsers that know do it
... browsers that don't ignore it

bhill: the report isn't much difference from CSP
... we only ship on violation
... that hasn't been a problem in bandwidth

What are we protecting

puhley: we're assuming a page that has already CSFP
... for PayPal, you have 1-click buys
... what does paypal need to encode?

bhill: 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

bhill: 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

bhill: 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

bhill: 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

bhill: 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"

Josh_Soref: instead of showing a warning, redirect framed page to a browser-hosted page that can't be attacked, which explains the situation
... there is no harm

bhill: unless it's a false positive, then the user is really freaked out

Josh_Soref: browser vendors can use that to improve huristics

bhill: if we do ClearClick and opt in
... that's a tiny percentage of the web
... if we opt everyone in by default
... 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?

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

bhill: 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

bhill: how conservative do we have to be in terms of not breaking anything else out there?

dveditz: relatively

bhill: 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

bhill: 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)

bhill: 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?

dveditz: assume you compare, get a number and compare to your tolerance
... report what the difference rates are as a population

<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"

<bhill> 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

<bhill> but run it in the background and get really large telemetry numbers on how often it would trigger on the rest of the web

<bhill> at different sensitivities

<bhill> and use that to later make a decision as to whether to opt-in the entire web, and at what sensitivity

<bhill> and perhaps collect, voluntarily, what sites would break and have a compatibility opt-out list baked-in

<gioma1> bhill, wait, someone did something similar

<gioma1> let me find the paper...

<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)

<bhill> 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

<bhill> 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> bhill, I'd like it (be soft on deadline, though :) )

<bhill> :)

<bhill> we can look for a co-editor - that's usually a good idea, anyway

<gioma1> bhill, you?

<bhill> 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

<bhill> so we are going to break for lunch for the moment

<bhill> I think we should summarize this on the list, make a proposal

<bhill> and I'd like to propose gioma1 as an initial editor, and find another co-editor

<bhill> I think a browser person might be a better choice than myself since they'd know the guts of the implementation details

<bhill> but let's solicit on the list. David Huang might also be a better choice than I if he's free.

<bhill> thanks very much, Giorgio.

<gioma1> bhill, my pleasure

<bhill> we're going to be doing test development following lunch, so you can get some sleep if it's' that time of day there.

<bhill> :)

<scribe> scribe: bhill

Testjam session

<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> Ms2Ger's testharness.js testrunner

<odinho> RRSAgent: draft minutes

<puhley> I am working on access-control-sandboxed-iframe-denied.cgi, access-control-sandboxed-iframe-allow.cgi, and access-control-basic-whitelist-response-headers.cgi

<gopal> CORS has similar tests in opera and webkit folder. Our goal is it consolidate the tests and bring one set of tests to cors1.0 folder.

<gopal> I am working on testRunner, this will help us run all the rest with one click.

<odinho> I'm working on opera/js/basic.htm I*m removing it from using resources/cors-headers.php, because I just want all the tests to use cors-makeheader.php instead.

<puhley> Moving on to access-control-sandboxed-iframe-denied-without-wildcard.cgi

<odinho> I can review stuff if anyone wants.

<gopal> apt-get install hgview if you want some visualization of hg repo

<gopal> Try out the testRunner

<gopal> hg pull, you should have webappsec/tests/testRunner

<gopal> in your vm, add a symlink, ln -s /home/webappsec/tests/testRunner

<gopal> then http://www.w3c-test.org/testRunner/index.html

<gopal> I assume you have www.w3c-test.org in your /etc/hosts.

<gopal> If you add your .html file to MANIFEST, testRunner will pick it up automatically.

<odinho> If someone wants to help me with converting sync tests to async ones. THat'd be A+. Just ask, I'll point you to places to start.

<odinho> Hmmm. Actually CORS DOES work with Firefox(!), but withCredentials does not. Wat?

<odinho> Anyone know anything?