<trackbot> Date: 05 October 2015

<bhill2> Rob Trace is replacing David Walp from MSFT on this group and browser team

<crispin_microsoft> +present

<bhill2> Mike O'Neill is from the TPWG and interested in Permissions API.

<bblfish> Do you want me to introduce myself

<bblfish> ?

<bhill2> Henry, are you on the phone?

<bblfish> yes

Minutes Approval

<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-09-21-webappsec-minutes.html

<bhill2> hearing no objections, minutes approved

News

bhill2: TPAC is coming. Brace yourselves.
... Dan will run the next call, I'm out.
... Think about agenda items.
... Good chance to brainstorm, collaborate with other groups, etc.
... Remote participation?
... If you're interested, let me know.
... One More Thing:

<deian> I think I can make it in person, but should know for sure in the next few days. (If I can't remote join would be great.)

bhill2: Time slot for the meeting. Perhaps we should alternate again after TPAC?

<terri> Alas, my regrets for TPAC. It's looking highly unlikely that I'll get travel budget approval at this point

bhill2: Next call, same time. Perhaps change the call after that.

<bhill2> mkwst: We have one repo per-spec now, except CSP which has a couple

<bhill2> ... should be more clear as we go forward with that spec

<bhill2> ... github.com/w3c/webappsec has a nice table linking to current editor's drafts, history is preserved, but issues haven't been migrated

<bhill2> ... hoping editors can migrate their own spec's issues

<bhill2> ... not clear there's a lot of value in doing so

<bhill2> ... probably best to put new issues in new repos and let old ones die out as they are resolved

<bhill2> (jww and mkwst note that the way to indicate to do this is to reply to issues opened in wrong repo)

Permissions API

<wseltzer> https://w3c.github.io/permissions/

<bhill2> mounir: last time we discussed being able to revoke

<bblfish> https://w3c.github.io/permissions/

<bhill2> ... extended request is added, is behind a flag

<jww> mkwst: no worries, I got it :-)

<bhill2> ... a few things need to be handled after that, new things for the API

<bhill2> ... some related to WebRTC we need to take care of

<bhill2> ... and for NFC

<bhill2> ... and whether to have those new permissions live in this spec or delegate to the other APIs and specs

<bhill2> ... at moment spec has a big TODO to finish, then we can heartbeat the draft

dveditz: Would prefer to not extend this spec. Modifying spec involves overhead.
... Perhaps makes sense to add pieces elsewhere and reference them.
... Would be nice to have a section in this spec to explain how to extend the spec.

mounir: I tend to agree with that.
... Opened a bug against WebIDL to have partial enums.
... Some folks very against that idea.
... That's why I'm doing things on the side.
... Need to see if folks will change their minds.
... Will try to make that happen.

mikeoneill: Posted to the list, asking about extensions.
... https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0207.html
... Will there be a procedure for extending? Registry, etc?

mounir: Don't know how much extensions should be part of the code of the API.
... FirefoxOS has their own way of doing permissions.
... Not clear to me that we need to specify that part in the document.
... If someone has an opinion, I'd love to hear it.

mikeoneill: At the moment, there are just the four permissions.
... WebRTC, for instance.
... When they come up, is there going to be a procedure for allocating a name for them, publishing a dictionary?

bhill2: Seems like the simplest way to do that is with an IANA registry.
... They exist for exactly this purpose.

mikeoneill: Any discussion about that?

mounir: Same as the first question from dveditz.
... Having a registry, having something in the spec, seem like reasonable solutions.

dveditz: Other thing not in the spec is a section on security.
... I know some things like push need to be on a secure site.

<bhill2> (I would tend to lean towards going with an IANA registry as the default idea unless there is good reason to do otherwise.)

dveditz: Geolocation headed that way.
... Should at least note that some permissions will require a secure context.

mounir: Already say that permissions are linked to origins.
... I think "secure or not" is already mentioned.

bhill2: I don't see "secure" or "https" in the body of the spec.

dveditz: In any case, most recent specs have a "security considerations" section.
... Should at least say "There aren't any."
... These things were considered, these discussions were had, etc.

<bblfish> there should probably even be privacy considerations, ( realaying from the Privcay WG )

<wseltzer> +1 to Security Considerations. There is already a Privacy Considerations

dveditz: Will be easier to get through approvals if you have such a section.
... Otherwise, kneejerk rejections.

wseltzer: Good work already having a "privacy considerations" section.

dveditz: Yup, I noticed that. Thank you.

bhill2: Anything else?

<bblfish> :-)

