Show last authors
1 This document describes the terms of service for [[>>url:]].
3 The goal of the review facility is to perform a transparent and open review of the technologies concerned. It is an open facility, where unauthenticated users can contribute information without a priori verification. In principle, the entire history of content is kept to capture discussions and progressive insight. If people wish to remain anonymous, they should register with a pseudonym. Accounts can be removed, but content is irrevocably contributed and will remain disconnected from the contributor account.
5 In the live discussion channels - available at [[>>url:]] - any comments made by participants are made available under the //Chatham House// rule: the participant list nor the discussion itself will be made available outside of those that participated directly to a channel while it exists, but any comments made are allowed by anyone to be used without attribution in the final report.
7 There will be no backward secrecy during the online sessions: users can scroll back in the channels they are subscribed to, to retrieve earlier discussions. After the scheduled sessions, channels will be closed and removed.
9 Information that is delivered offline to the [[>>url:]] team - such as contact details of technical leads, responsible authorities and other involved parties - will not be made publicly available. These are to be used as part of coordinated disclosure.
11 = Responsible and coordinated disclosure =
13 During the activities performed by [[>>url:]], serious security shortcoming or even exploitable vulnerabilities might come up. In case an application has not been registered to be in active use anywhere, these vulnerabilities will be published (and therefore made public) in full through the [[>>url:]] website and communicated with the upstream developers. It is therefore imperative that any countries or regions about to deploy an application check the [[>>url:]] website if no exploitable issues are present. And subsequently notify [[>>url:]] of their intent to deploy, so that they may receive proper warning.
15 If it is known that a project is in active use, and a responsible or coordinated disclosure procedure is present for the project, [[>>url:]] will act according to the procedure established by the project where possible. If such a procedure is not present, [[>>url:]] will seek to contact the lead developers through an encrypted channel.
17 In case the vulnerability lies with an underlying open source component or dependency which is in wider use, that project will be approached first. In the presence of a responsible or coordinated disclosure procedure for that component, [[>>url:]] will act according to the procedure described earlier.
19 = Quick-scans on behalf of other Member States =
21 Through the European Commission, Member States may request [[>>url:]] for a quickscan of open source projects championed by other member states or other relevant initiatives. Such an external validation of the maturity and security of an available technical solution is a precursor to learning and actual reuse with some level of trustworthiness, which is the point of the open source nature of most efforts.
23 As part of the procedural preparation of such a quickscan, the European Commission will inform the member state(s) - or other organisations responsible for the initial development - of the pending review. As a courtesy, the European Commission may also decide to notify countries (also outside of Europe) which it knows have the application(s) in confirmed use. It is up to these countries, regions or organisations involved to approach the respective developers as well as operational people involved with the deployment. They are also responsible themselves for providing the right information to [[>>url:]] - such as secure communication paths to relevant contacts (e.g. a combination of email addresses and OpenPGP keys), contact details of a CERT or information about contingency measures. It is much appreciated if upstream developers collaborate with or even participate in the quickscan; this will help make the quickscan more effective.
25 When [[>>url:]] receives the contact details of the upstream developers, it will reach out to engage with the upstream project and if possible onboard them into the live discussion channels. In case of non-responsiveness of upstream (more than 72 hours and three contact attempts at least 8 working hours apart), [[>>url:]] may proceed with the quick scan without initial involvement of upstream - time is a critical aspect, and with the source code available there is nothing holding such a review back. Obviously, [[>>url:]] will follow any established responsible and coordinated disclosure procedures.
27 When the quickscan is scheduled to be performed, all parties involved will be notified at least 48 hours before the start. Since channels are open, anyone may register from that moment in order to participate.
29 = Proprietary technology and non-disclosure =
31 It is generally not recommended to use proprietary technologies or third party services for critical use cases, because they lack transparency and therefore trustworthiness cannot be fully established - unless formal proofs are available for any proprietary code itself, the solution is built reproducibly with a formally proven compiler and the origin and integrity of the application running on the actual servers can be strictly audited in real time by reliable third parties.
33 Also, by virtue of the non-technical constraints of an NDA, no fully open review procedure of such components is possible in case part of a solution is proprietary. It //may// be possible to review proprietary technology components, but this requires a dedicated procedure which needs to be discussed with the applying party. This may involve additional costs to be negotiated, depending on the size and complexity of the proprietary components involved and their role in the solution. [[>>url:]] will not accept to review anything without access to source code; copyright protections are not affected by sharing code.
35 A generic full NDA is not suitable, as the outcomes of the quickscan should be made public in the general interest; any security and privacy issues with a technology proposed in such highly vulnerable situations after all directly involve public and private safety.
37 [[>>url:]] will strive to publish any information it needs to publish in the public interest without disclosing sensitive information about the proprietary technology at hand itself - unless it cannot be avoided. To that end, [[>>url:]] will provide the proprietor of the affected solution with a draft version of the negative security outcomes and allow for 72 hours of response. Within that period the proprietor may point out parts of the report that it would like to see altered in such a way that the technical implications are clear without directly exposing information. [[>>url:]] will do its best to accommodate proper revisions, although no guarantees are given: if technical details are deemed necessary for the publication in the public interest, this outweights the interests of the technology provider. Should this be a problem to the technology provider, it is advised to avoid doing a quickscan through [[>>url:]].
XWiki 11.10.3