<wseltzer> scribenick: wseltzer

<jeffh> scribenick: jeffh

Agenda Bashing

Minutes Approval

<dveditz> https://www.w3.org/2018/03/21-webappsec-minutes.html

dveditz: any obj to adopting minutes from last meeting
... not hearing any, minuted adopted/approved

News

<dveditz> * Limit lifetime of cookies delivered via plaintext

<dveditz> * https://github.com/mikewest/cookies-over-http-bad

<dveditz> * https://github.com/w3ctag/design-reviews/issues/239

dveditz: summarizes MikeWest's proposals

CSP

dveditz: is John Wilander on the call? not hearing him, will skip the `.well-known/modify-credentials` topic for now....
... skipping to CSP

<dveditz> * Hashed attributes, inline attributes, and versioning

<dveditz> *

<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2018Apr/0017.html

<dveditz> *

<dveditz> https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit?usp=sharing

<andy_paicu_> yes

dveditz: knows some moz folk think `unsafe-inline-attrs` would be useful and less dangerous than `inline-attrs`

<wseltzer> # Explainer: ‘unsafe-hashed-attributes’, ‘unsafe-inline-attributes’ and CSP directive versioning

andy_paicu_: main problem with hashed attrs (?) is .... if a handler is authz'd by hash, any occurrance of it in a page is authz'd rather than a specific instance, see the explainer

dveditz: and you also raise the versioning issue which we've had since the beginning of CSP

andy_paicu_: an option is to add a versioning mech that is understood by CSP 3 UAs, and some sort of syntax for ? that earlier UAs can understand
... that is one option, another option is to split directives to be per attr / per element, so eg can spec policies for style attrs that dont apply to style elements

dveditz: how many groups in goog are interested in this?

ArturJanc: in goog there's only one group that's deployed CSP and that's us, and this proposal addresses two use cases we've seen....
... [ something about being able to whitelist things that ought to occur in a given doc and we can automagically make it safe ]
... apps that need to whitelist one or two inline event handlers eg that come from an imported lib.... externally we see folks having dependencies on this sort of inline script and they could handle it by whitelisting said handlers via CSP
... script-source-for-attrs and -for-elements (?) would help address this... (much paraphrasing here)

andy_paicu_: currently if u want to whitelist a event handler, u are forced to use `unsafe-inline` and then u loose protections. so being able to whitelist specific handlers will make things safer

dveditz: the alternatives for inline hashes for attrs, motivations for that are pretty clear, and then the complication is versioning such that make it bkwd compat for ur site does not break on old browsers
... have not heard anyone object to unsafe-inline-attrs or -hashes
... being able to restrict the scope of unsafe-inline seems useful....really a matter of how we make it work....which is why u raised the former issue.....
... is the chrome team innarested in this?

andy_paicu_: unsafe-hashtag is already impl'd in chrome behind a flag
... imagine that unsafe-inline-attrs is easier to impl...

dveditz: so ur gaining experience on this and how to make work for older browsers so that will be good info....

arturjanc: directives work slightly differently (?) ... anyone have higher level objs to these proposals .... one is that the spelling can be cumbersome and not easy to understand by webdevs.... wud be good to decide which one is "nicer" and go with it....

dveditz: any other questions for these folks?
... christoph?

christoph: need to study the explainer first

Cross-origin load limitations

dveditz: specifically from-origin has gotten interest

<dveditz> * `From-Origin` https://github.com/whatwg/fetch/issues/687

<dveditz> * https://www.w3.org/TR/from-origin/

https://github.com/whatwg/fetch/issues/687

dveditz: from-origin is sort of like x-frame-options, but for individ resources rather than framing.... if being loaded by site X but from-orig says "only ABC" then no load....
... does raise issues wrt ordering of constituencies
... is one way to help with site isolation concept
... John W. innarested in this one also....

<dveditz> `Sec-Site`

<dveditz> * https://github.com/whatwg/fetch/issues/700

dveditz: somewhat similar proposal is `sec-site`
... something bwsr can send to site

tanvi: indicates if the (requested?) load is cross-site (?)

<tanvi> or same site

dveditz: hm if blocking referrer then prob want to block sec-site...
... proposal is for "registered domain"
... reason for sec- prefix is cant be set in JS
... so those are complementary proposals
... is not clear to me if folks want both things to be adopted

arturjanc: from what ive seen, folks like the complementary aspects of this
... potentially, there is room in the platform to have both of them and it'd be useful -- sec-site is server-side enforcmnt, from-orig is client-side
... have started writing a doc on this -- both address long-standing cross-orig leaks, so we ought to consider if we can use this to solve such large prob, and more generic protections on cross-orig resource loads may help with Spectre as well as brws-level issues

dveditz: tanvi, u have concerns wrt from-origin to be used diabolically to leak who's in the stack?

