<CraigSpiezle> Can you forward the dial in number?

<tara> Hullo all, waiting for more folks to join...

<jnovak_> present_

Agenda item 1 - update on PING docs

Jason: questionnaire working on integrating feedback from TAG; swap ordering and simplify, making good progress

Tara: need help?

Jason: in hand, but please feel free to look at PR

<CraigSpiezle> Can you forward the dial in number?

Jason: will post in IRC

<jnovak> https://github.com/w3ctag/security-questionnaire/pull/50

Pete: a couple of comments on mailing list; will write up in a more formal way; ready for next meeting (re private browsing)
... some question about broadening scope - would like more specific feedback on that

Tara - seeing no feedback, seems like a good idea to proceed as planned

Agenda item 2 - privacy considerations of inaccessability of CAPTCHA

Nick: feedback requested by last week

sent them an email roughly along the lines of what I discussed with this group

no response as yet

a lot of privacy and security topics that would benefit from more detail - optimistic that the feedback will help them

Tara: comments by 15th?

Sam: do not consider as a hard deadline
... they are looking for help to clean up privacy and security text -

Tara: still a window for comments and they would appreciate assistance

Pete: how best to offer to help?

Sam: github issues probably the best

ask the document editors

Agenda item 3 - Discussion tools

Tara: what might we do to improve discussions? alternate tools?

looking at a potential Slack instance for ongoing discussions

<npdoty> privacy and security issues re Inaccessibility of CAPTCHA email: https://lists.w3.org/Archives/Public/public-apa/2019Mar/0010.html

<weiler> WebAppSec tried cryptopad for minutes earlier this week.

looking at shared document writing - e.g. a minutes document, group writing for minutes (for example), e.g. cryptpad

zoom?

looking also at zoom

very experimental - starting a discussion to see what people might like to try/use

<tara> Christine: Other groups found zoom helpful for interactive discussiob

<CraigSpiezle> I find Zoom to be very good and easy to use. The video is a nice option for those that want to enable it

<tara> jnovak: did you mean video on zoom?

<tara> jnovak: videoconf makes sense; webex also supports video though?

Jason: two questions - did you mean video conference? webex supports video
... on the question of a slack or some such - what is the goal of a new communication medium - Slack is often seen as more casual than email or other form of chat - some perhaps a more casual environment might be useful - but need a set of expectations as to what we are trying to do

Tara: yes, thinking was more informal - email does not lend itself to quick questions or small interactions - we also have to think about how to move to public space

but downside is there is another channel to monitor

Jason: maybe we could borrow best practices from someone who uses slack

<npdoty> have we considered using this IRC channel as a public, casual discussion point?

<npdoty> there are some WGs that use nicely logged IRC channels for that kind of thing

jason: nick commented about IRC - question for Tara and Nick - do we want this to public or private casual venue?

Tara: thinking more private casual but only because slack is more account focused

so members of this group would have to be put in

<pes> were (Brave) is a slack shop. Its handy and works well, but downsides are 1) onboarding is difficult 2) creating a public record takes additional tools 3) not a huge endorsement for the “web is a useful open platform” optic :)

Jason: value to having private communication venues for topics, but also important to have an ethos about what needs to be public and when

Tara: as Pete points out - need to remember about open Web, public nature of work etc. - how to find the right balance
... Pete what did you mean on mailing list re forum?

Pete: could be PHBP instance or reddit subgroup or ... depends on formality

<npdoty> we could even have a Slack that was bridged to the IRC channel and then publicly logged

Tara: Slack not proposed as the only solution, just an idea

<jnovak> one ask I have is to use something that has mobile support etc.

<npdoty> Discourse is being used for WICG discussions, which is topic-based

Agenda item 4 - AC meeting coming up

<npdoty> what are the planned privacy discussions?

Tara: privacy discussion at AC, what is happening at PING, and in other groups - Tara, Sam and others will be there

<pes> (pete will be at AC meeting too)

<tara> See you there, Pete! :-)

