<scribe> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2019Feb/0002.html

News

dveditz: Our recharter was sent to AC

<mkwst> dveditz: Charter was presented to ACs.

dveditz: please ask your AC rep to vote

<dveditz> just plus feature-policy, more or less

mkwst: The scope hasn't changed, so please review and support
... we determined that Feature-Policy fit within existing scope
... just mention it explicitly
... Agenda review
... AOB?

Interesting specs in incubation.

mkwst: I picked out 5 things of interest
... there are likely more
... please jump in
... 1. Trusted Types
... https://github.com/WICG/trusted-types
... We are starting an origin trial in chrome
... in 73, as a dev, you can opt in to experimenting with this mechanism
... aiming for feedback on the API shape

trusted types draft

<dveditz> I'm personally excited by trusted-types, trying to drum up support inside Mozilla

scribe: 2. Mechanisms I hope will reduce passive fingerprinting surface
... User Agent and Lang client hints
... could in theory replace UA anc accept-language headers
... would like feedback
... Have heard some feedback from Privacy IG

mikeoneill_: generally good idea; interaction with feature-policy, and privacy risks with subresources
... we wanted to hear more information

mkwst: github repos are probably the right place for that kind of feedback, thanks
... 3. First Party Sets
... and early-stage proposal based on something Wilander posted
... builds on 2 proprietary systems, from Google and Apple, that allow origins to bind themselves together for use with application

first-party-sets

scribe: e.g. to bind orgins together for password management
... Mozilla has something conceptually similar
... for tracking protection

dveditz: hard-coded within Mozilla, on the website (not in FF)

mkwst: mechanism allowing entities to bind themselves together

<mikeoneill_> +q

mkwst: this proposal aims to create a non-proprietary mechanism for creating those associations
... need feedback
... would be nice to standardize

<dveditz> "conceptually similar" but not suitable for the same purpose.

mikeoneill_: noted on github that "-" interferes with javascript
... I thought this was what origin-policy was about
... put things in one place to minimize round trips

mkwst: we'll figure out spellings
... wrt origin policy, Mozilla wanted to decouple because they weren't sure they were going to implement origin policy
... so trying to increase deployability

mikeoneill_: what behavior is first-party-sets going to change?

<mkwst> https://github.com/mikewest/first-party-sets#what-exactly-does-first-partyness-enable

mkwst: ^ the use cases of interest
... blocking third-party cookies, credential-sharing, process isolation

<dveditz> +q

wilander: We raised this in ~2016
... still think it's interesting
... we also worry that consortia will be formed for the sole purpose of collapsing domain names for the purpose of tracking users across wildly different things
... if this introduces financial incentive to create groups of domains for tracking
... mostly in favor of grouping together ETLD+1
... because that can match user understanding

mkwst: agree that something like this can create opportunities for abuse. Try to address in explainer
... welcome feedback on explanations of abuse and mitigations
... For the one entity with several TLDs, sometimes different heuristics work. e.g. Google doesn't always have all google.*

<dveditz> at least before the lawyers found them

wilander: I didn't mean automatic

dveditz: you're explicitly not talking about relaxing same-origin policy

mkwst: indeed. I think the notion of party is more malleable

<dveditz> heh, I'm not sure having the advertisers like this is an endorsement I want

wseltzer: also note interest from Web Advertising BG

mkwst: 4. Fetch metadata, which used to be called sec-metadata
... https://mikewest.github.io/sec-metadata/
... 4 elements of metadata
... destination
... same-site, same-origin, or cross-site
... whether or not user-involvement
... cors-mode
... allowing better risk-assessments
... chrome has implementation behind a flag. seeking feedback
... Google's experimentation finds it pretty valuable

mikeoneill_: I tried this, enabling in Chrome, and then couldn't log into bank

mkwst: suspect that was an older version of chrome
... we changed the header format
... because of incompatibility at web application firewalls, and header compression concerns from TAG
... suggest trying in canary, file bug reports for chrome at crbug.com, or for spec at the github repo

