This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
MediaKeyMessageEvent's destinationURL is currently a DOMString. There is no mention of validating it or that it must be a valid URL. I propose adding text that says any URLs provided by the CDM should be validated before adding them to the event. At a minimum, we should note that URLs may be validated and/or normalized before they reach the application. (Some browsers use URL types internally and these may reject invalid URLs and/or normalize URLs.) In any case, applications should not expect exact URL matches across browsers (unless we require normalization AND provide a reference for it). Another option is to use the URL type instead of DOMString. There are specs [1][2] for this, but I'm not sure of their timeline or implementation status and there is no "URL" in Web IDL. destinationURL is currently the only URL in the spec, but we would probably want to apply this to any URLs that might be referenced in the spec. [1] http://url.spec.whatwg.org/ [2] https://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
As clarified in the telecon, there are 3 levels of proposal: 1) Implementations *may* validate and/or normalize URLs; applications should not expect the string to be exactly the same across user agents. * This is required IMO since implementations will do this internally when representing URLs by objects. 2) Implementations *should* validate and/or normalize URLs. * It would be helpful to have a definition to point to. * Even if we don't have a definition and the outcome may differ in some corner cases, there may be value in all implementations filtering out commonly-recognized issues or invalid URLs. * If/when URL is defined, this could be the implied definition or the spec could be revised to point to it. 3) Use an explicit URL type in the definition (i.e. URL instead of DOMString). * This would implicitly validate and normalize the URL according to that definition. * This is perhaps the most desirable solution, but this may be a ways out as the URL spec is controversial.
This is mostly driven from security considerations. We don't want to pass around strings purporting to contain URLs without checking them. I propose that we explicitly allow UAs to cleanse (validate/normalize) URLs and that we add a note to the security considerations reminding implementers that these URLs should also be treated as untrusted. Assigning to David.
Implemented in https://dvcs.w3.org/hg/html-media/rev/9e5a46f75bd7.