PING Self Review - Module 1 Adaptable content

[clapierre]

PING Questionnaire for Personalization Semantics Content Module 1.0

The answers below often reference potential to expose information about a user based on the settings enabled to modify the content in order to personalize it to meet the users needs. In addition to the information contained in this spec, there are other other technologies it builds upon which are not covered here, including JSON-LD, HTML, CSS, HTTP, and HTTPS.

Questions to Consider
2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

Semantic information about form controls, buttons, sections of text, and other user interface elements are embedded into the webpage either at the time of authoring or done when the webpage is requested.

We envision this semantic information could be used by either:

A) a user agent that the end user has chosen to trust and that user agent will modify the data presented to the user to suite their needs, this is all done at the client side and no information is sent back to the server so no personal preference information will be expose except to the trusted 3rd party user agent making the personalization changes that the user requested.

B) a proxy server that the user will have set up an account with that would serve as an intermediary that would retrieve the information and personalize it to suite their clients needs and then send the user the personalized view of the web page requested. The personalization preferences information will need to be shared between the user and the proxy server but this is outside the scope of our specification.

2.2. Is this specification exposing the minimum amount of information necessary to power the feature?

Since the same semantic information will be sent to all users and it will be acted upon by either the local user agent or proxy server there is no exposing of information.

2.3. How does this specification deal with personal information or personally-identifiable information or information derived thereof?

Personal preferences the user requires on how a webpage is presented to them will be something that the third party user agent or proxy server acting upon our semantic information will need to deal with on protecting PI and PII information. Our specification does not expose any of this information.

2.4. How does this specification deal with sensitive information?

This specification does not address how sensitive information should be handled. As a data format, no API is proposed to expose data to the web and therefore no mechanism is proposed to protect such distribution.

2.5. Does this specification introduce new state for an origin that persists across browsing sessions?

This specification does not directly allow browsers to persist state across sessions. While downloaded content could contain state about a user, no mechanism is provided by the specification for a website to access that downloaded content.

2.6. What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin?

This specification does not expose any data to an origin. But, see 2.8, below.

2.7. Does this specification allow an origin access to sensors on a user’s device

No.

2.8. What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.

This specification does not expose any additional information to an origin. Note that it may reference other documents (for example, HTML) that could expose data. Since this specification does not alter the processing model for those other formats, it does not introduce any new data exposure.

2.9. Does this specification enable new script execution/loading mechanisms?

This specification does not expose any additional information to an origin. Note that it may reference other documents (for example, HTML in order to obtain the symbols required to personalize the page) that could expose data. Since this specification does not alter the processing model for those other formats, it does not introduce any new data exposure. Again this would be up to the third party user agent or proxy server to ensure those requests for additional symbols are secure.

2.10. Does this specification allow an origin to access other devices?

No.

2.11. Does this specification allow an origin some measure of control over a user agent’s native UI?

The specification itself does not provide a mechanism for overriding native UI. It is expected that implementations of this specification could allow such control, but such implementations would simply be web apps, which are not defined by this spec.

2.12. What temporary identifiers might this this specification create or expose to the web?

No temporary identifiers are created.

2.13. How does this specification distinguish between behavior in first-party and third-party contexts?

This specification does not change the processing model of the resources it references, therefore it does not distinguish between first and third parties. The user agent or proxy server acting upon the semantic markup may reference third party resources such as symbols and that user agent/proxy server would handle the privacy/security implications.

2.14. How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode?

Since this specification does not alter the UA processing model for documents, it has no impact on private mode.
2.15. Does this specification have a "Security Considerations" and "Privacy Considerations" section?

No, we will bring this up and reference the following:

Documenting the various concerns and potential abuses in "Security Considerations" and "Privacy Considerations" sections of a document is a good way to help implementers and web developers understand the risks that a feature presents, and to ensure that adequate mitigations are in place. Simply adding a section to your specification with yes/no responses to the questions in this document is insufficient.

If it seems like a feature does not have security or privacy impacts, then say so inline in the spec > > section for that feature:

There are no known security or privacy impacts of this feature.
Saying so explicitly in the specification serves several purposes:

Shows that a spec author/editor has explicitly considered security and privacy when designing a > feature.
Provides some sense of confidence that there might be no such impacts.
Challenges security and privacy minded individuals to think of and find even the potential for such > impacts.
Demonstrates the spec author/editor’s receptivity to feedback about such impacts.
Demonstrates a desire that the specification should not be introducing security and privacy issues
[RFC3552] provides general advice as to writing Security Consideration sections. Generally, there should be a clear description of the kinds of privacy risks the new specification introduces to for users of the web platform. Below is a set of considerations, informed by that RFC, for writing a privacy considerations section.

