Page MenuHomeMiraheze

Create a written and clear CSP whitelist policy and checklist and review all current entries based on this
Closed, ResolvedPublic

Description

At the request of @Owen, we should create a written CSP policy and checklist that makes sure to take into account any possible security concerns with entries. I do mention that I myself did recommend this previously in T5092 but no progress was made.

Now that this request is being made by T&S/Owen as Director we should definitely look into this ASAP. Owen has recommended no new additions until a policy is in place.

Related Objects

Event Timeline

Reception123 created this task.
Reception123 created this object in space Restricted Space.
Reception123 created this object with visibility "Custom Policy".
Reception123 created this object with edit policy "Custom Policy".
Reception123 shifted this object from the Restricted Space space to the S1 Public space.May 17 2021, 15:55
Reception123 changed the visibility from "Custom Policy" to "Custom Policy".

@Southparkfan This is my first draft attempt, there's definitely some things that you'll need to change/improve but this is just an initial idea - P431

Shouldn't this task be made public?

Shouldn't this task be made public?

It was made private because the implication of this task was that there may be some existing CSP whitelists which are in fact not secure, so I thought until we finished the policy and reviewed everything it should be private, however if you feel that it could be public I wouldn't oppose that. Also, is the draft you proposed here P431#2921 ready to be sent to T&S for review?

Quick update on this task (due to absence for the remainder of this weekend): I have discussed my proposal with Owen B. My proposal will be a stopgap to prevent obviously unreasonable requests from being approved. Reducing GDPR non-compliance is non-trivial (blocking sites like YouTube have a huge impact on operations), reducing security risk to zero is impossible, but creating awareness and being in control is a better situation to be in.

@Reception123: unless you have objections, we can implement this policy and start reviewing the current list and resolving the backlog of requests.

[...]
It was made private because the implication of this task was that there may be some existing CSP whitelists which are in fact not secure, so I thought until we finished the policy and reviewed everything it should be private, however if you feel that it could be public I wouldn't oppose that.
[...]

The CSP list is public information, the new policy will be public and the reviews will be performed in public tasks as well (similar to the usual way of publishing reports, policies, procedures: information is public, unless [...])

Quick update on this task (due to absence for the remainder of this weekend): I have discussed my proposal with Owen B. My proposal will be a stopgap to prevent obviously unreasonable requests from being approved. Reducing GDPR non-compliance is non-trivial (blocking sites like YouTube have a huge impact on operations), reducing security risk to zero is impossible, but creating awareness and being in control is a better situation to be in.

@Reception123: unless you have objections, we can implement this policy and start reviewing the current list and resolving the backlog of requests.

[...]
It was made private because the implication of this task was that there may be some existing CSP whitelists which are in fact not secure, so I thought until we finished the policy and reviewed everything it should be private, however if you feel that it could be public I wouldn't oppose that.
[...]

The CSP list is public information, the new policy will be public and the reviews will be performed in public tasks as well (similar to the usual way of publishing reports, policies, procedures: information is public, unless [...])

Sorry for not seeing this, I have no objection to your proposed policy. We should publish it on Mete and then proceed to analyse all our current sites and see if they comply with the policy/checklist

@Void pinging you in case you have any thoughts / comments on this proposed policy

Is this now waiting on anything?

@Void Everyone seems to agree, so we can move forward with this.

@Void we should be able to make the task public now I think then at least.

@Owen the policy we are implementing defines:

Site Reliability Engineering and the privacy and security contact persons are consulted for determining consensus.

However, I don't believe we strictly have "privacy contact" or "security contact" persons as a clearly defined role. Unless we can do so, I would recommend that we instead change this to be specifically Trust and Safety, and an Engineering Manager (or DSRE, if DSRE is not also an EM).

Trust and Safety for sure - EM/DSRE is already included in SRE surely?

Ah, well, I was thinking of changing that specific line to something like:

Trust and Safety, and an Engineering Manager (or the Director of Site Reliability Engineering) will be consulted for determining consensus.

Which EM would be relevant?

Hmm, this is a bit of a gray area, given that CSP is not strictly a part of MediaWiki. However, I believe that, due to the close relationship between the CSP and MediaWiki security that this should primarily be the responsibility of the MediaWiki team. I think the process for handling a request should be like so:

  1. An SRE member (preferably on the MediaWiki team) performs the initial review, answering the questions required in the policy.
  2. A member of Trust and Safety reviews and verifies the information provided by SRE, giving their own opinion on whether the request should be approved or declined.
  3. An EM (again preferably MediaWiki) reviews the comments on the task, and makes the final call to either approve or decline the request.

At any point in this process other interested users may make their own comments as to whether or not the request should be approved or declined, which may impact the final decision. However, a recommendation to decline from any member of SRE or T&S should be considered to block approval, requiring additional discussion if the request is not to be outright declined.

@Void Do we have an update on the progress on the implementation of the policy? At the moment there are 6 tasks that are blocked on this (all new additions)

I just need to make a clarification update to the draft on staffwiki based on my messages above, and then I think it should be good to go. I'll draft that now (locally), so that it can hopefully be good to go sometime tonight after the database maintenance is done.

I've updated https://staff.miraheze.org/wiki/CSP_Whitelist_Policy and will go live with that if no other changes are necessary.

@Void I'd like to review this policy, but it's on staffwiki. Can we either (a) add Trust and Safety team members to staffwiki or (b) cross-post it to another private wiki? Thanks.

Arguably, we should consider the information contained on staffwiki and consider whether it's even necessary to retain the information that necessitates such a high level of restriction/classification.

Everything on staff wiki is there for a reason.

You having access to staffwiki is a call @Owen needs to make and comes from the board.

For the record re staffwiki:

R: “Directors resolve that; read and edit access to staff.miraheze.org is only granted to the members of Site Reliability Engineering and the Directors of Miraheze Limited, and must be removed upon leaving.” (Agreed: AZ, FT, RL, OB)

I've reviewed the final version of the draft on staffwiki and have no objections, it looks good to me.

Void removed Void as the assignee of this task.Fri, Aug 27, 17:45

Published: https://meta.miraheze.org/wiki/Tech:CSP_Whitelist_Policy

I don't personally have time to review current entries (or new ones) until next week. I don't know if we should create a new task for that, but I'm un-assigning for now so someone else can look at it.

I'd probably think it's best to have a new task for that yeah.

John assigned this task to Void.
In T7322#158692, @Void wrote:

Published: https://meta.miraheze.org/wiki/Tech:CSP_Whitelist_Policy

I don't personally have time to review current entries (or new ones) until next week. I don't know if we should create a new task for that, but I'm un-assigning for now so someone else can look at it.

I am satisfied that publishing the policy is sufficient to take ownership of this task. Reviewing entries should take place in separate tasks.

John changed the visibility from "Custom Policy" to "Public (No Login Required)".Sat, Aug 28, 18:52
John changed the edit policy from "Custom Policy" to "All Users".