There will be a W3C Web Authentication WG Face-to-Face Meeting on 02/13/2016 the location will be:
Microsoft San Francisco
555 California street, suite 200
San Francisco, CA 94104
More information will follow as we get closer to the date, any question please post to the list.

I worry that this makes fingerprinting easier for tracking servers, especially for subresources.
It is true that these capabilities are already available via JS but only for browsing contexts and the extra turnaround forces some stickiness. This would make these granular user-agent capabilities immediately available to any resource, without need for a round trip.
I think that at least the availability of a user opt-in should be a MUST.
-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: 02 December 2016 18:08
To: i-d-announce@ietf.org
Cc: ietf-http-wg@w3.org
Subject: I-D Action: draft-ietf-httpbis-client-hints-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol of the IETF.
Title : HTTP Client Hints
Author : Ilya Grigorik
Filename : draft-ietf-httpbis-client-hints-03.txt
Pages : 13
Date : 2016-12-02
Abstract:
An increasing diversity of Web-connected devices and software
capabilities has created a need to deliver optimized content for each
device.
This specification defines a set of HTTP request header fields,
colloquially known as Client Hints, to address this. They are
intended to be used as input to proactive content negotiation; just
as the Accept header field allows clients to indicate what formats
they prefer, Client Hints allow clients to indicate a list of device
and agent specific preferences.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-03
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-client-hints-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Hi Barry,
Oo, did I miss an earlier notice of this? This one just came the day
> of the call, and I didn't see it until the call was half over.
You did not miss an earlier notice. You can blame me for missing that the
usual earlier notice did not go out and then sending one out at the 11th
hour. Sorry about that.
Expect the "mark your calendars" email for January's call to be out soon,
with another reminder (with agenda) in (proper) advance of the call date.
--TW

01.12.2016, 18:37, "David Singer" <singer@apple.com>:
> Hi
>> On Nov 30, 2016, at 18:29 , Tara Whalen <tjwhalen@gmail.com> wrote:
>> Draft agenda
>>
>> 4. Privacy Questionnaire
>
> This needs to be updated to say that yes, a Privacy and Security Considerations section should be there, and that the questions are there to help you write it.
>
> The questions currently don’t help much with format specs (as opposed to protocols)…
Hence my earlier question, asking *where* I should be proposing edits so they get considered. It seems that "in reply to the agenda of teleconferences" is a pretty bad answer, but it's currently my leading hypothesis :(
cheers
--
Charles McCathie Nevile - standards - Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Hi all,
Thank you to those who were able to make the PING and friends get-together yesterday in Seoul.
We had an informal discussion about various items:
(1) User Data Controls in Web Browsers
https://gist.github.com/mnot/96440a5ca74fcf328d23
This is Mark Nottingham’s draft. You may have heard it described as the “private browsing mode” draft. It has already been used by a couple of WGs to evaluate their own specifications. Mark is welcoming comments. Additionally, we discussed the possibility of PING adopting the draft with the aim of ultimately publishing it as a PING Group Note.
This is timely, especially given the discussion at TPAC and the follow-up conversation raised by David.
Next steps: We will add this to the agenda for the next call. In the meantime, please review the draft and share your comments on this list.
(2) Mitigating Browser Fingerprinting in Web Specifications
https://w3c.github.io/fingerprinting-guidance/
It’s really time we move this toward becoming a PING Group Note. Look for a separate note on this.
(3) Privacy questionnaire
We have been receiving increasing numbers of requests to conduct privacy reviews of specifications. Our PING resources do not scale to this. So, we really need to devote our core effort to getting this out the door. I’m looking for volunteers to work with me on the draft in December.
(4) Secure Contexts
Secure Contexts is now a Candidate Recommendation
https://www.w3.org/TR/secure-contexts/
(5) Some ideas for increasing PING outreach
- reach out to browsers like Brave, Ghostery
- raise public awareness of Web privacy issues (i.e. beyond Web specification authors)
(6) Other items
Deprecate modification of 'secure' cookies from non-secure origins
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01
Double-keying third-party cookies and tracking
https://github.com/httpwg/http-extensions/issues/248
Christine (co-chair)

> On Nov 17, 2016, at 18:38 , Christine Runnegar <runnegar@isoc.org> wrote:
>
> (3) Privacy questionnaire
>
> We have been receiving increasing numbers of requests to conduct privacy reviews of specifications. Our PING resources do not scale to this. So, we really need to devote our core effort to getting this out the door. I’m looking for volunteers to work with me on the draft in December.
I recently started this for the VTT specification (and sent a copy to this list). It became clear that the questions were written with the mind-set that the spec is for a protocol, and I think we need better questions for specs of formats.
David Singer
Manager, Software Standards, Apple Inc.

> On 18 Nov 2016, at 7:53 PM, David Singer <singer@apple.com> wrote:
>
>
>> On Nov 17, 2016, at 18:38 , Christine Runnegar <runnegar@isoc.org> wrote:
>>
>> (3) Privacy questionnaire
>>
>> We have been receiving increasing numbers of requests to conduct privacy reviews of specifications. Our PING resources do not scale to this. So, we really need to devote our core effort to getting this out the door. I’m looking for volunteers to work with me on the draft in December.
>
> I recently started this for the VTT specification (and sent a copy to this list). It became clear that the questions were written with the mind-set that the spec is for a protocol, and I think we need better questions for specs of formats.
Noted. Thank you David. If you have suggestions for what those better questions might be like that would be really helpful.
>
> David Singer
> Manager, Software Standards, Apple Inc.
>

Also, rather obviously, I *think* that the PING and TAG surveys are there to help people write a privacy and security considerations section. However, I just came across a group that felt that answering (mostly with ‘no’ as it’s a format spec.) in email is enough.
I suspect that both surveys need to say, on the question “Does this specification have a privacy and security considerations section” that the only valid answers are “yes” or “No, not yet, but it will before any formal advancement request is made”
Even if there are no such considerations (hard to believe for any non-trivial spec.), the spec. needs to say that.
> On Nov 19, 2016, at 1:15 , Christine Runnegar <runnegar@isoc.org> wrote:
>
>
>> On 18 Nov 2016, at 7:53 PM, David Singer <singer@apple.com> wrote:
>>
>>
>>> On Nov 17, 2016, at 18:38 , Christine Runnegar <runnegar@isoc.org> wrote:
>>>
>>> (3) Privacy questionnaire
>>>
>>> We have been receiving increasing numbers of requests to conduct privacy reviews of specifications. Our PING resources do not scale to this. So, we really need to devote our core effort to getting this out the door. I’m looking for volunteers to work with me on the draft in December.
>>
>> I recently started this for the VTT specification (and sent a copy to this list). It became clear that the questions were written with the mind-set that the spec is for a protocol, and I think we need better questions for specs of formats.
>
> Noted. Thank you David. If you have suggestions for what those better questions might be like that would be really helpful.
>>
>> David Singer
>> Manager, Software Standards, Apple Inc.
>>
>
David Singer
Manager, Software Standards, Apple Inc.

On 11/28/2016 02:22 PM, David Singer wrote:
> Also, rather obviously, I *think* that the PING and TAG surveys are there to help people write a privacy and security considerations section. However, I just came across a group that felt that answering (mostly with ‘no’ as it’s a format spec.) in email is enough.
>
> I suspect that both surveys need to say, on the question “Does this specification have a privacy and security considerations section” that the only valid answers are “yes” or “No, not yet, but it will before any formal advancement request is made”
>
> Even if there are no such considerations (hard to believe for any non-trivial spec.), the spec. needs to say that.
+1. If this guidance isn't clear from the questionnaires, let's get some
PRs to add it.
--Wendy
>
>> On Nov 19, 2016, at 1:15 , Christine Runnegar <runnegar@isoc.org> wrote:
>>
>>
>>> On 18 Nov 2016, at 7:53 PM, David Singer <singer@apple.com> wrote:
>>>
>>>
>>>> On Nov 17, 2016, at 18:38 , Christine Runnegar <runnegar@isoc.org> wrote:
>>>>
>>>> (3) Privacy questionnaire
>>>>
>>>> We have been receiving increasing numbers of requests to conduct privacy reviews of specifications. Our PING resources do not scale to this. So, we really need to devote our core effort to getting this out the door. I’m looking for volunteers to work with me on the draft in December.
>>>
>>> I recently started this for the VTT specification (and sent a copy to this list). It became clear that the questions were written with the mind-set that the spec is for a protocol, and I think we need better questions for specs of formats.
>>
>> Noted. Thank you David. If you have suggestions for what those better questions might be like that would be really helpful.
>>>
>>> David Singer
>>> Manager, Software Standards, Apple Inc.
>>>
>>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>
--
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Strategy Lead, World Wide Web Consortium (W3C)
https://wendy.seltzer.org/ +1.617.863.0613 (mobile)

Hi everyone,
A friendly reminder.
For those who will be at the IETF meeting in Seoul, we will be having a PING and friends get-together at the usual time.
Time: 12:30 - 13:30
Location: Conrad Seoul, Level 6, Studio 9
Note: It’s bring your own lunch
Christine

