Review privacy implications #4
Comments
|
Thaddeus, please use this Checklist to check for Privacy Concerns. We may also want to after we did our own CheckList audit |
|
Thank you. I will make my response to this issue today. |
|
Two overall concerns here would be data ownership and confidentiality of user data. Because some semantics require user input, who would own that data? In the case of an HTML form the site owner typically owns the data as they are collecting information for a valid business use case and the user is made aware of this ownership through the site owners privacy and other policies. In the personalization use case, data is being used for the benefit of the user vs. a business use case of the site owner. The second concern is confidentiality. Based on the semantics, which as stored openly in the DOM, an untrusted third-party could potentially infer quite a lot of information about a user . |
|
Thaddeus wrote:
The second concern is confidentiality. Based on the semantics, which as
stored openly in the DOM, an untrusted third-party could potentially infer
quite a lot of information about a user .
Hi Thaddeus, can you expand on this please? Since, in this case, the
semantics openly "stored in the DOM" are author-generated for *ALL* users,
I am unsure how this poses a security or privacy risk (unlike, for example,
setting a site cookie, which even then is fairly benign even if they are
used for tracking purposes - however I see nothing in the draft spec
referencing cookies, and this type of user-tracking can be done today
without the Personalization draft).
I can as an author introduce all kinds of page semantics to a document, but
they are acted upon by the browser, and I'm not sure how else semantics in
the DOM are supposed to be perceived. Additionally, that author-supplied
DOM content is being served up to all users, whether or not they take
advantage of the additional semantic information provided by the author.
Take for example the following: <a href="about.html" aui-destination=
"about">Learn More</a>
Outside of completely
disambiguating the destination of the link, what additional information
here is introducing a security or privacy concern?
If I am missing something, can you also kindly provide a code snippet of
what you are concerned about? Thanks in advance.
JF
…On Sun, Apr 22, 2018 at 6:19 PM, Thaddeus Cambron ***@***.***> wrote:
Two overall concerns here would be data ownership and confidentiality of
user data. Because some semantics require user input, who would own that
data? In the case of an HTML form the site owner typically owns the data as
they are collecting information for a valid business use case and the user
is made aware of this ownership through the site owners privacy and other
policies. In the personalization use case, data is being used for the
benefit of the user vs. a business use case of the site owner. The second
concern is confidentiality. Based on the semantics, which as stored openly
in the DOM, an untrusted third-party could potentially infer quite a lot of
information about a user .
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c03VBl-wjsOocPRwReXUosZNn7I0ks5trRAbgaJpZM4OXRgb>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
In the current work yes, all semantics are author-generated, however, my understanding is that future modules would allow for broader customization by users. This would include user defined values, some of which may need to persist across pages or sessions. Is this not correct? Two of the links to the additional modules, "Adaptable Help and Support" and "Adaptable Tools", in the explainer document are broken. I will open an issue for these. |
|
Hi Thaddeus,
...include user defined values...
I am unclear on how this would work in practice. The key to understanding
the semantics is that they are already clearly defined at a "universal"
level, and each value will be pre-defined in advance so that other tools
can leverage the semantics on the page. That's why I believe we're working
on an abstracted taxonomy of terms and definitions now (yes?).
If a user 'defined' their own value, how would that work? (Also, where are
the additional modules, "Adaptable Help and Support" and "Adaptable Tools"
being linked from? I haven't even seen those modules, but I'm kind of late
to this party...)
JF
…On Mon, Apr 23, 2018 at 8:46 AM, Thaddeus Cambron ***@***.***> wrote:
In the current work yes, all semantics are author-generated, however, my
understanding is that future modules would allow for broader customization
by users. This would include user defined values, some of which may need to
persist across pages or sessions. Is this not correct? Two of the links to
the additional modules, "Adaptable Help and Support" and "Adaptable Tools",
in the explainer document are broken. I will open an issue for these.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c_gaPWvkqnbfduaWJUz5l0KZWe63ks5trds2gaJpZM4OXRgb>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
In some respects we are on the same page here. If a user 'defined' their own value, how would that work - I am not sure how that would work in practice either. I am under the impression that we would be allowing user input or customization in some of the modules, however I could be wrong. If this was the case there could be privacy concerns based on data classification of the user input and these would need to be reviewed, in terms of privacy, on a case-by-case basis. |
|
Privacy review is dependent on multiple factors including intended functionality, user data provided input (where applicable) and implementation. Messages and reminders would most likely require post authentication implementation. Although this may satisfy the need to protect data in transit there may be additional controls for data at rest. There may also be the need for non-technical controls in some cases. For example, opt-in language may be needed if a user shares or submits data, particularly if this data involves PII. I recommend maintaining a working privacy document which looks at the vocabulary on a case by case basis. |
|
Within the context of an incomplete taxonomy where the implementation method has not been determined, risk analysis should be as broad as potentially possible. In terms of user defined values, some of the suggestions in the current draft ask for user input, for example, one suggestion is depended on the contact information of an individual with whom the users is associated with as a property. The task here is not necessarily to demonstrate how the collection of user input would technically work, however, the task is to understand the potential risk and mitigation of collecting such information in the event the task force decides to explore these option further. |
|
Thank you for your comment. We have done the PING self-review. See #131 |
IndieUI: User Context was known to introduce privacy risks, which the specification called out. Personalization semantics takes a different approach but should be reviewed for any privacy implications, and address them in the spec.
The text was updated successfully, but these errors were encountered: