CnegPrivacyAndSecurityQuestionnaire
Introduction
Answers to the Self-Review Questionnaire: Security and Privacy for the Content Negotiation by Profile specification.
Answers to the questionnaire
4.1. How does the specification deal with personal information allowing to single out the user?
This specification does not directly handle any personal information. However, Since the web server receives information about all profiles prioritized, it could obtain information about the user that identifies them by the overlap of profiles or a profile plus their IP address. For example, if a user requests information with a profile used in a specific area of interest and also a company-specific profile, the identity of the person could become knowable (e.g., a person interested in model railroads who works for Adobe in San Francisco). Moreover, any health-specific profile information could hint at personal health information. Also, it's worth considering that marketers could look for specific profiles for targeted advertising.
4.2. How does this specification deal with high-value data?
This specification does not deal with high-value, but only with a user's preference for data according to a specified profile. Profile identifiers are not considered high-value data.
4.3. Might this specification introduce new state for an origin that persists across browsing sessions?
No. This specification does not introduce any state. The request-/response-interaction between an agent and an origin can be implemented statelessly.
4.4. Does this specification expose persistent, cross-origin state to the web?
No. This specification does not store or expose any state. The request-/response-interaction between an agent and an origin can be implemented statelessly.
4.5. Does this specification expose any other data to an origin that it doesn’t currently have access to?
Yes, profile preference information is exposed to the origin server.
4.6. Does this specification enable new script execution/loading mechanisms?
No. This specification describes a request-/response-pattern and scripting is not in the scope of this specification. The implementation of this pattern MAY be done using scripting but that is outside the scope of this specification.
4.7. Does this specification allow an origin access to a user’s location?
No, unless that kind of information is encoded in the profile URI. The design of profile URIs is outside the scope of this specification.
4.8. Does this specification allow an origin access to sensors on a user’s device?
No, the use of profile URIs as identifiers does not specify any access to sensors. Any use of profile URIs or interactions with services other than use for content negotiation is outside the scope of this specification.
4.9. Does this specification allow an origin access to aspects of a user’s local computing environment?
No. This specification describes a request-/response-pattern and any access to the user's local computing environment is not in the scope of this specification.
4.10. Does this specification allow an origin access to other devices?
No. This specification describes a request-/response-pattern and any access to other devices is not in the scope of this specification.
4.11. Does this specification allow an origin some measure of control over a user agent’s native UI?
No. This specification describes a protocol-level request-/response-pattern and any access to a user agent's UI is not in the scope of this specification.
4.12. Does this specification expose temporary identifiers to the web?
No. Profiles URIs should be considered persistent identifiers. No other identifiers are exposed through the use of this specification.
4.13. Does this specification distinguish between behavior in first-party and third-party contexts?
No. This specification does not distinguish between first party and third party contexts. The sharing of profile settings information with a third party (such as a company wishing to target advertising to those interested in a specific topic) would have potential privacy concerns, but the specification itself does not address this. Implementors of this specification are advised to disclose such use of profile information as they would the use of cookies or other user tracking techniques.
4.14. How does this specification work in the context of a user agent’s Private Browsing Modes mode?
The request-/response-pattern described by this specification should not behave differently during private browsing. The only difference could be that the use of profile URIs is prohibited in private browsing mode in which case profile negotiation would not work. That, however, does not tell an origin that the user is in privacy browsing mode.
4.15. Does this specification persist data to a user’s local device?
Yes. Although this specification defines a request-/response-interaction and does not specify any storage of data it can be assumed that certain User Agents, e. g. Web Browsers that support content negotiation by profile, will store profile preference settings. User Agents MAY store data from those interactions in local caches but that is outside the scope of this specification. If a user clears the User Agent's cache or local storage, the only side effect would be that the User Agent would need to re-fetch the information from the origin.
4.16. Does this specification have a "Security Considerations" and "Privacy Considerations" section?
Yes. Cf. https://w3c.github.io/dxwg/conneg-by-ap/#privacyConsiderations
4.17. Does this specification allow downgrading default security characteristics?
No. No part of this specification accesses security characteristics.
4.18. Does this specification allow the persistent monitoring of user behavior?
Not directly. The request-/response-interaction specified in this document only exposes information during that information exchange. However, a user with specific settings for profiles could be tracked by the headers created by those settings. The feasibility of that technique of monitoring depends on the uniqueness and the prevalence of profile settings.