tanvi: yes, rather than using FQDN use subdomains etc, but artur indicates that might make it not work at all.
... from-origin u can spec in 2 ways, ie same-site, cross-site, keep it kind of vague. or spec it to be a list of specific origins, then site A embed site B, but then site A can pull image from site B if has from-origin that lists A & B, but then when load occurs site B learns who loading it, not wanted leak all the time, presently this blocked in FF

dveditz: [asks artur a complex variation of above scenario]

<tanvi> essentially, do we need to look at frame ancesotrs, or just the current document?

<tanvi> are there are attacks if we do the later

arturjanc: am fan of taking approach of having from-origin only look at orig of current doc, rather than entire ancestor chain, cuz could be obstacle to deployment
... otherwise things will break in pages and page has no control over...

tanvi: question is whether there is an attack because if complete ancestor chain is not checked

arturjanc: concerned about embedding all the isolation features into from-orig and sec-site, eg if they have to remove doc.domain, embeddings, will see less adoption....
... would rather keep the from-origin scope small, and anyting that remains we address using separate features
... if too broad folks cant use the feature/directive

`Feature-Policy` and Permissions API

dveditz: not sure this has been discussed...?
... wseltzer sent us this?

wseltzer: quest from other WGs that wish to rely on those in references
... as things move towards REC, want to see if the ref'd things may be something webappsec take up and make progress on them, eg `Feature-Policy` and Permissions API
... with end result being they are something we can rely on across the web

dveditz: webplatform/webapp group gave us Permissions API and we havent really worked on it, there is activity in the github repo, wonder if we can give this spec back to them

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

dveditz: feature-policy is something mkwst wants webappsec to adopt, chrome has been impl'g this behind a flag?

<wseltzer> https://wicg.github.io/feature-policy/

dveditz: this is renamed to origin-manifest ? been experimented with?

<estark> are we talking about feature policy or origin manifests (formerly origin policy)?

arturjanc: no experiments yet, but there is interest in them, have sorme origins that could use origin-policy with them

<dveditz> estark: I was asking about both

<dveditz> as "interesting things our group could adopt from WICG"

arturjanc: emily estark might know more?

estark: confused cuz talking about both at same time
... thinks feature-policy is shipped
... origin-manifest is perhaps prototyped

<wseltzer> https://github.com/WICG/origin-policy

estark: so we webappsec are talking about possibly adopting both of these?

dveditz: knows folks innarested in both

estark: understanding of feature-policy is that it can be construed to be sec-related, but has various perf-related non-sec use cases....

wseltzer: my goal to encourage discussion of these items.
... webrtc and device-sensors have most immediate interest in these

<estark> feature policy status in Chrome: https://www.chromestatus.com/feature/5694225681219584

<estark> Chrome 60

wseltzer: these could be useful to sites employing webrtc and such
... will followup on mailing list wrt these items

dveditz: wrt permissions in particular, will get with mike to talk wtih the spec editors to find out where it really belongs....is not being dicsussed on webappsec
... need to talk with webplatform folks?

wseltzer: will reach out to the team contacts for that WG and for webperf

anyting else?

arturjanc: further discuss concern Tanvi has wrt the knowledge leak discussed above.....

tanvi: referrer is not reliable (as you have said before) -- can be stripped/spoofed. eg FF has feature where u can always set referrer to the site page is makeing request too. dont want to create a new vector such that we have to apply same things for referrer as the proposed header....
... if can make things more generalized (?) might be better

arturjanc: [ wonders about various simple-to-complex use cases and how useful for webdevs they are....]
... wonders if we can figure out some sort of opt-in for origins (to simplify all this?)

tanvi: are there more reasons that referrer is not reliable

?

arturjanc: sites have to expect that referrer will not always be present
... the webapp cant block reqs w/o referrer
... means cross-orig attacker can strip referer and webapp cant ignore those reqs

tanvi: if we make this header work same as referer, then both break in same way.....

arturjanc: thinks u r right

tanvi: this is case even if the referer stripping is done by browser eg a user pref
... so maybe if user reqs supress of referer, then we send vague response... ?

dveditz: thinks FF is only one with that pref, but there is 3d party stuff that gives user that pref

tanvi: seems we r just re-inventing referer, need to think more about this.....

meeting end....

adios

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/any u/and you/
Present: weiler wseltzer dveditz terri jeffh francois estark ckerschb__ ArturJanc tanvi gmaone
Regrets: mkwst
Found ScribeNick: wseltzer
WARNING: No scribe lines found matching ScribeNick pattern: <wseltzer> ...
Found ScribeNick: jeffh
Inferring Scribes: wseltzer, jeffh
Scribes: wseltzer, jeffh
ScribeNicks: wseltzer, jeffh
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2018Apr/0043.html
Found Date: 18 Apr 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)