<barryleiba> meeting number: 316 409 766

<tara> Erm I didn't think you needed one? I reloaded the page and that prompt went away.

<tara> Boy I hope we are starting in a few minutes...

<tara> ICANN!

<weiler> scribe: christine

<barryleiba> ?

Chaals: micro data, spec updated, hope to go to CR within the month

would like to hear from PING that the changes are sufficient

<chaals-o> Microdata Working Draft

see privacy considerations section

<tara_> Push API : https://www.w3.org/TR/push-api/

overview

<tara_> Web Platform Working Group

peter (Google, Chrome, one of the editors of the API, also involved at IETF work)

added the security and privacy questionnaire answers to the repository

some interesting privacy areas

server cannot see content but size and frequency of interaction

largest concern (privacy)

used with notification API - website can send notifications to users (e.g. image) and might be able to get location using id delegation techniques

in most browsers not available in incognito mode (not Chrome, but same as other Web APIs re persistent identifiers)

also not some other browsers

chaals: potential to tracker users through the notifications sent to users

peter: can be intrusive, part of the concern of the notfification API

in practice, mobile devices and desktop, do not disturb enables users to stop notifications

<tara_> Issue #258: Change Source of Push Service and Privacy Issues: https://github.com/w3c/push-api/issues/258

<tara_> See Change Source of Push Service and Privacy Issues: https://github.com/w3c/push-api/issues/258

peter: are there specific mitigations you would like to see?

chaals: essentially comes down to notification API rather than push API, also users might want to collect notifications in a less intrusive way

peter: provider priority?

chaals: not really .. more thinking in terms of in notification API implementation, enabling user to pipe notification into this bucket because I am busy doing something else (e.g. teleconference)

peter: our own experience (Google), introducing notification channels

one channel per website - gives users control

other platforms Mac OS, Microsoft are moving in similar directions - more control to users

from a spec point of view, not sure what could do for benefit of users

chaals: yes, one thing to say - be aware user may not get push in real time

like everything else on a mobile - not always true instant delivery and can rely on

peter; don't make any promises on timing of delivery

can't guarantee timing

nick: thanks for coming to talk to us - 2 or 3 things - users visible only option in the subscription, curious seems like an opportunity for privacy - can user agent enforce?

peter: the intention - push API is a delivery mechanism, doesn't not mandate what developers has to do - at least for first version

nick: it is a promise being made or UA making a mechanical decision

peter: in theory, uA may want to display different user prompts

in all today's implementations - push notifications

user visiable only property must be set to get the subscription

nick: are UAs implementing not deliver notifications when tab in background

peter: browsers does not need to running for notification to be delivered

nick: if use for background tracking, how enforce?

peter: mozilla - give a budget based on amount the user uses the website - subscription will drop and lose ability to deliver messages if

chrome is different - active vs. not active - ..

nick: seems the goal is to tell the user something is happening - background processing maybe should be written up in specification

peter: but there are valid reasns for receiving a notification in the background (e.g. calendar update) - but no implementation experience on how to handle from privacy point of view

nick: seems like then that that feature isnt ready yet

peter - yes why current implementations are user visible only

difficult to lock down the specification

nick: you are trying to think ahead for new cases

peter: yes, have use cases but not clear how to make clear to user that something has happened in the past

nicK; why separate method to find out if subscribed? why separate permission state method?

peter: 2 reasons: permission API was not ready when started this

websites show own method for notifications

nick: danger showing without permission state checked first?

peter: network call could take time ..