Hi
it’s way overdue for WebVTT to have a security and privacy considerations section.
I have taken the TAG and PING questionnaires, and seen what they provoke, and then below I offer the beginning of a security and privacy considerations section. Comments welcome. I have cc’d the Privacy Interest Group (PING!) in case they have comments or suggestions.
Most of these questions are more applicable to protocols than to formats, so I have answered them as not applicable (N/A). Please chip in if you see something that I do not.
Questions 3.x are from the TAG. <https://www.w3.org/TR/security-privacy-questionnaire/>
Questions Px are from PING. <https://www.w3.org/wiki/Privacy_and_security_questionnaire>
• 3.1 Does this specification deal with personally-identifiable information?
P2 Does this specification collect personally derived data?
P3 Does this specification generate personally derived data, and if so how will that data be handled?
P7 Does the standard utilize data that is personally-derived, i.e. derived from the interaction of a single person, or their device or address?
Only inasmuch as the desire for captions/sub-titlles (i.e. accessing the content at all) might indicate that the user wants/needs them. No collection is performed.
• 3.2 Does this specification deal with high-value data?
no
• 3.3 Does this specification introduce new state for an origin that persists across browsing sessions?
no
• 3.4 Does this specification expose persistent, cross-origin state to the web?
no
• 3.5 Does this specification expose any other data to an origin that it doesn’t currently have access to?
no
• 3.6 Does this specification enable new script execution/loading mechanisms?
It is possible to embed (and hence link to) CSS style sheets, so the security/privacy considerations of CSS apply, when the VTT user-agent supports CSS. If there is a user-side style-sheet, it’s possible that it will be possible to detect that it is in effect.
It is also possible to use VTT to pass cues that are ‘triggers’ to a script (though VTT does not, itself, provide the script). The security/privacy considerations of the script and scripting system then apply.
• 3.7 Does this specification allow an origin access to a user’s location?
P4 Does this specification allow an origin direct access to a user’s location, and if so is that information minimized?
no
• 3.8 Does this specification allow an origin access to sensors on a user’s device?
no
• 3.9 Does this specification allow an origin access to aspects of a user’s local computing environment?
See above under 3.6
• 3.10 Does this specification allow an origin access to other devices?
no
• 3.11 Does this specification allow an origin some measure of control over a user agent’s native UI?
Only inasmuch that captions/subtitles are presented.
• 3.12 Does this specification expose temporary identifiers to the web?
no
• 3.13 Does this specification distinguish between behavior in first-party and third-party contexts?
no
• 3.14 How should this specification work in the context of a user agent’s "incognito" mode?
P5 How should this specification work in the context of a user agent’s "incognito" mode?
Not applicable.
• 3.15 Does this specification persist data to a user’s local device?
no
• 3.16 Does this specification have a "Security Considerations" and "Privacy Considerations" section?
P1 Does this specification have a "Privacy Considerations" section?
It will, once we have finished this
• 3.17 Does this specification allow downgrading default security characteristics?
no
P6 Is it possible to spoof/fake the data being generated for privacy purposes?
n/a
P8 Does the data record contain elements that would enable re-correlation when combined with other datasets through the property of intersection (commonly known as "fingerprinting”)?
n/a
P9 Does the data record contain elements that would enable re-correlation when combined with other datasets through the property of intersection (commonly known as "fingerprinting”)?
n/a
P10 Is the user likely to know if information is being collected?
n/a
P11 Can the user easily, preferably through an element of the GUI, revoke consent granted to a particular feature?
n/a
P12 Once consent has been given, is there a mechanism whereby it can be automatically revoked after a reasonable, or user configurable, period?
n/a
P13 Does this standard utilize strong end to end encryption?
The delivery protocol used is out of scope.
* * * DRAFT * * *
X Security and Privacy Considerations
X.1 Text-based format security
As with any text-based format, it is possible to construct malicious content that might cause buffer over-runs, value overflows (e.g. string representations of integers that overflow a given word length), and the like. Implementers should take care that over-long lines, field values, or encoded values do not cause security problems.
X.2 Styling
VTT can embed style ‘snippets’, and they in turn can cause the loading of external style sheets, in user-agents that support CSS. Under these circumstances, the security and privacy considerations of CSS apply. In addition, it is possible for a user-agent to offer user style-sheets, and their presence and nature might be detectable by scripts running in the same user-agent (e.g. browser). This might enable fingerprinting of the user or reveal aspects of the user’s preferences (e.g. the choice of a large font size and/or high-contrast colors might indicate a user with visual impairments).
X.3 Scripting
VTT does not include or enable scripting. However, it is possible to construct and deliver a file that is designed not to present captions or subtitles, but instead to provide timed input (‘triggers’) to a script system. A poorly-written script or script system might then cause security or other problems; however, this consideration really applies to the script system. Because VTT supplies these triggers at their timestamps, a malicious file might present such triggers very rapidly, perhaps causing undue resource consumption.
X.4 Privacy of preference
A user-agent that selects, and causes to download or interpret a VTT file, might indicate to the origin server that the user has a need for captions or subtitles. That is a (small) piece of information about the user. However, the offering of a caption file, and the choice whether to retrieve and consume it, are better viewed as characteristics of the format or protocol which does the offer (e.g. the HTML <source> element), rather than of the caption format itself.
David Singer
Manager, Software Standards, Apple Inc.

Hey
I have a proposition about the ownership of content and some use cases
where this can be relevant. I am not very sure whether it should be an HTML
element or a CSS property. I would like your advice on it. Also, I am new
to this and if this is not the correct procedure, please guide me in the
right direction.
Objective:
Various content in a web page should be allowed to be tagged as one of the
following.
- first party content: typically content that the owner of the web page
created or owns
- second party content: content like comments and other user interactions
where the client(s) created the content
- third party content: typically ads, search bar powered by some search
engine, embedded maps, recommendations, etc fall into this category
The above classification can be used in creating views in browsers: for
example reader view can be made more focused by selecting only first party
content. The user can have better control over whether to allow third part
content or not.
I understand that web sites owners can easily violate this intention by
showing ads in first party content section. So, this more or less operates
in good faith that web sites will tag data appropriately.
Possible implementations:
1. as HTML elements
<body>
<first_party>This is my content</first_party>
<second_party>This is a commented by my reader</second_party>
</body>
2. as properties
<body>
<div party="first">This is my content</div>
<div party="second">This is a commented by my reader</div>
</body>
I hope I am not talking complete rubbish. I welcome your feedback.
Thanks and regards,
Amitav

Amitav,
my impression is that this type of discussion should be taken up with what we call the Web Platform WG, taking care of the evolution of HTML. The best approach for this is to consider putting a note to:
https://discourse.wicg.io/ <https://discourse.wicg.io/>
and see the feedbacks you get there. One of the usual mechanisms in that WG is to have some sort of an incubating discussion on that forum to see if there is enough momentum to take it further.
Sincerely
Ivan Herman
> On 10 Nov 2016, at 20:35, Amitav Mohanty <amitavmohanty01@gmail.com> wrote:
>
> Hey
>
> I have a proposition about the ownership of content and some use cases where this can be relevant. I am not very sure whether it should be an HTML element or a CSS property. I would like your advice on it. Also, I am new to this and if this is not the correct procedure, please guide me in the right direction.
>
> Objective:
> Various content in a web page should be allowed to be tagged as one of the following.
> - first party content: typically content that the owner of the web page created or owns
> - second party content: content like comments and other user interactions where the client(s) created the content
> - third party content: typically ads, search bar powered by some search engine, embedded maps, recommendations, etc fall into this category
>
> The above classification can be used in creating views in browsers: for example reader view can be made more focused by selecting only first party content. The user can have better control over whether to allow third part content or not.
>
> I understand that web sites owners can easily violate this intention by showing ads in first party content section. So, this more or less operates in good faith that web sites will tag data appropriately.
>
> Possible implementations:
> 1. as HTML elements
>
> <body>
> <first_party>This is my content</first_party>
> <second_party>This is a commented by my reader</second_party>
> </body>
>
> 2. as properties
>
> <body>
> <div party="first">This is my content</div>
> <div party="second">This is a commented by my reader</div>
> </body>
>
> I hope I am not talking complete rubbish. I welcome your feedback.
>
> Thanks and regards,
> Amitav
----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Hi everyone,
For those who will be at the IETF meeting in Seoul, we will be having a PING and friends get-together at the usual time.
Time: 12:30 - 13:30
Location: Conrad Seoul, Level 6, Studio 9
Note: It’s bring your own lunch
Christine

Hello privacy people,
The WebPlat WG would like to request a privacy review of the IndexedDB
API specification [1].
We have completed the privacy and security questionnaire. Answers at the
end of this email.
Please could you file your comments as Github issues [2]. An email
summary to public-webapps@w3.org
is welcome, but the editors focus on Github for issue tracking.
If it is possible for you to complete the review by 8th January 2017, we
would appreciate it. If this does not give you enough time, please let
me know.
Thanks.
Léonie on behalf of the WebPlat chairs & IndexedDB editors
[1] https://www.w3.org/TR/IndexedDB-2/
[2] https://github.com/w3c/IndexedDB/issues/
Questionnaire responses...
3.1 Does this specification deal with personally-identifiable information?
No.
3.2 Does this specification deal with high-value data?
No.
3.3 Does this specification introduce new state for an origin that
persists across browsing sessions?
Yes - it defines a storage API, equivalent in persistence behavior to
Web Storage's localStorage API.
3.4 Does this specification expose persistent, cross-origin state to the
web?
Through the use of quota probing (e.g. store data incrementally until
QuotaExceededErrors are returned) it may be possible to estimate the
amount of storage
available on the device, depending on the heuristics the user agent uses
to allocate quota to storage APIs and origins. If the storage amount is
stable
it could be used for fingerprinting. This can be mitigated by decreasing
entropy (e.g. binning values to make it more difficult to distinguish
users).
3.5 Does this specification expose any other data to an origin that it
doesn’t currently have access to?
No.
As an aside, Indexed DB does not currently allow the storage of Response
objects (opaque or otherwise) since they are not currently "structured
cloneable".
Therefore, storage quota side-channel attacks against cross origin data
that affect the Cache API (from Service Worker spec) do not apply; see
https://tom.vg/2016/08/request-and-conquer/
for more details.
3.6 Does this specification enable new script execution/loading mechanisms?
No.
3.7 Does this specification allow an origin access to a user’s location?
No.
3.8 Does this specification allow an origin access to sensors on a
user’s device?
No.
3.9 Does this specification allow an origin access to aspects of a
user’s local computing environment?
No.
3.10 Does this specification allow an origin access to other devices?
No.
3.11 Does this specification allow an origin some measure of control
over a user agent’s native UI?
No.
3.12 Does this specification expose temporary identifiers to the web?
No.
3.13 Does this specification distinguish between behavior in first-party
and third-party contexts?
The specification allows user agents to restrict access to the database
objects to scripts originating at the domain of the top-level document
of the browsing
context, for instance denying access to the API for pages from other
domains running in iframes.
(Called out in Privacy/User tracking section)
3.14 How should this specification work in the context of a user agent’s
"incognito" mode?
Browsers may implement an "memory-backed" store rather than
"disk-backed" store in incognito/private browsing mode. This allows the
feature to exist and
function in such a mode.
Note that probing through timing (RAM is usually faster than disk) or
quota (memory may be more limited than disk) it may be possible to
distinguish this
approach; this potentially affects all storage APIs.
3.15 Does this specification persist data to a user’s local device?
Yes. "Clear browsing data" for an origin must remove all Indexed DB data
for the origin (all databases, and all data and metadata within those
databases).
3.16 Does this specification have a "Security Considerations" and
"Privacy Considerations" section?
Yes.
3.17 Does this specification allow downgrading default security
characteristics?
No.
--
@LeonieWatson tink.uk Carpe diem

Hello Privacy,
The WebPlat WG would like to request a privacy review of the Screen
Orientation API [1].
We have completed the privacy and security questionnaire [3. Answers can
be found at the end of this email.
Please could you file your comments as Github issues [2]. An email
summary to public-webapps@w3.org
is welcome, but the editors of this spec do not monitor that email.
Thank you.
Léonie on behalf of the WebPlat chairs and Screen Orientation API editors
[1] https://www.w3.org/TR/screen-orientation/
[2] https://www.w3.org/TR/security-privacy-questionnaire/
[3] https://github.com/w3c/screen-orientation/issues
Questionnaire answers:
3.1 Does this specification deal with personally-identifiable information?
No.
3.2 Does this specification deal with high-value data?
No.
3.3 Does this specification introduce new state for an origin that
persists across browsing sessions?
No.
3.4 Does this specification expose persistent, cross-origin state to the
web?
The screen orientation state. Also already available in most browsers
via window.orientation.
3.5 Does this specification expose any other data to an origin that it
doesn’t currently have access to?
No.
3.6 Does this specification enable new script execution/loading mechanisms?
No.
3.7 Does this specification allow an origin access to a user’s location?
No.
3.8 Does this specification allow an origin access to sensors on a
user’s device?
The screen orientation state is a result of sensors. However, it has
only 4 values.
3.9 Does this specification allow an origin access to aspects of a
user’s local computing environment?
Screen orientation is one, yes.
3.10 Does this specification allow an origin access to other devices?
No.
3.11 Does this specification allow an origin some measure of control
over a user agent’s native UI?
Not really. It can lock the screen orientation but it is not really
"controlling" the UA UI.
3.12 Does this specification expose temporary identifiers to the web?
No.
3.13 Does this specification distinguish between behavior in first-party
and third-party contexts?
No.
3.14 How should this specification work in the context of a user agent’s
"incognito" mode?
Should not be different.
3.15 Does this specification persist data to a user’s local device?
No.
3.16 Does this specification have a "Security Considerations" and
"Privacy Considerations" section?
No, but we'll add one with information about the points answered "yes".
3.17 Does this specification allow downgrading default security
characteristics?
No.
--
@LeonieWatson tink.uk Carpe diem

Dear Experts (with attachment this time)
We are planning to propose a special session on "JPEG Privacy and Security”
for ICIP 2017. We welcome the experts working on this area to contribute
their work on this special session. Please find attached the proposal and a
list of potential areas of contribution. Please forward this to your
colleagues whose work may align closely with this activity, as appropriate.
Please send me the preliminary title, author, the contact information of
the corresponding author and the draft abstract by 12 November 2016 to be
included in the proposal.
Please feel free to contact me with any question you may have in relation
to this proposal. With your contributions, we wish to make the special
session worthwhile that can greatly benefit the work within the JPEG
Committee.
Thank you and looking forward to your reply!
Cheers
Ambarish S Natu
--
Cheers
Ambarish S Natu
www.angelfire.com/ak4/ambarishnatuatunsw/1_page.htm

I, along with all of you save David, neglected to start an on-list
discussion of these questions. I'm happy to add some thoughts, but I'm
wondering if there are other questions people would add to this list?
And how might PING be most productive given the very limited time of
all of us in terms of advocating for more consistent/standard elements
of PBM?
On Wed, Sep 21, 2016 at 1:00 PM, David Singer <singer@apple.com> wrote:
> Hi
>
> at the face-to-face in Lisbon we talked about exploring ‘incognito’ or
> private-browsing mode, its problems, misperceptions, and what might be the
> possibilities for standardization, and to end up with a discussion paper. I
> promised to kick off the discussion. This is the kick-off, so discuss away;
> add what I missed, disagree with me, and so on!
>
> Mark Nottingham has a write-up of PBM at
> https://gist.github.com/mnot/96440a5ca74fcf328d23. There is also a wealth
> of research on what users think.
>
>
> 1) Non-uniformity of approach. The various browsers use different names for
> this, and more importantly, they differ slightly in what’s done.
>
> 1.1) While this enables differentiation, to what extent does this lead to
> user confusion?
>
> 2) Many users believe that this mode provides enhanced protection from
> network snooping, or from server recording and tracking. Actually, servers
> are unaware, and most or all browsers don’t insist on HTTPS — and even if
> they did, the network can obviously see what sites are being visited (as
> they have to help deliver the packets). We probably don’t want to move to
> full-on TOR.
>
> 2.1) To what extent could or should we enable servers to know “heh, I am
> trying to be private here!”? Note that we’ve informally discussed this
> before (e.g. at last year’s TPAC). What are the positive use-cases and what
> are the major concerns with this?
>
> 2.2) If we were to recommend some uniformity of behavior (see 1.1), should
> that include recommending https-only?
>
> 2.3) Sometimes in this mode the browser tries to reduce its fingerprint
> surface. Should this be part of the recommendation?
>
> 2.4) Should we recommend deeper-level fingerprint protection e.g. changing
> the IP address, if possible?
>
> 3) Some sites know that they might be sensitive; orthogonally to the
> possible user->server signal, should a server be able to suggest “you
> probably want to be in the incog mode when browsing here”? Would it help at
> all if one had to visit the site anyway, to learn this?
>
> 4) This mode mixes several concepts; should we disentangle them?
>
>
>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871
Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner

