The Editor's Draft should cite the latest published version as well.

This Group develop and execute a strategy for improving vulnerability coordination globally:
https://first.org/global/sigs/vulnerability-coordination
This seem highly relevant for the W3C guidelines.

It would be good to extend the scope of this document to include providers of alternate formats and/or accommodations for disabled people, where the original content producers have failed to do so.

'm going to point out that this "W3C Security Disclosures Best Practices" document has had, to my knowledge, no endorsement from W3C members on either side of the debate. Worse, it could be considered a fig-leaf to cover up W3C's inaction on DRM. At best, it's a well-meaning waste of time.

First, all companies of any reasonable size already have a security disclosure guidelines. Second, those that don't probably won't copy this draft document. Third, the entire process is misguided, ignoring the EFF covenant supported by adding more restraints to the security research community, rather than less as entailed by the EFF covenant. The likely cause of this procedural error by W3C. Therefore, I (formally, if possible) object to this entire "Security Disclosure" process.

Instead of continuing this bizarre "Security Disclosure" process, I propose this process be ended and W3C convene an ACTUAL NEUTRAL GROUP OF EXPERTS from the security research community, W3C membership, and with speciality in international law around copyright and security in order to solve this problem.

The goal of this group of experts should be to determine what the precise legal objections to the EFF covenant are, and if the concerns of the security research community and goals of the EFF covenant can be made part of the security disclosure policy of every member of the W3C involved in Encrypted Media Extensions and DRM. This may, and likely will, require substantial changes to the ALREADY EXISTING security disclosure process of existing W3C members like Mozilla, Google, and Microsoft.

Wendy Seltzer as she is the only person on W3C Team qualified to lead such a process for the benefit of both industry and users. As a lawyer who is knowledgeable about security/privacy and has dealt with the DMCA in court, she's best positioned to help out with this effort. Neither W3C staff member PLH, W3C PR, and even the Director have enough background in security and the law to reasonably make decisions around security disclosures and EME, but should pass the decision entirely over to a group of experts from the security and legal community while remaining neutral.

This process can address real concerns around jurisdictions, fair use, and sandboxing. This NEW process should be initiated and completed BEFORE W3C lets Encrypted Media Extensions be a recommendation. This was my initial understanding of objections against the EFF covenant from vendors before I left W3C over this DRM issue, i.e. that their lawyers could not accept EFF's covenant in its current form for some yet unclear reason but could imagine making changes to their current processes to bring their existing approved disclosure process in line with the EFF covenant's goal of not persecuting researchers under the DMCA. How after I left the W3C misinterpreted this feedback and started this security disclosure process is beyond me.

I am not going to claim I am qualified to decide on this issue either. However, the W3C should at least gather concerned experts and do a good faith effort to work out the concerns raised by many W3C members. This current effort is clearly not working and may not even be in good faith due the fact that's it's not even staffed with qualified people, including W3C lawyers Wendy and Rigo. The HME Working Group and this "Security Disclosure" process do not include any lawyers, either from members or the groups concerned around EME - and security research community, civil society, and even democratically elected leaders about how DRM could cause concrete damage and harm to users.

Leave a msg onmy email [email protected] because i dnt knw about this website wether it is safe to share or not having a link for your private key

Hi,
I am Febin, a security researcher and a bug hunter. I found a Server-Side Request Forgery (SSRF) bug which leads to internal port scanning. I don't know how to contact w3.org to report the bug!!

Kindly Contact me for more details and PoC : [email protected]

Thank You!!

Posted in the EME issues repo: w3c/encrypted-media#389
(Cross-posting here, since the comments are relevant to this document as well.)

Under section 2. W3C Security Disclosure and Privacy Best Practices, there is text that threatens legal action if the finder does not disclose the issue in a certain way.

Such a threat can be counterproductive. While this document seems to have been written with security researchers disclosing to an organization in mind, try to read the conditions listed as a
technology vendor disclosing an issue to this organization (usually through security advisories or alerts which also also security disclosures!):

Request that you give us a reasonable time (usually not to exceed 90 days) before publicly disclosing specific details of the vulnerability;

For example if this organization is using Apache Struts2, would it be taking legal
action against Apache for disclosing a critical vulnerability without giving them 90 days to apply patches?

Request to be provided an appropriate level of detail on the vulnerability to allow us to identify and reproduce the issue. Detail should include target URLs, request/response pairs, screenshots, and/or other relevant information;

Most technology vendors provide enough details to identify issues in their advisories, but do not share reproducers or exploits. If the organization is using a Name-brand Webserver, would it be taking legal action against that Name-brand vendor for not disclosing exploits such as request/response pairs that trigger a vulnerability?

Request that your vulnerability research not create service disruption (e.g. DoS), privacy issues (i.e. accessing a customer’s data), or data destruction, within a reasonable effort.

This is perhaps the hardest to guarantee for any disclosure either for a finder or a tech vendor disclosing thru advisories. As we have seen with Mirai, vulnerabilities and their disclosures in one product (IP cams) can have an impact on something entirely different (Dyn).

Would an organization expecting finders and researchers to adhere to certain rules follow the same rules when it has to disclose vulnerabilities to its customers or users or other organizations?

IMHO:

1. get rid of the legal threat for incoming security disclosures.
2. include a policy template for outgoing security disclosures.