Sam: I do want to talk about TPAC? WGs you would like to go to other than WebAppsSec and WebAuth?

needs response by June or July

<pes> one vote for keeping WebPayments from conflicting with PING

Jason: a little hard to say this far out - maybe keep a running list in Github

<tara> https://www.w3.org/2019/04/AC/ac-agenda.html

Tara: re Nick's question, see the agenda above

Wendy: my perspective - an important piece - send more participants to PING, early consideration of privacy in spec dev and review

sam and tara will be participating - many channels - if something you would like to send a message can do that

<wseltzer> [and PES, I believe]

Agenda item 5 - Mike's draft

https://github.com/w3c/web-advertising/blob/master/serverdeclaration.md

Tara: have people had a chance to look at the document and have initial feedback? but mike not here, maybe better to defer?

Pete: hoping for clarification from mike .. server to label? sounds like a DNT direction?

Wendy: I think .. encouraging servers to indicate what else is affliated with them .. could enable more permissions than they might otherwise get (maybe)

but we should hear from mike for context

Tara: could also send questions along to mike

don't need to wait for next call

Wendy - Github issues welcome

<npdoty> I think Mike O’Neill’s draft and Mike West’s draft are both opt-in by servers to indicate relationships, and there would be no guarantee that they would be correct

<tara> IETF next week: there will be PING & friends f2f usual time on Thursday

<npdoty> but I think that kind of explicit transparency can be useful for end users if servers genuinely want to use it

Sam: since we have time, could we refer to web payments
... I opened a separate issue

<weiler> https://github.com/w3c/payment-request/issues/842

address redaction - sending parts of billing address to compute sales tax - my issue says for some use cases don't need

for some people any static redaction list will over share for some users

<wseltzer> [Note that Ian has proposed addressing the issue on the basic card payment method: https://github.com/w3c/payment-method-basic-card/issues/72]

said you are moving the bar - API is sending excess of use cases and what some sites do now - q is how bad is this?

<pes> !!! Seems bad!

<weiler> https://github.com/w3c/payment-request/issues/842#issuecomment-473907871

Wendy: note that Ian Jacobs suggested that this is an issue on basic card payment method rather than the API per se - suggests discuss on payment method document

(a procedural issue)

sam: maybe should be in both

<npdoty> is this data shared after the user has selected a card during a payment flow? or available in the background?

Pete: I don't have much to add beyond initial call we had but in your court - agree is bad - what would be helpful? +1 in Github or what else?

Sam: a single comment in the thread would help

re Nick question

Wendy: after user clicked buy and has given a card and other info and before they click pay

user gestures are required before info is shared

(my understanding)

Nick: obviously a big difference if background iframes read or during browser mediated intentional flow?

wendy: was one of my concerns looking at it initially - think there are protections against drive-by slurping

Ian shared TR for payment request API to go back to CR with new features and as part of making transition, they need to demonstrate they addressed the open issues

part of the urgency to look at issues - CR as is, or do or indicate more re privacy considerations

is this a bug with spec bringing forward or to which they are referencing is important for how we deal with the issue

sam: more eyes giving feedback would be helpful

Pete: would like to speak to something similar

call for people to chime in with support on github issues

even just this is important - will drop in chat as well

<pes> https://github.com/httpwg/http-extensions/issues/767

<npdoty> I’ve been trying to catch up on the Client-Hints github issues that pes noted, which I see have gotten long and heated and confused

<pes> ^^ relevant for IETF, since I wont be there

<npdoty> but I wasn’t sure what I could do to help

<pes> https://github.com/w3c/hr-time/issues/64

<pes> (thats all :) )

<tara> Next call: April 18?

Tara: 18th?

proposed time for next call

Sam and Tara: we may try some different technologies

thanks,

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/baic/basic/
Present: tara christine weiler terri pranjal wseltzer jnovak Brent_Zundel npdoty
No ScribeNick specified.  Guessing ScribeNick: christine
Inferring Scribes: christine

WARNING: No "Topic:" lines found.


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

Found Date: 21 Mar 2019
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


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.)