(apologies peter, I don't always hear you clearly)

chaals: if one service channels all your push stuff, what is the reaility of whether you can mitigate in any way?

peter: comes down to OS restrictions

don't allow apps to run continuously or if want have to use OS systems

peter: understand not a satifiying answer

metrics from telefonica, persistently open connection up to 6% of your batter life

chaals: missing a unit here

peter: battery duration is decreased by 6%

chaals: if talk to performance wonks, seems like a big number, users do crazy things that have bigger impacts than that, if they want to move notifications around, would seem a small part of the budget

peter - no API that prohibits this

chaals: given that everything goes through a single server - whoever provides the services gets the metadata - time, frequencies, sizes, but packets are encrypted - but still quite a lot there

nick: one service per website or device

chaals: device

if a lot filtering, then the default service endpoint might not be available, e.g. in china

peter - based on current implementations - no interest to provide multiple backings to user but nothing in spec to prohibit - might want to make this clearer in the spec - but actual choice input service strikes me as a UA deicsion

chaals: if UA decision, privacy concern - choosing for you and routing through known point

a consideration if implmentations are done like that, they should be called out that way and explain if forced by OSs or a decision of the group as a trade-off on performance and is that trade-off right or arbitrary

explain constraints and implications is important

peter: spec cannot move blame to another actor, clarification is a good thing - would you iterate with me

chaals: happy to work with you on that

mulitple considerations go into this

tara: you went through the TAG questionnaire? feedback?

peter: quite easy to answer it

one q .. can reply offline - one q was unclear what it meant - rest was clear

end of July

thanks peter

apologies peter

it was hard to hear sometimes

<tara_> Screen Orientation API: https://www.w3.org/TR/screen-orientation/

leonie is looking for a review

<beverloo> christine: no problem -- thank you for taking notes!! the connection is not ideal from my side either.

tara: we need to provide a response

<beverloo> ""3.9 Does this specification allow an origin access to aspects of a user’s local computing environment?"" - it was not clear to us what "allow access" meant. Does the device's choice in push service count as this?

<tara_> Comments on Remote Playback API

<tara_> https://lists.w3.org/Archives/Public/public-privacy/2017AprJun/0025.html

tara: simon provided views and this is the response

we should look at the response

and see if it addresses the issues

see asks on mailing list

<tara_> PING at TPAC

<tara_> https://www.w3.org/2017/11/TPAC/

we have a slot

<tara_> We have a 1-day slot on Thursday 9 November

<beverloo> "(apologies peter, I don't always hear you clearly)" (re: Nick's question) - websites sometimes show custom UI when the user has yet to make a decision in the UA's permission request UI. Calling subscribe() *may* ask for permission, and then makes a network request to the push service to create a subscription. Distinguishing between whether the user is still seeing the permission prompt and whether the subscription request is still in progress is impor[CUT]

sam - web security and web authentication at the same time

<chaals-o> [beverloo I think that the device´s choice of service provides access to user data, but not sure about the local computing *environment* ...]

need to coordinate and structure with those groups

<chaals-o> [... I think the issue there is can you get stuff processed, and I guess the answer is yes?]

<Zakim> weiler, you wanted to discuss conflicts

<tara_> Christine: Closer to the agenda creation, we can coordinate with those groups and have mini combined meetings

<beverloo> [chaals-o: yes, we settled on a careful yes]

<beverloo> [let's continue discussion on the PR (I'll share tomorrow) and/or the bug. I've got to run - thank you once again!]

<tara_> See if there is way to create way for their agenda etc to allow for them to attend PING

<tara_> Christine: may be better to bring PING to their meeting

<tara_> Thanks for bringing it up!

<tara_> Could add the conflict issues to the TPAC questionnaire

sam: also mention on TPAC questionnaire

<tara_> Watch out for Dreamforce conference - book early!

<tara_> (Is mentioned on the TPAC page)

micro data?

sam: trying to recruit security reviewers

are there people on the call or in the group that would be able and willing?

nick: how is that being organised?

sam: going to individuals and asking them if they will do something, not through web SIG

open q about when we do reviews

trying to do based on manually generated requests, for now

nick: my hope would be that there would be a group/list where we could have the results of that to lead to a more common tradition

do we want people to do GitHub or email or both?

chaals: sam, want you to do both - make sure there is a record in a forum of what has been down

<scribe> done

and if can get reviewers to do that would be fantastic

nick: need to do more in privacy group

<tara_> Christine: would like that when we do questionnaire, in annotated section, put in some examples of success stories

<tara_> Example: Battery API with reduced granularity of info (data minimization)

nick: yes, good and bad examples

<tara_> Christine: Geolocation API -no interest for encrypted channel because rest of the world wasn't protecting the location data very well

<tara_> (as bad example)

christine ( not sure if I got that right)

let's use the wiki to document this

agreed

microdata

<chaals-o> microdata privacy section

<tara_> Very succinct!

<tara_> Next call: July 20 or 27th?

<tara_> 20th - bad choice (IETF & PETS)

<tara_> 27th better choice- pencil it in!

<tara_> Please check the Microdata privacy section, all.

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)

Present: Barry_Leiba Peter chaals christine keiji npdoty tara weiler
Found Scribe: christine
Inferring ScribeNick: christine

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


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

Got date from IRC log name: 29 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/29-privacy-minutes.html
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