Hello all,
Thanks again to all of you who participated in the PING TPAC meeting,
either in person or remotely. I’ve pulled together a summary of what was
discussed, including some future work items, to supplement the minutes that
can be found online at https://www.w3.org/2016/09/20-privacy-minutes.html
TPAC discussion topics:
* Mitigating Browser Fingerprinting in Web Specifications
Nick Doty gave an overview of this document [1] to the group (including its
structure and purpose) before discussing the open issues to be resolved.
Feedback from the TAG and PING identified items that are marked "pending
review" [2]; issues 11 and 13 were discussed. Issue 11 is on providing
hooks for instrumentation/detection of fingerprinting -- ways to make it
easier for browser extensions to reveal website activity. The conclusion
was that this is not something to include in this guidance document, given
that instrumentation is mostly implementation-specific, not Web-specific.
Issue 13 is on actionability -- how to make the document more readily
applied in practice. To date, we’ve had a few people use this document, but
could dig further to see how useful it has been. Also this could be tied in
with the privacy questionnaire; they are two separate documents but they
could be integrated more (e.g., with relevant elements from fingerprinting
guidance surfaced in the event that this consideration arises in the
privacy questionnaire). After further discussion, Nick noted it would be
useful to close out the “pending-review” items, solicit some additional
feedback from other groups, and to get this document in a note by the end
of the year.
* PING privacy questionnaire
Christine Runnegar led discussion of the privacy questionnaire [3], which
was developed to help authors to identify and address privacy implications
of their specifications. The TPAC meeting was spent in reviewing the
current state of the document and identifying items for future work, with
the goal being a working draft by the end of the year. The challenge is
produce a questionnaire with enough guidance to be helpful, without it
being overwhelming. One proposal was that those with security expertise
could try to draft a questionnaire as a starting point; Joe Hall and Kepeng
Li volunteered to do this. A process item was raised: we may need to
determine at what stage of spec development the privacy considerations
would be expected to be included; this could be discussed with Ralph Swick
(W3C). As for concrete work, it was suggested that we could combine the TAG
and PING questionnaires and begin with a “high-level” overview (suggested
by Mike West) followed by more detailed sections.
* Privacy Protection Principles
Kepeng Li sent a message to the PING mailing list on privacy protection
principles [4], to help in furthering privacy discussions, which he
presented to the group. The discussion highlighted how there were several
related works (e.g., OECD privacy guidelines, US FIPPs) that provide
foundational principles; this may not be the right document to develop
through PING. However, it is possible that some parts of this document may
be useful for the privacy questionnaire; Kepeng will explore this avenue.
* Terminology discussion
As part of a mailing list discussion about documentation, Joe Hall asked
whether a standardized privacy vocabulary would be useful in our work [5].
There are words that we may need to define in order have consistency and
clarity (e.g., “spoof”; “randomize”). This need not be exhaustive but a
basic list might be helpful; there was general support for creating such a
list and hosting it on a wiki or GitHub.
* Planning next year's work
TPAC provided a great opportunity for planning what PING should be engaged
with over the next year. We have already identified work we need to
complete on documents (e.g., group notes) as well as conducting regular
reviews, but this was an opportunity to identify additional items. A
number of ideas were floated at the IETF F2F meeting [6], which were used
as a starting point for the TPAC discussion.
-
Privacy/incognito mode: there have been various discussions both within
and outside the W3C (e.g., “privacy mode” [7]) about the different
interpretations of this concept. Many different aspects of user privacy
have been conflated under this umbrella, leading to much confusion. There
was interest within the group for finding ways to improve the situation
(e.g., developing a document); David Singer volunteered to spearhead this
work.
-
Data gathering on privacy-violating techniques: given the state of
sophistication of the web, where advances in techniques (like
fingerprinting) can move quickly, it may be helpful to have a means for
collecting relevant research in one place for reference. This might also
include (where possible) information about large-scale behaviours (e.g.,
user behaviours), as this data is used to motivate and direct
privacy-focused work in the Web space.
-
Making privacy reviews more systematic: this was an item raised by Joe
Hall, who was trying to find ways to improve PING’s overall process. There
was discussion of the ways in which the TAG carries out reviews, as
possible model; there is a need to ensure things remain scalable. It may be
helpful to streamline the process by which reviews are requested (in
general); following the GitHub repository for spec reviews [8] might
provide a means for keeping basic track of items.
[1] https://github.com/w3c/fingerprinting-guidance
[2] https://github.com/w3c/fingerprinting-guidance/issues/
[3] https://github.com/w3c/ping/blob/master/privacy-questions.html
[4] https://www.w3.org/wiki/Privacy/Privacy_protection_principles
[5] https://lists.w3.org/Archives/Public/public-privacy/2016JulSep/0038.html
[6] https://lists.w3.org/Archives/Public/public-privacy/2016JulSep/0018.html
[7] https://gist.github.com/mnot/96440a5ca74fcf328d23
[8] https://github.com/w3ctag/spec-reviews/issues/