Upgrade Insecure Requests

<bhill2> mkwst: implemented in Chrome & FF and on W3C website for about a day

<wseltzer> https://w3c.github.io/webappsec/specs/upgrade/

<bhill2> ... implementation in browsers seems to work the way it is supposed to

<wseltzer> now at https://w3c.github.io/webappsec-upgrade-insecure-requests/

<bhill2> ... transition request submitted, first attempt blocked to resolve reference issues with Workers and review from WebApps

<bhill2> ... hoping transition request will resolve in the near future. Secure Contexts is next and has many of the same transition request issues.

<bhill2> wseltzer: will be speaking with Ralph acting as Director's designate re: this transition request

<bhill2> dveditz: done in Firefox but signaling header not implemented yet

<bhill2> ... in FF43

<bhill2> mkwst: next steps are create a test suite

<bhill2> dveditz: actually in 42, so released 1st week of November

<bhill2> http://webappsec-test.info/~bhill2/DifferentTakeOnOE.html

bhill2: I wrote an explainer doc after our Berlin meeting.
... Interest in exploring that document.
... Probably a breakout session at TPAC.
... If you're interested in helping, I'd be very interested in comments and participation.

Clear Site Data

<deian> +1 I gave it a read last night, I really like the idea

<bhill2> mkwst: not much since FPWD

<wseltzer> https://w3c.github.io/webappsec-clear-site-data/

<bhill2> ... some interest from Google in using this feature, may have someone lined up to implement in Q4 so we can see if it solves the problems we think

<bhill2> ... includesSubdomains is less important to google than I thought, and we probably won't use it

<bhill2> ... so I would like to remove it if there are no other use cases

<bhill2> dveditz: can be used destructively, so needs extra considerations if we leave it in

<bhill2> ... this assumes that superdomain owns subdomains in many specs, but can cause problems when not strictly true

<bhill2> mkwst: can remove a lot of complexity if we remove the feature

<bhill2> ... feedback appreciated, esp from other implementers and users!

<bhill2> mikeoneill: has anyone discussed having a time-delay on this?

<bhill2> mkwst: makes sense to me as a browser feature that a user could opt themselves into

<bhill2> ... less clear to me that an origin having a self destruct would be useful

<bhill2> mikeoneill: site might want to extend control to the user, like with cookies to time out storage

<bhill2> mkwst: sounds more like an expiration for things like local storage, but that's a bit of a distinct use case from this app

<bhill2> ... this is more for a logout case

<bhill2> ... e.g. google+, docs, to make sure that offline cached stuff is removed when you log out

<wseltzer> https://www.w3.org/wiki/TPAC/2015/SessionIdeas

<bhill2> wseltzer: if you are thinking of TPAC, Wednesday is the plenary day, submit ideas

<dveditz> heh

<bhill2> ack

<bhill2> ack CSP3...

<dveditz> Zakim: ack CSP3

<bhill2> mkwst: CSP3 is starting to shape up, good time for folks interested in integration with Fetch and HTML to take a look and comment

<bhill2> ack update:

francois: SRI is basically ready for the next step.
... merged all the outstanding PRs.
... resolved all issues before LC/RC.
... What's the next step?
... Ask the chair to take it for wide review?

bhill2: Next step is to document the review and implementation experience we have.
... Send it for comments to places that might be interested (IETF?)
... Two implementations + test suite mean that we can probably rapidly advance to CR.

francois: Next step is to write to the list? Ask for people who might be interested?

bhill2: Yup. That'd be great.
... Can point to blog posts (GitHub, etc) as well.
... Qualifies as part of "wide review".
... Excited to take that to CR. Awesome.

<bblfish> which one is going to CR?

wseltzer: Good work group in getting so many specs moving forward.

bblfish: SRI.

(and Upgrade.)

(and Secure Contexts.)

<bblfish> ah this one: https://w3c.github.io/webappsec-subresource-integrity/

bhill2: Bye!

<bblfish> thanks

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/own way of doing extensions./own way of doing permissions./
No ScribeNick specified.  Guessing ScribeNick: mkwst
Inferring Scribes: mkwst
Default Present: bhill2, mkwst, francois, dveditz, wseltzer, estark, jww, terri, ckerschb, JonathanKingston, mikeoneill, moneill2, mounir, crispin, rob_trace, present, deian
Present: bhill2 mkwst francois dveditz wseltzer estark jww terri ckerschb JonathanKingston mikeoneill moneill2 mounir crispin rob_trace deian
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0005.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 05 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/05-webappsec-minutes.html
People with action items: