This document contains a template intended for organizations interested in protecting their users and applications from fraud, malware, and computer viruses, as well as interested in ensuring proper adherence to security and privacy considerations included in W3C Recommendations. It also help to support broad participation, testing, and audit from the security community to keep users safe and the web’s security model intact.
This document is a work in progress and may be changed at any time and without notice.
This March 2017 W3C Team Submission, is a proposal for security and privacy disclosure programs.
By publishing this document, Philippe Le Hegaret made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input for further work. Please consult the complete list of acknowledged W3C Team Submissions.
Many organizations making software and hardware products encourage their customers and users to provide feedback about bugs in their products. Especially important are bugs related to security which can be exploited to gain unauthorized access or privileges in their products. However, in some cases, customers and security researchers are reluctant to provide such information to vendors. This is particularly the case when their actions could be interpreted as circumventing measures that control access to copyrighted works. There are existing statutes prohibiting the circumvention of technological protection measures (TPMs), such as section 1201-1203 of the US DMCA, as well as laws in other territories (EUCD implementations in the EU; Bill C-11 in Canada; and other laws throughout Asia, Latin-America, Australia, NZ, etc).
The deployment and ubiquity of the Web reinforce the importance of maintaining strong security in the Web Platform. We rely on broad participation, testing, and audit to keep users safe and the web’s security model intact. As such, we should assure that such broad testing and audit continues to be possible, as it is necessary to keep both design and implementation quality high.
This document provides a template that vendors should adopt as best practices and would remove impediments to disclosing security and privacy bugs.
This section contains a template of typical coordinated disclosure program best practices that we recommend for adoption by organizations.
We (the organization):
- Agree not to bring suit against you, recommend law enforcement investigation, or cooperate with law enforcement investigation, if your disclosure meets the criteria listed in this section;
- Request that you give us a reasonable time (usually not to exceed 90 days) before publicly disclosing specific details of the vulnerability;
- 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;
- Agree to confirm, within a reasonable time, receipt of your disclosure (such as 3 days) and the validity of your disclosure (such as 10 days);
- 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.
Your organization may not impose any further conditions or restrictions on the disclosures but may include reasonable, customary terms relating to sending disclosures or interacting with vulnerability researchers such as the following: interest in specific disclosures, compensations, choice of law and dispute resolution. In addition, your organization may also express interest or disinterest in particular areas of review.
In addition, we also recommend that your organization keep the researcher informed of progress in fixing the issue.
Note: your organization must provide a reasonnable mean of communications for receiving disclosures and may also provide additional services to ensure encrypted communications.
Several individuals contributed to the document. The author especially thank: @@TODO.
The document was largely inspired by the Responsible Vulnerability Disclosure from Netflix and the Technical Architecture Group statement.