Hi Tara,
Thanks a lot. I'm looking forward to the aspects of user behavioral privacy
issues.
Happy to help here.
Best
Lukasz
2016-10-20 6:10 GMT+01:00 Tara Whalen <tjwhalen@gmail.com>:
> Hello all,
>
> Thanks again to all of you who participated in the PING TPAC meeting,
> either in person or remotely. I’ve pulled together a summary of what was
> discussed, including some future work items, to supplement the minutes that
> can be found online at https://www.w3.org/2016/09/20-privacy-minutes.html
>
> TPAC discussion topics:
>
>
> * Mitigating Browser Fingerprinting in Web Specifications
>
> Nick Doty gave an overview of this document [1] to the group (including
> its structure and purpose) before discussing the open issues to be
> resolved. Feedback from the TAG and PING identified items that are marked
> "pending review" [2]; issues 11 and 13 were discussed. Issue 11 is on
> providing hooks for instrumentation/detection of fingerprinting -- ways to
> make it easier for browser extensions to reveal website activity. The
> conclusion was that this is not something to include in this guidance
> document, given that instrumentation is mostly implementation-specific, not
> Web-specific. Issue 13 is on actionability -- how to make the document more
> readily applied in practice. To date, we’ve had a few people use this
> document, but could dig further to see how useful it has been. Also this
> could be tied in with the privacy questionnaire; they are two separate
> documents but they could be integrated more (e.g., with relevant elements
> from fingerprinting guidance surfaced in the event that this consideration
> arises in the privacy questionnaire). After further discussion, Nick noted
> it would be useful to close out the “pending-review” items, solicit some
> additional feedback from other groups, and to get this document in a note
> by the end of the year.
>
>
> * PING privacy questionnaire
>
> Christine Runnegar led discussion of the privacy questionnaire [3], which
> was developed to help authors to identify and address privacy implications
> of their specifications. The TPAC meeting was spent in reviewing the
> current state of the document and identifying items for future work, with
> the goal being a working draft by the end of the year. The challenge is
> produce a questionnaire with enough guidance to be helpful, without it
> being overwhelming. One proposal was that those with security expertise
> could try to draft a questionnaire as a starting point; Joe Hall and Kepeng
> Li volunteered to do this. A process item was raised: we may need to
> determine at what stage of spec development the privacy considerations
> would be expected to be included; this could be discussed with Ralph Swick
> (W3C). As for concrete work, it was suggested that we could combine the TAG
> and PING questionnaires and begin with a “high-level” overview (suggested
> by Mike West) followed by more detailed sections.
>
>
> * Privacy Protection Principles
>
> Kepeng Li sent a message to the PING mailing list on privacy protection
> principles [4], to help in furthering privacy discussions, which he
> presented to the group. The discussion highlighted how there were several
> related works (e.g., OECD privacy guidelines, US FIPPs) that provide
> foundational principles; this may not be the right document to develop
> through PING. However, it is possible that some parts of this document may
> be useful for the privacy questionnaire; Kepeng will explore this avenue.
>
>
> * Terminology discussion
>
> As part of a mailing list discussion about documentation, Joe Hall asked
> whether a standardized privacy vocabulary would be useful in our work [5].
> There are words that we may need to define in order have consistency and
> clarity (e.g., “spoof”; “randomize”). This need not be exhaustive but a
> basic list might be helpful; there was general support for creating such a
> list and hosting it on a wiki or GitHub.
>
>
> * Planning next year's work
>
> TPAC provided a great opportunity for planning what PING should be engaged
> with over the next year. We have already identified work we need to
> complete on documents (e.g., group notes) as well as conducting regular
> reviews, but this was an opportunity to identify additional items. A
> number of ideas were floated at the IETF F2F meeting [6], which were used
> as a starting point for the TPAC discussion.
>
>
> -
>
> Privacy/incognito mode: there have been various discussions both
> within and outside the W3C (e.g., “privacy mode” [7]) about the different
> interpretations of this concept. Many different aspects of user privacy
> have been conflated under this umbrella, leading to much confusion. There
> was interest within the group for finding ways to improve the situation
> (e.g., developing a document); David Singer volunteered to spearhead this
> work.
>
>
> -
>
> Data gathering on privacy-violating techniques: given the state of
> sophistication of the web, where advances in techniques (like
> fingerprinting) can move quickly, it may be helpful to have a means for
> collecting relevant research in one place for reference. This might also
> include (where possible) information about large-scale behaviours (e.g.,
> user behaviours), as this data is used to motivate and direct
> privacy-focused work in the Web space.
> -
>
> Making privacy reviews more systematic: this was an item raised by Joe
> Hall, who was trying to find ways to improve PING’s overall process. There
> was discussion of the ways in which the TAG carries out reviews, as
> possible model; there is a need to ensure things remain scalable. It may be
> helpful to streamline the process by which reviews are requested (in
> general); following the GitHub repository for spec reviews [8] might
> provide a means for keeping basic track of items.
>
>
> [1] https://github.com/w3c/fingerprinting-guidance
>
> [2] https://github.com/w3c/fingerprinting-guidance/issues/
>
> [3] https://github.com/w3c/ping/blob/master/privacy-questions.html
>
> [4] https://www.w3.org/wiki/Privacy/Privacy_protection_principles
>
> [5] https://lists.w3.org/Archives/Public/public-privacy/
> 2016JulSep/0038.html
>
> [6] https://lists.w3.org/Archives/Public/public-privacy/
> 2016JulSep/0018.html
>
> [7] https://gist.github.com/mnot/96440a5ca74fcf328d23
>
> [8] https://github.com/w3ctag/spec-reviews/issues/
>
>
>

