<tara> Hullo folks; giving people a chance to join WebEx

<tara> WebEx meeting - https://mit.webex.com/mit/j.php?MTID=meda7c1b71d647aefa4377d4610c67648

<christine> hello, just have some issues getting webex up

<tara> Sorry for AV difficulties today...

<tara> Any scribe volunteers?

<christine> I can scribe

<scribe> scribenick: npdoty

anything to add to the agenda?

christine: IETF meeting next week, so planning a privacy get-together
... Payments is meeting again (now), will check in with them on status

<tara> UI Events KeyboardEvents Code Values [1] (comments due 10 April)

Review requests - UI Events

<tara> https://w3c.github.io/uievents-code

<tara> UI Events KeyboardEvents Key Values [2] (comments due 10 April)

<tara> https://w3c.github.io/uievents-key

tara: asking for events on these docs by 10 April
... anyone with knowledge of these specs?

chaals: a stack of events related to your keyboard
... so it could reveal how your system is laid out (what keys, etc.)
... so a potential fingerprinting vector

christine: have we heard from a11y? often a privacy concern about revealing an ability or disability

chaals: makes sense as a concern, but don't know if we have received those comments yet

<tara> (based on layout, etc of keyboard -choice mades)

<chaals> scribe: chaals

NPD: how is this different from existing keyboard events?

CMN: This is just an actual specification for that…

<tara> chaals: this is specifying what the codes and values are

<tara> Fingerprinting is "what keys does a user use, when"

<tara> Can tell "where on the keyboard is the key"

<tara> You would have to track user's activity to get more info

<wseltzer> https://www.w3.org/TR/uievents/#security-considerations

<tara> wseltzer: typing patterns also good source of fingerprinting

WS: Note the parent spec - the UIEvents spec - has a security considerations section but no mention o fprivacy
... and some of the things listed under security are probably properly privacy considerations. In any event that is the document to review. Propose not to move the document forward without adding something on privacy considerations.

TW: So we should go up one level and look there for most of the issues?

WS: that would be my approach.

<wseltzer> https://www.w3.org/TR/uievents/#relationship-between-key-code

NPD: Seems like the values coming in the specs are the kind of document you refer to when doing the implementation, the design issues might be more appropriate in the parent spec.

CMN: Web platform wants to move the UI evnt key codes/values specs to CR, waiting for signoff.
... These are things that have been implemented for 2 decades, we're just trying to get decent specs for them.

TW: OK, so we should go through this quickly.

<tara> ARIA in HTML [3] (comments due 30 April)

<tara> https://www.w3.org/TR/html-aria/

ARIA in HTML

TW: No time to discuss in last call.

<christine> note from christine - sound keeps cutting in and out for me

<tara> CMN: tells authors how to use ARIA

<tara> CMN: you could give different information to people with, say, screen readers

<tara> CMN: can find out whether a targetted subset responds

<tara> 'NPD: is there any automatic content -- automatically fetched - because of an ARIA role?

<tara> CMN: the upstream spec may be more relevant in this case

<tara> CMN: content isn't fetched in current ARIA (unless introduced in ARIA 1.1?) -- is what is in existing page

<npdoty> in general it seems like markup should have fewer privacy implications than many specs

<tara> CMN: would we want to put an outline of an attack in a privacy section?

<tara> CMN: in the authoring guidance, seems odd to demonstrate *how* to exploit.

<tara> WS: privacy by obscurity not helpful, so...yes, such a note would help

<tara> NPD: sometimes it's helpful to describe attacks if there might be a mitigation...so you can tell implementors how to help

<tara> CMN: there is not much mitigation here.

<npdoty> wseltzer: at least a note for authors that a11y information is sensitive and shouldn't be collected or shouldn't be exposed if inferred

ODRL

<tara> ODRL Information Model [4] (comments due 30 April)

<tara> https://www.w3.org/TR/odrl-model/

<tara> ODRL Vocabulary & Expression [5] (comments due 30 April)

<tara> https://www.w3.org/TR/odrl-vocab/

<tara> CMN: could maybe fingerprint based on intersection of policy settings

<tara> NPD: not sure how this is being used/implemented

<christine_> note from Christine: apologies, back online now

<wseltzer> [The purpose value is taken from the P3P privacy purpose vocabulary]

<tara> P3P vocab about to be deprecated

<tara> W3C recently added "deprecation" powers...

<tara> "obsoletion", sorry

<wseltzer> "Obsolete"

<tara> WS: ODRL - have not reviewed in detail; noted it was scoped to be "not DRM"

<npdoty> (recalls that P3P has quite a few implementations, even if it's not the ubiquity of implementation that we might have liked)

[there is plenty of implementation of P3P. But it doesn't work, in the sense of "people actually negotiate or set things to protect their privacy"]

http://w3.org/TR/input-events

<wseltzer> [right, there's implementatoin, but not adoption]

<wseltzer> [or use]

<tara> CMN: anything where you can see how users act (e.g., how they manipulate text) then there is a fingerprinting vector

<tara> WS: is it visible to the user that Input Events is active, or could this be used to capture keystroke secretly?

<tara> CMN: can you use as keylogger you mean? No -- you would need the element that captures the keys

<wseltzer> [could you create a hidden input field, for example?]

<tara> CMN: does not log actual keys. Post-processing; events *after* text to add/remove has been generated

<tara> CMN: so I think the answer is "no"

<tara> NPD: if I indicate that I am about to paste text, is the JS going to handle insertion?

<tara> CMN: browser says "I am going to put this text in this place"; event is b/c JS rich text editor can say "no, I am going to do something else" -- inserting the text that the user wants...

<tara> CMN:...or putting it through the "undo"

<tara> CMN: you get a series of events of what user wants to achieve + possibility of preventing them

<tara> NPD: I know there are means for preventing pasting of text into pages

<tara> CMN: people who edit content on Github, blog etc - want to be able to do stuff like this

<tara> CMN: might be worth asking for a better overview with Johannes Wilm

<npdoty> I'm frustrated by web pages that inhibit password managers by preventing pasting into an input field

<npdoty> but I get the impression that this wouldn't be easier than current methods for doing that, so maybe not a significant impact

<scribe> ACTION: chaals to ask Johannes to join a call and present input events more intelligently [recorded in http://www.w3.org/2017/03/23-privacy-minutes.html#action01]

<trackbot> Created ACTION-15 - Ask johannes to join a call and present input events more intelligently [on Charles McCathie Nevile - due 2017-03-30].

<tara> Date for next call?

<npdoty> Thursday, April 20 or Thursday, April 27?

<tara> April 20 looks the most optimal

<tara> Giving comments to Web Payments is still useful but ASAP - they are meeting today and tomorrow

<tara> (And yes, comments after this point still useful too.)

[thanks 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)

Succeeded: s/haven't/don't know if we have/
Succeeded: s/chaals:/chaals/
Present: keiji tara wseltzer chaals npdoty christine
Found ScribeNick: npdoty
Found Scribe: chaals
Inferring ScribeNick: chaals
ScribeNicks: npdoty, chaals

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

Got date from IRC log name: 23 Mar 2017
Guessing minutes URL: http://www.w3.org/2017/03/23-privacy-minutes.html
People with action items: chaals