<jeffh> is aadd me ?

<abarth> Zakim: aabb is abarth

scribe is ekr

ScribeNick+ ekr

bhill: anhy objections to the previous minutes?

none seen.

bhill: friday wrapped up official call for consensus on CSP. No objections within WG to consensus. Some LC comments recorded as issues.

… if you object to moving to CR for CSP 1.0, speak now

no objections heard

bhill: on to issues.

… Issue 11

Issue 11: http://www.w3.org/2011/webappsec/track/issues/11

abarth: I don't understand this issue.

bhill: me neither

dveditz: it does reveal the CSP header, but it's the same server sending it out

… I don't think this is a users' issue. At most it's an attack from one server onto another

bhill: is this revealing information about the user's configuration that wouldn't have been anticipated by the CSP policy author.

dveditz: we o know that this happens

… twitter reported it, e.g., people's addons or carriers injecting content and then being blocked

bhill: this seems to be related to issue #17
... should we expand on this more in the implementation considerations

dveditz: does anything stop the UA from injecting policies?

if so, who cares.

a well-behaved add-on should take this into account

bhill: is this something we should add in implementation considerations?

abarth: right now just says don't interfere with operation of extensions but doesn't say how. Maybe add advice about providing some way to let add-ons modify polocy

… my instinct is to wait

bhill: this wouldn't need to be standardized
... will add notes to issues and close them out

moving to issues: http://www.w3.org/2011/webappsec/track/issues/12

http://www.w3.org/2011/webappsec/track/issues/15

abarth: for issue 12 decided to leave self but report document uri

… maybe we can wait since there is only one src doc implementation

… there was a thread with hickson but I forget what he wanted to do. let me find it

… discussion on June 24-29 on public webappsec. decided to wait until 1.1

bhill: will mark this as postpone and re-raise for 1.1

abarth: for src doc, there's no url so it's hard to express

Issue 16 is editorial: http://www.w3.org/2011/webappsec/track/issues/16

bhill: resolved to issue at CR and issue a call for implementations

No objections

bhill: will wait wor adam to tell me he's done
... next step is CORS

… issue is lacking an editor

… is there anyone extremely comfortable with CORS who could co-edit with cory

abarth: I could help out with htis

bhill: if you [abarth] could just help him get over the line. Mostly the comments from Jeff that are editorial/pedagogical
... probably will be ready to issue a CfC once we incorporate last set of changes
... last item is my proposed user safety stuff

<bhill21> http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html

bhill: I made a big edit pass...

… how to import definitions from CSP?

abarth: propose to reference the TR URL

<jeffh> http://www.w3.org/TR/CSP/

[bunch of discussion about editorial toolchain]

bhill: host-src is the current behavior of x-frame options

… with csp we could use a source expression so have more granularit

dveditz: default should respect host and port. agnostic about pathc

abarth: hoping to convince them to allow >1 source

dveditz: this seems more useful
... the problem is that if you can only do 1 you can't construct the CSP header until you have seen the refererer.

abarth: people to convince here are tobias and david ross

bhill: will bring them into the discussion

<jeffh> agreed

<jeffh> yes, this is fine for fpwd

… is this a good enough starting point for FPWD

general consensus yes

dveditz: even if ultimate consensus was only 1, still better han inventing something new

bhill: other options i frame ancestors CSP directive
... next directive is input protection

<dveditz> what list are we working through now?

this is the list of directives on http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html

<dveditz> thx

bhill: If we block an event due to policy should we raise anothr event

<scribe> [UNKNOWN]: maybe discuss this on the list since David isn't here

bhill: most issues have to do with script interfaces and reporting

… how about I raise these issues on the list

bhill: we have a little bit of time. Do we have odin and gopal?

gopal: trying to get in touch with odin. he had good luck with opera tests.

… and I have been having rpoblems with the tests

… once this starts running I will need to go annotate the tests for each section

… going to try t get a sense of the coverage and let peopl eknbow where to contribute

<erlend> Results from the tests so far: http://csptesting.herokuapp.com/home/results

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)

No ScribeNick specified.  Guessing ScribeNick: ekr
Inferring Scribes: ekr

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Mozilla P10 P4 P5 Velmont aaaa aabb aacc aadd aaee aaff aagg abarth annevk bhill bhill2 bhill21 ccarson dveditz ekr erlend gioma1 gopal jeffh ma1 mkwst odinho puhley tanvi timeless tobie trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0030.html
Got date from IRC log name: 11 Sep 2012
Guessing minutes URL: http://www.w3.org/2012/09/11-webappsec-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report