Dear Privacy Interest Group,
The WebRTC Working Group and Device and Sensors Working Group are
working toward publishing their Audio Output Devices API to Candidate
Recommendation and are thus seeking review from a variety of groups on
the document:
https://www.w3.org/TR/2016/WD-audio-output-20161014/
We are particularly interested on feedback from the Privacy Interest
Group on the impact on privacy (and the proposed mitigations) to the new
ability to play sound on specific audio devices.
We of course also welcome feedback on any other aspect of the
specification.
We would appreciate to receive feedback before November 11. We hope to
transition request to Candidate Recommendation by the end of this year.
If you have any comments, we prefer you submit them as Github issues:
https://github.com/w3c/mediacapture-output/issues
Alternatively, you can send your comments by email to
public-mediacapture@w3.org.
Thanks,
For the WebRTC and DAS chairs,
Stefan Hakansson

(if an issue arises, happy to put them into github... staying here for
the moment)
Heya, I took a look at this spec and had a question about the example
in the privacy considerations section:
https://www.w3.org/TR/2016/WD-audio-output-20161014/#privacy-considerations
There, is says, "Authorization is necessary because playing audio out
of a non-default device may be unexpected behavior to the user, and
may cause a nuisance. For example, suppose a user is in a library or
other quiet public place where she is using a laptop with system audio
directed to a USB headset. Her expectation is that the laptop’s audio
is private and she will not disturb others. If any Web application can
direct audio output through arbitrary output devices, a mischievous
website may play loud audio out of the laptop’s external speakers
without the user’s consent."
The case I can think of at the moment (because it's happening on my
system right now!) is Spotify... we'll pretend through a browser UA
and not it's native app. Presumably, in typical use of a site like
spotify.com to play audio, the user quickly (within a few days) gives
permission (if needed) to spotify.com to output audio to external
speakers and any headsets they may use. So, certainly spotify.com
would be able to switch audio from one to the other (and from the
spec, it sounds like if the USB headset is removed an becomes
unavailalbe, the sinkId for the external speakers is likely to be
chosen in a non-paused state)?
It might make sense to have that example be a bit more robust... for
example, you could describe the user listening to audio at foo.com on
USB headset and another tab at bar.com wants to direct audio ouput to
external speakers, perhaps to play an ultrasonic beacon code that
humans can't hear? (e.g., trying to signal across origins in different
tabs or something).
Or maybe I have this wrong? best, Joe
On Wed, Oct 19, 2016 at 9:24 AM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> Dear Privacy Interest Group,
>
> The WebRTC Working Group and Device and Sensors Working Group are
> working toward publishing their Audio Output Devices API to Candidate
> Recommendation and are thus seeking review from a variety of groups on
> the document:
> https://www.w3.org/TR/2016/WD-audio-output-20161014/
>
> We are particularly interested on feedback from the Privacy Interest
> Group on the impact on privacy (and the proposed mitigations) to the new
> ability to play sound on specific audio devices.
>
> We of course also welcome feedback on any other aspect of the
> specification.
>
> We would appreciate to receive feedback before November 11. We hope to
> transition request to Candidate Recommendation by the end of this year.
>
> If you have any comments, we prefer you submit them as Github issues:
> https://github.com/w3c/mediacapture-output/issues
>
> Alternatively, you can send your comments by email to
> public-mediacapture@w3.org.
>
> Thanks,
>
> For the WebRTC and DAS chairs,
> Stefan Hakansson
>
>
--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871
Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner

another scenario we are looking at are the ads which auto run video & audio.. effectively drive bys
Sent from my iPhone
> On Oct 31, 2016, at 1:33 PM, Joseph Lorenzo Hall <joe@cdt.org> wrote:
>
> (if an issue arises, happy to put them into github... staying here for
> the moment)
>
> Heya, I took a look at this spec and had a question about the example
> in the privacy considerations section:
>
> https://www.w3.org/TR/2016/WD-audio-output-20161014/#privacy-considerations
>
> There, is says, "Authorization is necessary because playing audio out
> of a non-default device may be unexpected behavior to the user, and
> may cause a nuisance. For example, suppose a user is in a library or
> other quiet public place where she is using a laptop with system audio
> directed to a USB headset. Her expectation is that the laptop’s audio
> is private and she will not disturb others. If any Web application can
> direct audio output through arbitrary output devices, a mischievous
> website may play loud audio out of the laptop’s external speakers
> without the user’s consent."
>
> The case I can think of at the moment (because it's happening on my
> system right now!) is Spotify... we'll pretend through a browser UA
> and not it's native app. Presumably, in typical use of a site like
> spotify.com to play audio, the user quickly (within a few days) gives
> permission (if needed) to spotify.com to output audio to external
> speakers and any headsets they may use. So, certainly spotify.com
> would be able to switch audio from one to the other (and from the
> spec, it sounds like if the USB headset is removed an becomes
> unavailalbe, the sinkId for the external speakers is likely to be
> chosen in a non-paused state)?
>
> It might make sense to have that example be a bit more robust... for
> example, you could describe the user listening to audio at foo.com on
> USB headset and another tab at bar.com wants to direct audio ouput to
> external speakers, perhaps to play an ultrasonic beacon code that
> humans can't hear? (e.g., trying to signal across origins in different
> tabs or something).
>
> Or maybe I have this wrong? best, Joe
>
> On Wed, Oct 19, 2016 at 9:24 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> Dear Privacy Interest Group,
>>
>> The WebRTC Working Group and Device and Sensors Working Group are
>> working toward publishing their Audio Output Devices API to Candidate
>> Recommendation and are thus seeking review from a variety of groups on
>> the document:
>> https://www.w3.org/TR/2016/WD-audio-output-20161014/
>>
>> We are particularly interested on feedback from the Privacy Interest
>> Group on the impact on privacy (and the proposed mitigations) to the new
>> ability to play sound on specific audio devices.
>>
>> We of course also welcome feedback on any other aspect of the
>> specification.
>>
>> We would appreciate to receive feedback before November 11. We hope to
>> transition request to Candidate Recommendation by the end of this year.
>>
>> If you have any comments, we prefer you submit them as Github issues:
>> https://github.com/w3c/mediacapture-output/issues
>>
>> Alternatively, you can send your comments by email to
>> public-mediacapture@w3.org.
>>
>> Thanks,
>>
>> For the WebRTC and DAS chairs,
>> Stefan Hakansson
>>
>>
>
>
>
> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871
>
> Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner
>

I think these privacy considerations are woefully inadequate.
I would encourage people to open up their preferences and look at what the system has available as output devices. In my case, on a Mac, it includes:
* headphone port
* display audio
* an dozens of Apple TV devices, many of them with descriptive names (I am at work)
Fingerprinting: a site can work out if I am at work or not by seeing whether I have a display connected. If the sites see the AppleTV devices, it can fingerprint me much more, and indeed can connect me with other devices that see the same or similar sets of outputs. Increasingly, projectors, TVs, and other devices have wireless capability to behave as an output device. This is undiscussed.
Beaconing: as you say, it might emit beacons if it thinks it’s on speakers. Indeed, if it has access to AirPlay, it might cycle through the set of devices and see which ones are audible to someone else, and connect me. This API came from the WebRTC group and to do RTC one needs microphone access, after all.
Since the draft does not discuss the motivation for this API, it’s hard to see how to mitigate the problems. In general, I think APIs that think about “devices” rather than “functions” are problematic for security, for privacy, and maybe even for portability; it is the wrong mind-set.
> On Oct 31, 2016, at 13:30 , Joseph Lorenzo Hall <joe@cdt.org> wrote:
>
> (if an issue arises, happy to put them into github... staying here for
> the moment)
>
> Heya, I took a look at this spec and had a question about the example
> in the privacy considerations section:
>
> https://www.w3.org/TR/2016/WD-audio-output-20161014/#privacy-considerations
>
> There, is says, "Authorization is necessary because playing audio out
> of a non-default device may be unexpected behavior to the user, and
> may cause a nuisance. For example, suppose a user is in a library or
> other quiet public place where she is using a laptop with system audio
> directed to a USB headset. Her expectation is that the laptop’s audio
> is private and she will not disturb others. If any Web application can
> direct audio output through arbitrary output devices, a mischievous
> website may play loud audio out of the laptop’s external speakers
> without the user’s consent."
>
> The case I can think of at the moment (because it's happening on my
> system right now!) is Spotify... we'll pretend through a browser UA
> and not it's native app. Presumably, in typical use of a site like
> spotify.com to play audio, the user quickly (within a few days) gives
> permission (if needed) to spotify.com to output audio to external
> speakers and any headsets they may use. So, certainly spotify.com
> would be able to switch audio from one to the other (and from the
> spec, it sounds like if the USB headset is removed an becomes
> unavailalbe, the sinkId for the external speakers is likely to be
> chosen in a non-paused state)?
>
> It might make sense to have that example be a bit more robust... for
> example, you could describe the user listening to audio at foo.com on
> USB headset and another tab at bar.com wants to direct audio ouput to
> external speakers, perhaps to play an ultrasonic beacon code that
> humans can't hear? (e.g., trying to signal across origins in different
> tabs or something).
>
> Or maybe I have this wrong? best, Joe
>
> On Wed, Oct 19, 2016 at 9:24 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> Dear Privacy Interest Group,
>>
>> The WebRTC Working Group and Device and Sensors Working Group are
>> working toward publishing their Audio Output Devices API to Candidate
>> Recommendation and are thus seeking review from a variety of groups on
>> the document:
>> https://www.w3.org/TR/2016/WD-audio-output-20161014/
>>
>> We are particularly interested on feedback from the Privacy Interest
>> Group on the impact on privacy (and the proposed mitigations) to the new
>> ability to play sound on specific audio devices.
>>
>> We of course also welcome feedback on any other aspect of the
>> specification.
>>
>> We would appreciate to receive feedback before November 11. We hope to
>> transition request to Candidate Recommendation by the end of this year.
>>
>> If you have any comments, we prefer you submit them as Github issues:
>> https://github.com/w3c/mediacapture-output/issues
>>
>> Alternatively, you can send your comments by email to
>> public-mediacapture@w3.org.
>>
>> Thanks,
>>
>> For the WebRTC and DAS chairs,
>> Stefan Hakansson
>>
>>
>
>
>
> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871
>
> Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner
>
David Singer
Manager, Software Standards, Apple Inc.

