See also: IRC log
<tara> Hello all. Giving a moment for folks to join...
<scribe> scribenick: weiler
<tara> Thanks, Sam!
<christine> nick are you on the webex?
<christine> I gave up
johanes: Input Events.... editing appls that sit on top of browser.
<tara> https://w3c.github.io/uievents-code/
johanes: idea is to provide a consistent event before anything has changed in text edittng area.
<tara> https://github.com/w3c/uievents-key/
johanes: level 1: only for things
e.g. formatting/menus.
... level 2 includes that + character inputs.
... invites questions re: privacy implications. all of this is
stuff that j/s already has access to, but it was impractical
before.
... keystrokes easiest now; context menu/touchbar harder
now.
<Zakim> npdoty, you wanted to comment on fingerprinting
npdoty: re: fingerprinting. some
things will be hard to mitigate (e.g. how users type certain
words). will this reveal details re: keybaord layout? - that's
very persistent, avail. across origins.
... or touchbar configuration.
johannes: some characters only on
certain (language) layouts.
... ideas is to have more of abstraction. not say HW kbd v.
soft kbd for example.
... some have suggested ADDING this info.
ntdoty: we've talked to accessibility people re: this (e.g. did this come from a kbd or voice input)?
leonie: user population for voice stuff has grown; less identifying.
<npdoty> to be clear, we *haven't* talked to accessibility group, but would be interested in their expertise
[a larger "anonymity set"]
npdoty: this is a privacy impl. re: revealing some of users capabilities (e.g. ability to type or not).
christine: Sounds like there are some potential privacy improvements in this - they should be noted in the privacy considerations section
<chaals> [+1 to Christine - note the privacy advantages as well as disadvantages in privacy considerations]
<npdoty> autocomplete library information is an interesting privacy question too
chaals: would be useful to do some testing w/ real input systems (e.g. predictive input systems / Swype)
johannes: w/ mobile devices, have less information. often guessing at user's intent.
<npdoty> was this useful? what's the timeline?
johannes: useful. chrome almost ready to ship. webkit has shipped or will soon.
<npdoty> and is the spec at CR?
chaals: no, but hoping for soon.
still in fpwd exclusion period, maybe?
... wanting wider review. thinking it's ready for CR.
<chaals> [Thanks Johannes for turning up]
<tara> https://lists.w3.org/Archives/Public/public-privacy/2017AprJun/0001.html
<chaals> HTML changes section
leonie: 6 incremental updates to
5.1 since Sept. we suggest focusing on the changelog.
... how could we make reviews easier? (make changelog more
useful?)
christine: for me, THIS (talking to us on this call) is the best.
chaals: walking us through the changelog...
<npdoty> this change log is definitely more useful than trying to read every github commit, say. but it's still a little tricky to understand the reasoning or implications
https://w3c.github.io/html/changes.html#changes-wd4
<chaals> change in security creator context
<npdoty> can you speak to "allowed to use"?
scribe: impacts possible from how users interact w/ forms
<npdoty> data: as a separate origin seems like a security/privacy improvement
<chaals> commit for "allowed to use"
<chaals> Open HTML issues
scribe: no label here re:
privacy, but we do label other areas.
... we haven't found many things that we thing implicate
privacy
<chaals> describe ping attribute
leonie: there a label, mostly unused.
<tink> The "privacy" label on the HTML repo is not attached to any issues at the moment.
chaals: ping attr allows a link
on a page to send a msg somewhere else. purpose is for user
tracking. if we were to define that, you should look! was in
html5; subsequently removed.
... waiting. would be helpful to look at it now.
<chaals> pingback, used for blog references, not exactly what I am thinking of...
<npdoty> right, pingback is an entirely different technology
<chaals> links, including a description of the ping attribute
<npdoty> we're talking about a ping attribute on an a element, I think
chaals: The whatwg has PING in
their specification.
... if you follow a link, other links get told
<chaals> explanations of what happens, and why
chaals: spec says user agent should tell user what it's doing. but what do UA's actually do today?
npdoty: I can see where this might make sense for user, but if UAs are never are exposing this to user... may want to answer the Q of whether this is ever being implemented for the user's benefit before we standardize it.
<npdoty> +1 on determining what UAs are actually doing
<npdoty> I'm concerned that even though the reasoning should support the user, it's possible that it would just make it easier to add several tracking services to a link, all without the user actually understanding it
<npdoty> I'm glad that the WHATWG spec writes it as an explicitly optional feature
Leonie: may 26 is cutoff for CR. comments sooner appreciated.
chaals: would be helpful if PING could help of think re: what gets submitted w/ forms. what does it make sense to expose to a user? (e.g. not meaningless strings)
<npdoty> I'm curious whether there has been any attempt to show *when* a page is communicating back to a server
<chaals> Issues tagged as privacy
[and provide UA features to stop such communication?]
chaals: no.
[are there plugins that can do that, on a per-page basis?]
<tara> We're coming to the last two minutes...
chaals: should look at page-to-page messaging within the browser. follows same-origin policy, which might not mean much.
tara: Next call 18 May.
<chaals> [Look at Service Workers, in the context of being able to know when information is being transferred - but the key problem is actually knowing what information is being transferred - is it just icons for the page, or privacy-sensitive information added by the user's interaction with the page. This is also the issue with forms, ever since they have been part of the web.
<npdoty> yeah, it's Service Workers and more meaningful offline apps (and things like background requests) that made me bring it up
<npdoty> I think it will always be difficult to describe what information is being transferred (since it's so easy to obfuscate), but whether I'm connected or not is a sharper distinction that users might make choices based on
<chaals> Sure, except without an understanding of what information has been gathered and is being transferred, that's pretty meaningless.
<chaals> a request to service.example.com/update?feqad might be a hash of the user interaction patterns, or a request for the next meaningless comment that should appear now I scrolled
<chaals> My phone shows me when data is going up and down, but it's almost useless even when I lock it down to a single page that is the only thing allowed to communicate…
<chaals> …and I actually care enough to try and understand that.
<chaals> [ref. wseltzer's comments about atypical users :) ]
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/@@/Sounds like there are some potential privacy improvements in this - they should be noted in the privacy considerations section/ Succeeded: s/@@ WG/whatwg/ Succeeded: s/makes sense/might make sense/ Succeeded: s/title: Privacy IG meeting// Default Present: weiler, Léonie, wseltzer, tara, keiji, johanneswilm, chaals, christine, Lisa, npdoty Present: weiler Léonie wseltzer tara keiji johanneswilm chaals christine Lisa npdoty Found ScribeNick: weiler Inferring Scribes: weiler Got date from IRC log name: 20 Apr 2017 Guessing minutes URL: http://www.w3.org/2017/04/20-privacy-minutes.html People with action items:[End of scribe.perl diagnostic output]