Authors must describe:

What privacy attacks have been considered?
What privacy attacks have been deemed out of scope (and why)?
What privacy mitigations have been implemented?
What privacy mitigations have considered and not implemented (and why)?
In addition, attacks considered must include:

Fingerprinting risk;
Unexpected exfiltration of data through abuse of sensors;
Unexpected usage of the specification / feature by third parties;
If the specification includes identifiers, the authors must document what rotation period was selected for the identifiers and why.
If the specification introduces new state to the user agent, the authors must document what guidance regarding clearing said storage was given and why.
There should be a clear description of the residual risk to the user after the privacy mitigations has been implemented.
The crucial aspect is to actually considering security and privacy. All new specifications must have security and privacy considerations sections to be considered for wide reviews. Interesting features added to the web platform generally often already had security and/or privacy impacts.

2.16. Does this specification allow downgrading default security characteristics?

We feel this does not apply, let us know if we misunderstood this. We don't facilitate nor prohibit this.

[lseeman]

note: John add or a proxy service we envision a subscription model - security concern is between user and service provider, we are just providing the tools to enable personalization

[lseeman]

JF: ****Since the same semantic information will be sent to all users and it will be acted upon the individual user's user-agent stack. There is no exposing of private information information.

[jumde]

so no personal preference information will be expose except to the trusted 3rd party user agent making the personalization changes that the user requested

@clapierre - Revealing personal preference information to third-party scripts exposes a fingerprinting surface. Are all personal preferences exposed to third parties or is it limited to the changes that the user is requesting from the third party?

[jumde]

2.15. Does this specification have a "Security Considerations" and "Privacy Considerations" section? No, we will bring this up and reference the following:

@clapierre - Is this still being discussed?

[lseeman]

@jumde the third party is the user agent. our specification does not include storing the user preferences. We are not exposing or collecting their preferences. We leave that to the user agent.
Do you feel we need a section or appendix on security considerations? Such as facilitating the inference that use may have a cognitive disability - because they use a site which is more adaptable by user agents.

[jumde]

@lseeman - that makes sense, thanks for your response. Have you had any conversations with browser vendors if they plan to store user preferences and expose them to the site?

Also, a security considerations section would be really helpful for the implementors.

[johnfoliot]

Hi Pranjal, I'm a tad concerned that you may not be understanding our goal here. We are looking to mint a new collection of attributes to store what is effectively micro-metadata (i.e. metadata at the component or element level) that 'standardizes' the conveyance of basic actions, destination, or similar page components for machines. For example, on the Google homepage, there is a button marked "I'm feeling lucky". For many if not most users, they understand the *implied* outcome of clicking on that button, but for some users with cognitive issues, they may not be able to make that leap, and attempt to interpret that button's purpose as doing something different (or simply not understanding at all what that button actually does). In that case, if we could unambiguously encode the 'real' purpose of that button into the semantics of the HTML, then helper applications could then 'bridge the gap' and simplify / modify / present "in different modalities" that "purpose" (i.e. "Personalize") to the specific user. As such, this is all about (and ONLY about) author supplied meta-data (author proposes), but at this time we are NOT going beyond establishing those condition(s), so that external entities can then use this metadata to do the actual transformation(s) or other personalizations. (NOTE: we have third-parties today who are using our draft spec for POC implementations now). You ask: "... if they [ browser vendors] plan to store user preferences and expose them to the site?" It's actually the other way around: the site will expose the (supplemental and standardized) in-page metadata to the user-agents, after which the user-agent will then 'do' something with that information (i.e. apply customizations) if the user requests that. As such, user preferences will stay stored on the individual user-agent, and used by that user-agent in interpreting the DOM (which is where our metadata will be 'exposed'). However there is no "bleed", as our specification isn't an API or creating functionality, it's just extending semantics down to the element level (and there, primarily fixed token terms as our taxonomies). It has more similarities with Microdata (with it's unfortunate and unwieldy data structure, which we considered but ultimately rejected as being too author-difficult) than anything else. (Here's another conceptual way of thinking of it... in responsive design, the CSS provides "information" for different breakpoints, but the author never knows which specific breakpoint is being used by an individual user. The author simply set some "conditions" that user-agents can then act, or not act upon, based on other variables - like screen size. Or, as another example, and again using CSS, it is similar to *prefers-reduced-motion <https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion> *where the author provides the 'alternative', or in our case additional semantic, but then leaves it for individual users and user-agents to do something with that information). Does that help? JF -- *John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[jumde]

This helps, thanks for the explanation @johnfoliot