Craig, David and Joseph,
thanks for your input. We'll look into it.
Stefan
On 31/10/16 22:28, David Singer wrote:
> I think these privacy considerations are woefully inadequate.
>
> I would encourage people to open up their preferences and look at what the system has available as output devices. In my case, on a Mac, it includes:
>
> * headphone port
> * display audio
> * an dozens of Apple TV devices, many of them with descriptive names (I am at work)
>
> Fingerprinting: a site can work out if I am at work or not by seeing whether I have a display connected. If the sites see the AppleTV devices, it can fingerprint me much more, and indeed can connect me with other devices that see the same or similar sets of outputs. Increasingly, projectors, TVs, and other devices have wireless capability to behave as an output device.. This is undiscussed.
>
> Beaconing: as you say, it might emit beacons if it thinks it’s on speakers. Indeed, if it has access to AirPlay, it might cycle through the set of devices and see which ones are audible to someone else, and connect me. This API came from the WebRTC group and to do RTC one needs microphone access, after all.
>
> Since the draft does not discuss the motivation for this API, it’s hard to see how to mitigate the problems. In general, I think APIs that think about “devices” rather than “functions” are problematic for security, for privacy, and maybe even for portability; it is the wrong mind-set.
>
>
>> On Oct 31, 2016, at 13:30 , Joseph Lorenzo Hall <joe@cdt.org> wrote:
>>
>> (if an issue arises, happy to put them into github... staying here for
>> the moment)
>>
>> Heya, I took a look at this spec and had a question about the example
>> in the privacy considerations section:
>>
>> https://www.w3.org/TR/2016/WD-audio-output-20161014/#privacy-considerations
>>
>> There, is says, "Authorization is necessary because playing audio out
>> of a non-default device may be unexpected behavior to the user, and
>> may cause a nuisance. For example, suppose a user is in a library or
>> other quiet public place where she is using a laptop with system audio
>> directed to a USB headset. Her expectation is that the laptop’s audio
>> is private and she will not disturb others. If any Web application can
>> direct audio output through arbitrary output devices, a mischievous
>> website may play loud audio out of the laptop’s external speakers
>> without the user’s consent."
>>
>> The case I can think of at the moment (because it's happening on my
>> system right now!) is Spotify... we'll pretend through a browser UA
>> and not it's native app. Presumably, in typical use of a site like
>> spotify.com to play audio, the user quickly (within a few days) gives
>> permission (if needed) to spotify.com to output audio to external
>> speakers and any headsets they may use. So, certainly spotify.com
>> would be able to switch audio from one to the other (and from the
>> spec, it sounds like if the USB headset is removed an becomes
>> unavailalbe, the sinkId for the external speakers is likely to be
>> chosen in a non-paused state)?
>>
>> It might make sense to have that example be a bit more robust... for
>> example, you could describe the user listening to audio at foo.com on
>> USB headset and another tab at bar.com wants to direct audio ouput to
>> external speakers, perhaps to play an ultrasonic beacon code that
>> humans can't hear? (e.g., trying to signal across origins in different
>> tabs or something).
>>
>> Or maybe I have this wrong? best, Joe
>>
>> On Wed, Oct 19, 2016 at 9:24 AM, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com> wrote:
>>> Dear Privacy Interest Group,
>>>
>>> The WebRTC Working Group and Device and Sensors Working Group are
>>> working toward publishing their Audio Output Devices API to Candidate
>>> Recommendation and are thus seeking review from a variety of groups on
>>> the document:
>>> https://www.w3.org/TR/2016/WD-audio-output-20161014/
>>>
>>> We are particularly interested on feedback from the Privacy Interest
>>> Group on the impact on privacy (and the proposed mitigations) to the new
>>> ability to play sound on specific audio devices.
>>>
>>> We of course also welcome feedback on any other aspect of the
>>> specification.
>>>
>>> We would appreciate to receive feedback before November 11. We hope to
>>> transition request to Candidate Recommendation by the end of this year.
>>>
>>> If you have any comments, we prefer you submit them as Github issues:
>>> https://github.com/w3c/mediacapture-output/issues
>>>
>>> Alternatively, you can send your comments by email to
>>> public-mediacapture@w3.org.
>>>
>>> Thanks,
>>>
>>> For the WebRTC and DAS chairs,
>>> Stefan Hakansson
>>>
>>>
>>
>>
>>
>> --
>> Joseph Lorenzo Hall
>> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
>> 1401 K ST NW STE 200, Washington DC 20005-3497
>> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871
>>
>> Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner
>>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>

Re: List of self-questionnaires to facilitate wide reviews and reminderMarkinfo@smartspecies.commid:B165F82A-8E2B-4387-A951-5913498F51EC@smartspecies.com2016-10-09T21:09:48+01:00

Hi David,
You bring up an interesting point and just the right time (for me at least)
> On 7 Oct 2016, at 17:12, David Singer <singer@apple.com> wrote:
>
> I don’t think security and privacy are the same, and it’s confusing to have them in the same set of questions.
I have been thinking about this issue a lot lately and its something that we are assessing in terms of the consent receipt specification at Kantara in the Consent & Information Sharing WG.
There is the issue about the security of the personal and personal information, which I am aware, not being a security specialist may be a dichotomy I am myself making.
But, I have proposed to the WG that is doing this work that we add the PII confidentiality levels from NIST, to the specification. From my point of view, an individual should be able to tell a data controller that the PII being disclosed is highly confidential. IN this context then, the data controller, from my non-specialist point of view, would then have a greater responsibility to secure the the PII in storage, transit and disclosure.
In this context - it can be confusing, but, I am wondering if you might have an opinion on wether or not this is an appropriate method for creating a security expectation in a privacy enhancing context. ?
Kind Regards,
Mark

Seeking feedback on "user consent" text in Web Payments Working Group specificationIan Jacobsij@w3.orgmid:5DCE81B0-952D-4B49-96B7-4613E4D04FC6@w3.org2016-10-06T10:22:03-05:00

Dear Privacy IG,
The Web Payments WG’s draft “Payment Request API” [1] involves user actions
to share some information with a merchant (e.g., credit card details, shipping address).
We would like to make it clear in the specification that that information should not be
shared without user consent. Opinions vary on how much (if any) guidance to provide
about securing user content.
I would like to ask for your review of the proposal below, which would appear in
our “Privacy Considerations” (section 18). Please let me know whether you find the text
below useful and sufficient.
For comparison, an analogous section in the Media Capture and Streams specification goes into
greater detail:
https://w3c.github.io/mediacapture-main/getusermedia.html#privacy-and-security-considerations
Thank you,
Ian
[1] https://w3c.github.io/browser-payment-api/
=================
Proposal for 18.1 Exposing user information
Capturing user information (payment credentials, shipping address, etc.) exposes personally-identifiable information to applications.
The user agent should never share user information to the web page without user consent.
For a number of reasons, this specification does not recommend particular practices for establishing user consent:
• What constitutes user consent from a regulatory perspective may vary by jurisdiction.
• Users provide consent through a variety of mechanisms, both case-by-case (e.g., one-time click-through agreement)
and persistent (e.g., contractual agreements that involve a single user interaction, user agent settings, and operating system settings).
• There are numerous good practices for establishing consent, such as clear notice to the user about implications of an action,
usability of configuration interfaces to view and change user decisions, and avoiding unnecessary prompts. Developers should
therefore consult up-to-date good practice documentation, which may vary by region, browser, operating system, and payment system.
--
Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs
Tel: +1 718 260 9447