dveditz: does the header format problem mean we can't consider JSON?

mkwst: this wasn't JSON, but structured header
... there was a target attribute, and web application firewalls were blocking
... because they interpreted it as HTML injection
... changed format and it now works.
... 5. The `Cross-Origin` response header
... proposal from AvK with browser feedback
... enforce CORS-only mode for documents
... because of spectre, we no longer believe it's safe to pull content into process
... unless the content has agreed to be pulled into the renderer process
... memory space attacks
... Proposal: only enable certain interesting APIs on a page where we guarantee that everything on the page has done the CORS dance
... please look at https://gist.github.com/annevk/17f580379c45802d5c3aef5a8fd53c7d
... and give feedback
... Any other specs you'd like to bring to this group's attention?

This call.

mkwst: I would like to make this call effective to people
... Consider timing
... How often?
... Mode?
... alternatives to telephone?
... Scribing?
... other groups use a more collaborative environment
... e.g. cryptpad, googledocs
... Thoughts on how we could be more effective?

<mkwst> wseltzer: Thanks for raising this.

<mkwst> ... Certainly if we're going to continue with sync. calls, we should find a good time for them.

<mkwst> ... A feature that we could use that calls for regular calls would be driving progress on specific specs.

<mkwst> ... Drive people to review issues, see what's ready to proceed each time.

<mkwst> ... I've also seen other groups using other tools, would be happy to explore them.

<mkwst> ... We're trying to make these WGs useful to participants, so, what else could we be doing that would make webappsec more useful to you?

<mkwst> mikeoneill_: What's the experience with what the TAG uses?

<dveditz> <somebody> uses https://cryptpad.fr/

mkwst: TAG uses cryptpad for reviews

<dveditz> or maybe a self-hosted one

mkwst: Multiple people can type into the same text box simultaneously
... and edit (with using sed commands)

<weiler> TAG uses appear.in for video, which I have issues with - permissions issues, oddly enough

mkwst: It's also a phone call
... or video
... always an exciting experience as they switch among services

mikeoneill_: I've used slack for typing

<weiler> I've seen IETF groups use Etherpad for collective notes; google docs works great, too.

dveditz: hear mkwst angling for more presence

mkwst: as I'm talking with people, I find it helpful to see them
... most services also offer the opportunity to turn off video and do voice-only

dveditz: it would be nice if we could pick a service that allows phone

<mkwst> wseltzer: webex does have a video mode.

<mkwst> ... Doesn't have multiple-people-on-the-screen mode of some other services, but we have access through W3C, so it might be helpful.

<mkwst> dveditz: Is there a smartphone version of webex?

<mkwst> wseltzer: I use it on Android. It works fine.

<mkwst> ... Others use it on iPhones.

[and in browsers]

<weiler> I'm fine with a push for video.

mkwst: I'll start a mailing list thread on some options

dveditz: it's tricky to talk about time with those who can make it to this call

mkwst: 6pm is Europe dinner time, so that's tough for me
... I'm looking for feedback from those who currently attend
... and those who don't
... for me personally, later is better

wilander: current time is 9am California, so later would also work better for me

mkwst: think about where people are, and what times are good for them
... for example, are there people in Asia who would participate

mikeoneill_: I also don't mind later

<weiler> US eastern time here; meetings in the evening my time can be tricky.

mkwst: I'll send email to list soliciting suggestions
... which we can narrow with a doodle

<mkwst> wseltzer: News. webauthn is getting close to REC on that spec.

[adjourned]

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/metatada/metadata, which used to be called sec metadata/
Succeeded: s/sec metadata/sec-metadata/
Present: mkwst weiler wseltzer dveditz iclelland mikeoneill_ wilander gmaone ArturJanc
No ScribeNick specified.  Guessing ScribeNick: wseltzer
Inferring Scribes: wseltzer
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2019Feb/0002.html

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

Found Date: 20 Feb 2019
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.)