This project is comprised of three phases. The first phase changed the way we were serving up files in Canvas. The goal of this phase was twofold:
- Make it clear that the files are not owned by Instructure, but rather by other Canvas users.
- Limit how broadly user-granted permission was being applied. For example, if a user grants a file permission to access their webcam, permission will only be given for files in that course, and not for all files in that institution's instance of Canvas.
This first phase was deployed at the end of the year (view release notes here).
- This will be managed by a whitelist of acceptable domains. All JS that attempts to execute in violation of the whitelist will be blocked.
- The whitelist has a limit of 50 domains. We recommend using wildcard domains (*.domain).
- We will automatically add all necessary Instructure and Canvas domains, as well as any LTI tools that are configured on the account. These do not count toward the 50 domain limit.
- Root account admins determine if sub accounts can manage their own whitelists. If so, sub accounts will have the option of either inheriting the whitelist from the parent account or managing their own whitelist.
- Individual courses can be opted out of the CSP (for example, a computer science class that requires the ability to render student-submitted JS). Only account admins can opt a course out of the CSP.
This phase is currently in development. Our plan is to have this phase completed in the next couple of months.
The third phase adds a log to the UI which shows any requested domains that are in violation of the whitelist. This will allow admins to monitor activity and easily add new domains to the whitelist.
This phase is currently in the design stage and will begin development after phase 2 is released.
We're excited about the increased control this gives to institutions in managing the security for their instance of Canvas. As always, we'd love to hear from you. Let us know what you think in the comments!