> On Fri, Oct 07, 2016 at 05:38:19, Lukasz Olejnik (W3C) wrote:
> The UA MUST inform about the past and current uses of the API "
That seems unnecessary. When someone is trying to checkout in an online
store, they don't expect to see all the times other web sites might
have called the API.
The question at hand here is the degree to which user consent can
be defined in a technical specification where UX is out of scope.
We have lots of experience in other working groups of trying to
specify this and given the different legal and regulatory
environments around the world, I posit that we should not be
trying to specify such policy in this kind of document. It is
sufficient to be clear that UAs will not release information
in the absence of consent, whatever form that takes.

Ian - thanks for the opportunity to comment.
I agree that there is complexity here and that it is not advisable to try
to specify a complete UX experience. However, the specification
over-emphasizes the degree of regional variation in best practice and is
likely to encourage implementers to through up their hands. There is
nothing in the proposed language that a developer can implement, so many
will do nothing. Or, if they work for a responsible organization, they will
talk to their lawyers.
Just because there isn't global agreement on what is required it does not
mean that W3C should wash its hands of enabling some minimum standard best
privacy practice.
Good minimum privacy practice when handling personal data requires
transparency for users and the various intermediaries along the way who use
this data.
For users, when personal data is transferred, there should be a clear
policy about how it is handled. That is, I would argue, the minimum
required by nearly all legal systems and is just plain good design.
For implementers, when receiving or processing personal data, they should
know whether the user has consented to the transfer and under what terms.
To enable user agent developers to meet these goals, I would simply provide
a mechanism in the protocol to indicate two facts:
(a) was user consent provided? (could be a boolean or a JSON object)
(b) under what policy (specified by a URI)
By making these two simple pieces of data visible in the mechanism, W3C
will provide users and implementers a tractable way to be sure that privacy
issues are addressed and that the privacy conditions can easily travel
along with the personal data through the API.
W3C has been down the path of trying to specific the semantics of such
policy (with P3P) and that was complicated. I don't suggest going back
there. However, I do think it would be good practice to enable this
protocol, which seems to be very careful about how to communication about
mundane (but sensitive) things like shipping addresses (and which have
considerable international variation), to also look at how to be sure that
personal data is handled with awareness of privacy practice.
Best
Danny
--
Daniel J. Weitzner, Principal Research Scientist
Director, MIT Internet Policy Research Initiative
Massachusetts Institute of Technology
Tel: +1 617 253 8036
On Fri, Oct 7, 2016 at 9:24 AM Adrian Bateman <adrianba@microsoft.com>
wrote:
> > On Fri, Oct 07, 2016 at 05:38:19, Lukasz Olejnik (W3C) wrote:
> > The UA MUST inform about the past and current uses of the API "
>
> That seems unnecessary. When someone is trying to checkout in an online
> store, they don't expect to see all the times other web sites might
> have called the API.
>
> The question at hand here is the degree to which user consent can
> be defined in a technical specification where UX is out of scope.
> We have lots of experience in other working groups of trying to
> specify this and given the different legal and regulatory
> environments around the world, I posit that we should not be
> trying to specify such policy in this kind of document. It is
> sufficient to be clear that UAs will not release information
> in the absence of consent, whatever form that takes.
>

Hi Danny,
Thank you for the feedback. Notes inline.
Ian
> On Oct 18, 2016, at 3:03 PM, Daniel Weitzner <weitzner@mit.edu> wrote:
>
> Ian - thanks for the opportunity to comment.
>
> I agree that there is complexity here and that it is not advisable to try to specify a complete UX experience. However, the specification over-emphasizes the degree of regional variation in best practice and is likely to encourage implementers to through up their hands. There is nothing in the proposed language that a developer can implement, so many will do nothing. Or, if they work for a responsible organization, they will talk to their lawyers.
>
> Just because there isn't global agreement on what is required it does not mean that W3C should wash its hands of enabling some minimum standard best privacy practice.
>
> Good minimum privacy practice when handling personal data requires transparency for users and the various intermediaries along the way who use this data.
>
> For users, when personal data is transferred, there should be a clear policy about how it is handled. That is, I would argue, the minimum required by nearly all legal systems and is just plain good design.
>
> For implementers, when receiving or processing personal data, they should know whether the user has consented to the transfer and under what terms.
>
> To enable user agent developers to meet these goals, I would simply provide a mechanism in the protocol to indicate two facts:
>
> (a) was user consent provided? (could be a boolean or a JSON object)
> (b) under what policy (specified by a URI)
Regarding point (b), it seems to me that when you shop on an E-Commerce site, the merchant defines the terms and conditions for interaction.
As just one example, here are the terms for target.com, which includes a section on how transaction data will be used:
http://www.target.com/c/terms-conditions/-/N-4sr7l
Is the suggestion that the e-commerce paradigm change so that users specify their own terms and conditions for how they agree for others to use their data?
Regarding point (a), it seems to me that if the spec says “the user agent must not share data it collects without user consent” then a flag is unnecessary.
Completion of the API signals consent.
If the language remains “SHOULD NEVER” and the user agent “knows” it is sharing data without user consent, then it seems there is room for a boolean.
Per Barry’s point, I think the group needs to review MUST NOT v. SHOULD NEVER.
Ian
>
> By making these two simple pieces of data visible in the mechanism, W3C will provide users and implementers a tractable way to be sure that privacy issues are addressed and that the privacy conditions can easily travel along with the personal data through the API.
>
> W3C has been down the path of trying to specific the semantics of such policy (with P3P) and that was complicated. I don't suggest going back there. However, I do think it would be good practice to enable this protocol, which seems to be very careful about how to communication about mundane (but sensitive) things like shipping addresses (and which have considerable international variation), to also look at how to be sure that personal data is handled with awareness of privacy practice.
>
--
Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs
Tel: +1 718 260 9447

Hi Ian,
I wonder if the "allowpaymentrequest" attribute on an iframe is sufficient to stop rogue script dynamically creating iframes which present bogus payment requests to the user. Maybe a CSP directive would work here, or at least block payment requests from iframes when the top level context is not secure.
Mike
-----Original Message-----
From: Ian Jacobs [mailto:ij@w3.org]
Sent: 06 October 2016 16:22
To: public-privacy@w3.org
Cc: Adam Roach <abr@mozilla.com>; Telford-Reed, Nick <Nick.Telford-Reed@worldpay.com>; Adrian Hope-Bailie <adrian@ripple.com>
Subject: Seeking feedback on "user consent" text in Web Payments Working Group specification
Dear Privacy IG,
The Web Payments WG’s draft “Payment Request API” [1] involves user actions
to share some information with a merchant (e.g., credit card details, shipping address).
We would like to make it clear in the specification that that information should not be
shared without user consent. Opinions vary on how much (if any) guidance to provide
about securing user content.
I would like to ask for your review of the proposal below, which would appear in
our “Privacy Considerations” (section 18). Please let me know whether you find the text
below useful and sufficient.
For comparison, an analogous section in the Media Capture and Streams specification goes into
greater detail:
https://w3c.github.io/mediacapture-main/getusermedia.html#privacy-and-security-considerations
Thank you,
Ian
[1] https://w3c.github.io/browser-payment-api/
=================
Proposal for 18.1 Exposing user information
Capturing user information (payment credentials, shipping address, etc.) exposes personally-identifiable information to applications.
The user agent should never share user information to the web page without user consent.
For a number of reasons, this specification does not recommend particular practices for establishing user consent:
• What constitutes user consent from a regulatory perspective may vary by jurisdiction.
• Users provide consent through a variety of mechanisms, both case-by-case (e.g., one-time click-through agreement)
and persistent (e.g., contractual agreements that involve a single user interaction, user agent settings, and operating system settings).
• There are numerous good practices for establishing consent, such as clear notice to the user about implications of an action,
usability of configuration interfaces to view and change user decisions, and avoiding unnecessary prompts. Developers should
therefore consult up-to-date good practice documentation, which may vary by region, browser, operating system, and payment system.
--
Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs
Tel: +1 718 260 9447

> On Fri, Oct 07, 2016 at 06:42:59, Mike O'Neill wrote:
> I wonder if the "allowpaymentrequest" attribute on an iframe is
> sufficient to stop rogue script dynamically creating iframes which
> present bogus payment requests to the user. Maybe a CSP directive would
> work here, or at least block payment requests from iframes when the top
> level context is not secure.
iframes for which the top level context is not secure are not Secure Contexts
and so the PaymentRequest API isn't available.

