Proposal for New Security Policy

[chunter]

Canvas makes teaching and learning easier by being open and adaptable. Openness is also a core value at Instructure. When we learn about potential security concerns, we want to keep you aware of what Instructure is doing to keep you safe.

Most content on the Internet uses powerful front-end code to render objects on web pages, such as videos, files, and interactive content referred to generically as dynamic content. We have allowed teachers to implement this functionality in Canvas to create engaging digital learning experiences, primarily through the Rich Content Editor. Many courses served on Canvas teach students how to create this type of content so we have also allowed Canvas to render some front-end code created by students as part of the learning process.

We’ve always been aware that allowing Canvas to render user-created code comes with a risk, and we’ve actively managed a code whitelist to help moderate supported content. However, the world is always changing so we regularly revisit this approach to ensure the guard rails we have put in place are appropriate for the level of risk. The goal is to provide access to powerful education technologies in a safe and effective way.

Our Product, Engineering, and Security teams met recently and discussed risks and user needs related to rendering user-generated dynamic content in Canvas. Our conclusion is that it’s time to make adjustments to our approach for allowing this content—specifically JavaScript.

We will implement the following changes:

• By default, if you upload an html file to the "Files" section in Canvas, we will not allow any javascript in that file to be run
• If desired, Canvas Admins can allow the use of JavaScript by enabling a feature option at the account, sub-account, or course level. This feature option allows admins to manage the use of dynamic content for their institution in a granular way. When enabling the use of JavaScript, Canvas will display a warning with the associated risks and require the admin to verify the feature option change.

This proposal would have no impact on:

1) JavaScript uploaded by admins to the Theme Editor.

2) IFrames embedded into a Canvas page that call an external source (for example, Twitter tweets or YouTube videos).

3) Our current practice to not allow inline scripting within the rich content editor.

We believe this approach will allow Canvas administrators to balance security- and privacy-related risk that meets the needs of their specific institution. Our preferred approach is to make this change as part of our standard deployment process—first to beta where it can be evaluated by admins, and then to production.

We welcome any feedback you may have about this upcoming functionality adjustment. Please share your thoughts by Sunday, February 11, so it can be considered as part of our plan.

**Now closed for feedback**