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.
We will implement the following changes:
This proposal would haveno impact on:
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.