The secure context requirement mitigates rogue script being inserted externally, say by a MITM, but not the risk of bad script generated by a compromised third-party script server or poor site administration procedures. Given the honeypot the API creates it could be a good idea to have a belt & braces approach, say with a new "allowpaymentrequest-src" CSP directive i.e:
Content-Security-Policy: allowpaymentrequest-src paywidgit.com; [other CSP directives]
-----Original Message-----
From: Adrian Bateman [mailto:adrianba@microsoft.com]
Sent: 07 October 2016 19:14
To: Mike O'Neill <michael.oneill@baycloud.com>; 'Ian Jacobs' <ij@w3.org>; public-privacy@w3.org
Cc: 'Adam Roach' <abr@mozilla.com>; 'Telford-Reed, Nick' <Nick.Telford-Reed@worldpay.com>; 'Adrian Hope-Bailie' <adrian@ripple.com>
Subject: RE: Seeking feedback on "user consent" text in Web Payments Working Group specification
> On Fri, Oct 07, 2016 at 06:42:59, Mike O'Neill wrote:
> I wonder if the "allowpaymentrequest" attribute on an iframe is
> sufficient to stop rogue script dynamically creating iframes which
> present bogus payment requests to the user. Maybe a CSP directive would
> work here, or at least block payment requests from iframes when the top
> level context is not secure.
iframes for which the top level context is not secure are not Secure Contexts
and so the PaymentRequest API isn't available.

> The Web Payments WG’s draft “Payment Request API” [1] involves user actions
> to share some information with a merchant (e.g., credit card details, shipping address).
> We would like to make it clear in the specification that that information should not be
> shared without user consent. Opinions vary on how much (if any) guidance to provide
> about securing user content.
>
> I would like to ask for your review of the proposal below, which would appear in
> our “Privacy Considerations” (section 18). Please let me know whether you find the text
> below useful and sufficient.
...
> =================
> Proposal for 18.1 Exposing user information
>
> Capturing user information (payment credentials, shipping address,
> etc.) exposes personally-identifiable information to applications. The
> user agent should never share user information to the web page without
> user consent.
>
> For a number of reasons, this specification does not recommend
> particular practices for establishing user consent:
>
> • What constitutes user consent from a regulatory perspective
> may vary by jurisdiction.
>
> • Users provide consent through a variety of mechanisms, both
> case-by-case (e.g., one-time click-through agreement) and
> persistent (e.g., contractual agreements that involve a single
> user interaction, user agent settings, and operating system
> settings).
>
> • There are numerous good practices for establishing consent,
> such as clear notice to the user about implications of an
> action, usability of configuration interfaces to view and
> change user decisions, and avoiding unnecessary prompts.
> Developers should therefore consult up-to-date good practice
> documentation, which may vary by region, browser, operating
> system, and payment system.
It doesn't seem sufficient to me, as I have a different view of
transactional information. So let me back up for a moment:
When a consumer buys something (or otherwise does a "transaction") on
the Internet, I think there's a difference between the information
that the web site gets to create the user's account (let's call it
"account information") and that which it obtains for the purpose of
this transaction (let's call it "transaction information"). I think
the text above works mostly fine for account information (though I
would say MUST NOT share without consent), but isn't adequate for
transaction information.
I believe that transaction information MUST NOT be shared (never mind
consent) outside of what's necessary to complete the transaction (that
would include providing the credit card information to the bank to get
approval and process payment, providing the shipping address to the
shipping company, and that sort of thing). I think consumers assume
that a purchase transaction is private, and we need to keep it that
way.
Note, for example, that the consumer might provide an address as part
of the account setup, and that address would fall under the "only with
permission" sharing of account information. But if the user provided
a different shipping address for this transaction, it's transaction
information, and I'd say "must not share." (Of course, the merchant
might include a "Save this address to your account?" option in that
case, and if the user says yes then it becomes account information and
things are fuzzier. Which is why you're right not to go into too much
detail.)
I would also explicitly say that certain key account information, such
as saved credit cards and bank account information, MUST NOT be shared
as well, even though it's account information.
What, if anything, you want to say about collected information such as
what items the consumer looked at and which ones she purchased, is a
separate question, but it's also relevant here, and I don't think you
should ignore it. I'd say it falls under "not without user consent."
Finally, in any case, I think we need to be strong and consistent
about saying that we never share information without user consent,
hence my suggestion to change "should never share...without user
consent," to "MUST NOT share...without user consent."
Barry

Hi Barry,
Thank you for sending comments. Some clarifications and a suggested change inline.
Ian
> On Oct 18, 2016, at 10:43 AM, Barry Leiba <barryleiba@computer.org> wrote:
>
>> The Web Payments WG’s draft “Payment Request API” [1] involves user actions
>> to share some information with a merchant (e.g., credit card details, shipping address).
>> We would like to make it clear in the specification that that information should not be
>> shared without user consent. Opinions vary on how much (if any) guidance to provide
>> about securing user content.
>>
>> I would like to ask for your review of the proposal below, which would appear in
>> our “Privacy Considerations” (section 18). Please let me know whether you find the text
>> below useful and sufficient.
> ...
>> =================
>> Proposal for 18.1 Exposing user information
>>
>> Capturing user information (payment credentials, shipping address,
>> etc.) exposes personally-identifiable information to applications. The
>> user agent should never share user information to the web page without
>> user consent.
>>
>> For a number of reasons, this specification does not recommend
>> particular practices for establishing user consent:
>>
>> • What constitutes user consent from a regulatory perspective
>> may vary by jurisdiction.
>>
>> • Users provide consent through a variety of mechanisms, both
>> case-by-case (e.g., one-time click-through agreement) and
>> persistent (e.g., contractual agreements that involve a single
>> user interaction, user agent settings, and operating system
>> settings).
>>
>> • There are numerous good practices for establishing consent,
>> such as clear notice to the user about implications of an
>> action, usability of configuration interfaces to view and
>> change user decisions, and avoiding unnecessary prompts.
>> Developers should therefore consult up-to-date good practice
>> documentation, which may vary by region, browser, operating
>> system, and payment system.
>
> It doesn't seem sufficient to me, as I have a different view of
> transactional information. So let me back up for a moment:
>
> When a consumer buys something (or otherwise does a "transaction") on
> the Internet, I think there's a difference between the information
> that the web site gets to create the user's account (let's call it
> "account information") and that which it obtains for the purpose of
> this transaction (let's call it "transaction information”).
Agreed.
> I think
> the text above works mostly fine for account information (though I
> would say MUST NOT share without consent), but isn't adequate for
> transaction information.
The payment request API spec only details with transaction information.
>
> I believe that transaction information MUST NOT be shared (never mind
> consent) outside of what's necessary to complete the transaction (that
> would include providing the credit card information to the bank to get
> approval and process payment, providing the shipping address to the
> shipping company, and that sort of thing). I think consumers assume
> that a purchase transaction is private, and we need to keep it that
> way.
The payment request API only involves collection of information that is
necessary to complete the transaction. Perhaps we need to clarify
the text so that the scope of the recommendation is only about the
data gathered via the API. Something like:
"Capturing user information (payment credentials, shipping address,
etc.) exposes personally-identifiable information to applications. The
user agent should never share information captured via this
API to the web page without user consent.”
It’s a separate point whether the text says “SHOULD NEVER”
or “MUST NOT”.
>
> Note, for example, that the consumer might provide an address as part
> of the account setup, and that address would fall under the "only with
> permission" sharing of account information. But if the user provided
> a different shipping address for this transaction, it's transaction
> information, and I'd say "must not share." (Of course, the merchant
> might include a "Save this address to your account?" option in that
> case, and if the user says yes then it becomes account information and
> things are fuzzier. Which is why you're right not to go into too much
> detail.)
>
> I would also explicitly say that certain key account information, such
> as saved credit cards and bank account information, MUST NOT be shared
> as well, even though it's account information.
I’m not sure to understand that point. This API is about returning payment
instrument information (such as card information) to the merchant, or
whoever is providing services to the merchant.
>
> What, if anything, you want to say about collected information such as
> what items the consumer looked at and which ones she purchased, is a
> separate question, but it's also relevant here, and I don't think you
> should ignore it. I'd say it falls under "not without user consent."
>
> Finally, in any case, I think we need to be strong and consistent
> about saying that we never share information without user consent,
> hence my suggestion to change "should never share...without user
> consent," to "MUST NOT share...without user consent."
>
> Barry
--
Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs
Tel: +1 718 260 9447

Hi Amy, there's not much we can do if we were to catch a privacy or
security problem this close to CR. However, we can still aim to give it a
good go.
PING folks: does anyone want to volunteer to give LDN spec a review? best,
Joe
On Wed, Sep 28, 2016 at 11:10 AM, Amy G <amy@rhiaro.co.uk> wrote:
> Hi all,
>
> LDN (Linked Data Notifications) is aiming to enter Candidate
> Recommendation by the 11th of October, and we'd like to request a review
> for potential security or privacy issues. Linked Data Notifications is a
> protocol that describes how servers (receivers) can have messages pushed to
> them by applications (senders), as well as how other applications
> (consumers) may retrieve those messages. Any resource can advertise a
> receiving endpoint (Inbox) for the messages. Messages are expressed in RDF,
> and can contain any data.
>
> You can find the latest working draft here:
> https://www.w3.org/TR/ldn/
>
> Note that we have filled out the security and privacy questionnaire:
> *https://www.w3.org/TR/ldn/#security-and-privacy-review
> <https://www.w3.org/TR/ldn/#security-and-privacy-review>*
>
> Any and all feedback is welcome. Thank you!
>
> Amy & Sarven
>
--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871
Tech Prom, CDT's Annual Dinner, is April 20, 2017!
https://cdt.org/annual-dinner