Self-Review Questionnaire: Security and Privacy

[wilaw]

Feedback has been to review this project through the lens provided by the Self-Review Questionnaire: Security and Privacy https://www.w3.org/TR/security-privacy-questionnaire/ established by the W3C. While we are not a W3C spec, it is a useful tool in evaluating our security and privacy posture. To this end I have attempted to answer the following questions for the CMCD project:

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
   1. This spec relays information from a media player to the CDN from which it is requesting media objects. The information concerns attributes of the object being requested (such as bitrate, duration, object type), the state of the player (buffer level, rebuffering status, startup mode) and the session (sessionID and contentID). The exposure is necessary because it allows the CDN to a) optimize delivery of the object b) apply intelligent timeouts and retry thresholds c) Analyze disparate requests as being a playback session and d) trigger immediate network health alerts for poor performance.
2. Is this specification exposing the minimum amount of information necessary to power the feature?
   1. Yes, we believe so. Over 35 data points were originally proposed, of which we have accepted 16. We have evaluated each on the litmus test of "is it necessary" and "what is the benefit"? For each key/value pair accepted, we have a clear value proposition.
3. How does this specification deal with personal information or personally-identifiable information or information derived thereof?
   1. All PII is explicitly prohibited. The spec indicates that "Personally Identifiable Information, such as IP address, cookie information and location data is intentionally not carried by the specification. "
4. How does this specification deal with sensitive information?
   1. None of the defined keys carry sensitive information, such as financial data, health information, location, or credentials.
5. Does this specification introduce new state for an origin that persists across browsing sessions?
   1. The "sessionID" key is the only data point that persists across requests. This ID is required to be a GUI and the UUID standard is suggested. It ties together the audio, video and manifest requests when a particular asset is played. It is never used twice, even if the same user plays another assets, or the same asset is repeatedly viewed by the end user. It cannot be used to identify the user, or the content and it does not persist across browsing sessions.
6. What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin?
   1. Of the reserved keys, the ones closest to configuration data would be requested maximum throughput and buffer length. These can conceivably be set differently players at levels that could be averaged over time and then used as part of a fingerprinting surface. To mitigate this, the spec requires these values to be rounded to the nearest 100mbps. This bucketing lowers the entropy associated with these parameters and thus reduces the fingerprinting surface. An explicit key called 'DeviceID' was proposed but then removed from the spec due to fingerprinting concerns.
7. Does this specification allow an origin access to sensors on a user’s device
   1. No it does not.
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.
   1. The spec exposes the following information to an origin. In manby cases, the origin already has access to this information if it were to parse the object being delivered
      1. Encoded bitrate - the bitrate of the media object being requested . Origin can discover by parsing.
      2. Buffer length - the buffer length of the media player
      3. Buffer starvation - a Boolean flag indicating if a rebuffer event has taken place since the last object was requested.
      4. Content ID - A unique string identifying the current content. This does not increase information leakage, as the object URL is visible to the receiver and itself a reference to the content. This ID simply ties together the thousands of separate objects which comprise a media asset.
      5. Object duration - the media time duration of the object. Origin can discover by parsing.
      6. Deadline - the minimum time for the CDN to deliver the object before the player rebuffers.
      7. Measured throughput - the throughput between client and server as measured by the client
      8. Next object request - the next object the client intends to request. This is used to request a prefetch by the CDN edge. Must be a relative path to the current request.
      9. Next range request - a range request associated with the next object request.
      10. Object type - whether the current file represents an audio, video, init, caption, or manifest file.
      11. Playback rate - current playback speed of the player
      12. Requested maximum throughput - a means for a player to voluntarily ask for delivery to be throttled.
      13. Streaming format - type of media presentation, such as HLS or DASH.
      14. Session ID - a randomly generated GUID, such as UUID, used to tie together object requests across a single piece of media.
      15. Stream type - live or VOD
      16. Startup - boolean true if the player is in start/seeking/recovery mode.
      17. CMCD version - version to accommodate future updates. Not sent if version == 1.
9. Does this specification enable new script execution/loading mechanisms?
   1. No.
10. Does this specification allow an origin to access other devices?
    1. No.
11. Does this specification allow an origin some measure of control over a user agent’s native UI?
    1. No, this is client to server communication, not server to client.
12. What temporary identifiers might this this specification create or expose to the web?
    1. The SessionID can be considered a temporary identifier. It is randomly generated, never repeats for the same user and is never reused for other sessions.
13. How does this specification distinguish between behavior in first-party and third-party contexts?
    1. The first party receiver of the data is the CDN serving the media objects. The CDN will log this information in its delivery log files. Log files are considered proprietary data of the customer whose content is being delivered. These log files are subject to privacy constraints, such as GDPR.
14. How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode?
    1. A media player may optionally send the CMCD data. The spec does not restrain whether the data should be sent when a browser-based player is in Private Browsing mode.
15. Does this specification have a "Security Considerations" and "Privacy Considerations" section?
    1. Yes, Section 5 deals with security and privacy concerns.
16. Does this specification allow downgrading default security characteristics?
17. This allows data to be attached to a HTTP request. If this request is made over http, then it is subject to man-in-the-middle attacks and any attacker would be able to view the information being sent to the server. Use of a HTTPS request would mitigate this attack.