See also: IRC log
<scribe> Scribe: Brad Hill
<scribe> Scribenick: bhill2
folks, I have internal approval, but the process for me to officially re-join hasn't completed yet, so I'm just going to be silent scribe today
<dveditz> bhill2: do you have a different link to the minutes from last time?
oh, yes
sorry, my agenda script doesn't know about skipped meetings
last minutes were at:
http://www.w3.org/2014/09/10-webappsec-minutes.html
http://www.w3.org/2014/09/10-webappsec-minutes.html
<mgoodwin> dveditz: I am here; I have no idea if you can hear me
<dveditz> yes, we can
dveditz: reminder, TPAC is
coming. today is last day to register at the lower cost
rate
... cutoff may be USA Eastern close-of-business, not sure
dan, I can't run the tracker today, sorry - I'm not authorized as a non-member
<tanvi> sorry, had to step away for a minute
dveditz: Next meeting is Monday, Oct 20 at 12:00 noon USA Pacific Time
<dveditz> http://www.w3.org/2011/webappsec/track/actions/open?sort=owner
dveditz: update your GitHub issues, too before TPAC
https://github.com/w3c/webappsec/issues
argh...
http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0011.html
<tanvi> chromes implementation isn't touching caching yet
<tanvi> of sri
mkwst: an experimental implementation my jww will hit Chrome canary tomorrow
<tanvi> enforces everythign is cors same origin, publicly cachable
mkwst: we are not touching
caching at the moment
... very interested in the possible performance benefits of
content addressable caching
... but erring on the side of caution for now
... need to be very careful in working those issues out before
proceeding there
... current interest exists for the feature just in integrity
verifying mode, expressed by e.g. GitHub
dveditz: concerns if servers give different content to different users
<tanvi> mkwst: hoping that resources that depend on cookies aren't publicly cachable.
mkwst: we hope we've addressed
this by only allowing integrity verifying things that are
marked as publicly cachable
... also rely on good hashes for this, need ways to migrate in
the future
dveditz: we could still use the
integrity properties without the caching properties even if
hashes are found to be weak
... mozilla has started work on implementing this as well, will
try to get feedback on that
<mkwst> https://github.com/w3c/web-platform-tests/pull/1275
mkwst: someone at github has started putting tests into web platform tests
attributes or ni:// uris?
http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0010.html
bhill2: need to resolve the tension between using multiple hashes to indicate multiple valid content vs. defense-in depth hashing
mkwst: use cases for both exist, may need a toggle
(dan, I'm having a bit of trouble hearing you)
http://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0003.html
(aha, that helped a lot, thanks mike)
<mgoodwin> that's better.
ISSUE look into JSONP protections for CSP v.Next
A long time ago I proposed: http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/att-0030/JSONPDirectiveStrawman.html
wasn't much interest at the time
http://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0074.html
this is probably work for the IETF HTTP WG
would it solve problems for us that it is worth proposing to them?
dveditz: not a lot of interest apparent, if nobody wants to champion it on the list will probably just leave it
http://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0106.html
mkwst: boils down to the same question about information leakage, needs to be addressed
yeah, sorry - the subject line looked different when I was building the agenda
dveditz: yes, we have another
thread about this, not too much worse than you can already get
from cache timing and other detection
... think we can address this thread in the same action as the
earlier one
http://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0072.html
dveditz: mostly spec nits, need to make sure they are clarified
mkwst: yes, reasonable to file an action against it
<dveditz> ACTION: address Integrity spec clarifications in Angel Gonzalez's mail [recorded in http://www.w3.org/2014/10/08-webappsec-minutes.html#action01]
<trackbot> Error finding 'address'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
http://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0080.html
mkwst: one of the basic problems
we want to solve is contention between public and private
urls
... keep the web from accessing your local machine and things
on your local network
... is about protecting the user, not just the web
... is in conflict with what some developers want to do -
install a local server and connect to it from the web
... I don't know how to do it safely. CORS headers are one way
- if server explicitly allows it, but doesn't give user control
over what's going on
... also makes the distinction a bit muddy
... it's an important question
... my tendency is to come down on the side of blocking more
than we allow
... but should explore means to do this
other issue - is this orthogonal to what is in MIX - should it happen elsewhere?
mkwst: irrelevant - question
doesn't go away, conceptually its very similar
... insecure resource loading changes properties of the secure
environment, loading private content into a public resource is
similar conceptually
... if folks wanted to split it out, could do that
wonder if IoT will make this much more relevant, and creating a new spec focused on bridging public/private networks may bring additional participation from experts in that community
mkwst: yes, if we want to allow it, but if we just want to lock it down, makes sense to keep it in MIX
tanvi: does chrome block it today?
mkwst: yes, but by virtue of our
considering it insecure
... localhost is insecure because it's almost always loaded
over http
tanvi: firefox does the same
mkwst: getting a good amount of pushback from folks interested in these local server deployments, at the moment they intentionally don't work
tanvi: if it's already implemented this way, we aren't breaking compat
mkwst: yes, except that there are
things on my local network with self-signed certs I've
accepted
... we added some measurements to chrome
... see how much private stuff being included in public
webpages, get a feel for the impact
dveditz: believe opera has
blocked such for a long time
... may have feedback, but people with problems may just switch
to another browser
mkwst: right now 0.04% of pages have this
<mkwst> https://www.chromestatus.com/metrics/feature/popularity#MixedContentPrivateHostnameInPublicHostname
mkwst: this for the moment is just a flat list of yesterday's values
http://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0081.html
dveditz: please propose new
topics we might want to standardize, things that are coming
up
... webcrypto group will be meeting at TPAC as well
terri: they are on Thursday, I think
mkwst: credential management unofficial draft I've been working on - not clear to me what group should be publishing that
<mkwst> http://mikewest.github.io/credentialmanagement/spec/
mkwst: this group, webcrypto, webapps all come to mind, I'd like to consider that at some point
tanvi: +1
<mkwst> also http://mikewest.github.io/credentialmanagement/writeonly/
terri: +1, know web crypto is looking at more authN related stuff
mkwst: some overlap, also with
stuff like FIDO Alliance, argument to be made to move it into
that sort of group
... may be a new group spinning up out of web crypto next
workshop
... doing a prototype in chrome in hopes some group will find
room for it in charter, not optimistic until after TPAC
... potentially more relevant is writeonly link and an opaque
formdata element
dveditz: current experience is that websites try to disable password managers with autocomplete='off'
mkwst: hope that making this
explicit vs. heuristic might change that trend
... credentials community group also proposed
http://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0040.html
dveditz: thread on how to address RTC, believe mike has a tracker item for it?
mkwst: yes something we can consider for v.next
dveditz: seems odd to have
another rich data source that impacts what happens in the page
with no CSP control
... but not clear what makes sense in a peer context
... other than to disallow peer connections in a page
mkwst: agree we need something,
but don't know enough to know what they should be
... proposal looks sane but very coarse-grained
(maybe we can ask EKR?)
<terri> I might be able to ask some folk who are internal to me; will check
tanvi: what hours are we doing at TPAC?
dveditz: schedule on site
generally 9-5 with break for lunch, will try to get a schedule out
dveditz: reminder: new time and day, Monday, noon, 20th, for next call
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/tanvi/terri/ Found Scribe: Brad Hill Found ScribeNick: bhill2 Default Present: BHill, gmaone, dveditz, +1.310.597.aaaa, mkwst, +1.503.712.aabb, terri, +1.310.597.aacc, mgoodwin, tanvi, +1.781.262.aadd Present: BHill gmaone dveditz +1.310.597.aaaa mkwst +1.503.712.aabb terri +1.310.597.aacc mgoodwin tanvi +1.781.262.aadd Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0012.html Got date from IRC log name: 08 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/08-webappsec-minutes.html People with action items: address[End of scribe.perl diagnostic output]