- From: <bugzilla@jessica.w3.org>
- Date: Wed, 27 Aug 2014 23:22:26 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26683 Bug ID: 26683 Summary: Replace MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute Product: HTML WG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Encrypted Media Extensions Assignee: adrianba@microsoft.com Reporter: ddorwin@google.com QA Contact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-media@w3.org The application should control which URLs it uses and where it sends data. In general, it seems wrong for the user agent or - especially - the CDM to tell the application where to send a message. URLs present other problems as well: * "An application may choose not to send the message to this URL." * The URLs may be normalized. * URLs can be abused. * URLs may be used incorrectly (i.e. including privacy-sensitive information). * Applications should verify a URL before using it, but there is no way to enforce this and it seems likely many authors will fail to do so. * There are two paragraphs on URLs in the Security Considerations section. With the removal of support for parsing URLs from the initData (bug 25920), the remaining known use cases are a "heartbeat" URL and maybe initialization. These could be handled by the CDM telling the application the type of message it has provided and allowing the application to select, if it wishes, a different server. This is equivalent to the "heartbeat" scenario where the application author would configure the license server to provide a different URL to receive heartbeat messages, but it avoids the issues described above. Thus, I propose changing MediaKeyMessageEvent's definition to (enum types TBD) enum MessageType { "default", "heartbeat",... }; interface MediaKeyMessageEvent : Event { readonly attribute ArrayBuffer message; readonly attribute MessageType type; }; -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 27 August 2014 23:22:27 UTC