W3C

Web Application Security Working Group Teleconference

25 Sep 2012

See also: IRC log

Attendees

Present
Mozilla bhill2 ccarson dveditz ekr erlend fred gioma1 gopal jeffh mike mkswt mkwst odinho tanvi tobie
Regrets
Chair
bhill2, ekr
SV_MEETING_CHAIR
Scribe
tanvi

Contents


<trackbot> Date: 25 September 2012

<scribe> scribe: tanvi

trackbot-ng, start telcon

<trackbot> Meeting: Web Application Security Working Group Teleconference

<trackbot> Date: 25 September 2012

2: 01

Date: 25 September 2012

<ekr> meeting: Web Application Security Working Group Teleconference

<ekr> scribenick: tanvi

<scribe> meeting: Web Application Security Working Group Teleconference

<ekr> rrsgent, make logs

<jeffh> jeffh on phone

<erlend> erlend is on the phone

<ekr> fred, tobie, timeless, and velmont not actually here

<ekr> http://www.w3.org/2012/09/11-webappsec-minutes.html

ekr: approval from last weeks meeting notes
... http://www.w3.org/2012/09/11-webappsec-minutes.html
... agenda bashing? no issues

<bhill2> http://www.w3.org/2011/webappsec/minutes/WebAppSec-minutes-11-Sep-2012.html

<bhill2> edited minutes there

ekr: open issues. http://www.w3.org/2011/webappsec/track/issues/open
... no open issues.

<ekr> http://www.w3.org/2011/webappsec/track/actions/open

ekr: open actions - http://www.w3.org/2011/webappsec/track/actions/open

<ekr> http://www.w3.org/2011/webappsec/track/actions/76

ekr: most action items assigned to people who are not here today
... ACTION-76 assigned to gopal
... quite a few tests running. will go back and check

sorry...

gopal: quite a few tests running.  will go back and check

ekr: should we push out a couple weeks?

gopal: yeah. we are checking test coverage. we have a bunch of tests running, but dont' have an idea on what specific features are at risk.

ekr: issues on the mailing list to go over
... long thread about whether there is a privacy threat due to mandatory csp enforcement

mike: the one point i was clear of, was the concept of extensions in browsers potentially visibile to a website thats using csp
... if a resource from an extension violates the pages' policy. then server get a report saying that that resource violated csp
... and can determine what extension the user is running

dveditz: the extension part is real. working with twitter, there were more violations than should be, and some from addons
... nothing in the spec that would prevent the user agent from allowing addons to make an exception for themselves

??: spec says that extensiosn and addons shoudn't be affected by csp

dveditz: in right now firefox there are, but we consider that a bug

??: in webkit and chrome they are as well and we also consider that a bug

<fred> can it be avoided

dveditz: User agent. maybe i changed my user agent to xx to hide myself, but the csp errors show that i am actually firefox. coudl be a problem for the tor bundle (though right now it only uses firefox)
... so could turn of csp completely. but not the safest thing to do

??: creating a user agent in such a way that it enhances user privacy

(can ?? identify themselves)

??: spec is clear that extensions shouldn't affect csp. the spec is quite clear on this point. there is some discussion that user agents are having about how to do this.

<jeffh> ?? is apparently referring to the new W3C "Privacy Interest Group"

<erlend> /cgi-bin/blockpage.cgi?ws-session

dveditz: do noting to the spec, but firefox and webkit have bugs

<jeffh> http://www.w3.org/community/groups/proposed/#pua

<fred> fred is Fredrick Andrews

<mkwst> tanvi: ?? is me. :)

<mkwst> mike west.

dveditz: twitter encountered a lot more modified content

thanks mike

<ekr> whoever is ??P8 should tell zakim.

mkwst: if dealing with active network attacker, csp not helpful. which is why we request people use https

ekr: unsafe inline for style source

tanvi: what does unsafe-inline really mean for style-src?

dveditz: in principal we all agree, but some edge cases we have to work out
... the only one i dont entirely agree about is that you could argue that adding css text property is invoking the parser and therefore might coutn as inline styles
... otherwise agree with all the other DOM manipulations of inline style is not covered by inline style. directive intended to protect against injected content.

mkswt: write another email that says that

dveditz: implementation wise, it may be easier to drop this.
... still unclear, even after mail thread, about why we care so much about inline style
... the old browser that included executable like things. all the browser have dropped that dangerous stuff.
... although adam's comments about new css features are valid

ekr: dveditz still think about this some and then raise again if an issue
... moving on to next item...

tanvi: interaction of csp sandbox and meta tag

dveditz: 1.1 issue

tanvi: confused on the conclusion from the thread

ekr: bring it up on the next call when adam and jacob are here
... csp connect-src and browser plugins raised by erlend

erlend: thinking in terms of things like flash, can make http requests that include the cookies the user has at the time
... that is what brought up the subject

dveditz: i think the spec probably shoudl be clearer
... i know what we did in firefox, but after the issue was raised i realized we were sort of guessing. it's easy to promise more thatn the browser can deliver since plugins can mkae their own network requests independent of the browser
... some web author may think they are sandboxing more than they are

ekr: but then they wouldnt have access to cookies. ??

dveditz: sometimes they are just reading data. but often in playlist situation (ex: youtube), loading a whole new chunk of plugin content

ekr: final agenda item is on web crypto wg
... webcrypto wg announced FPWD

<ekr> http://www.w3.org/TR/WebCryptoAPI/

<ekr> http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2017/02/15 22:32:52 $