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**

[wwolf]

Deactivated user I think this is a terrific proposal.  Security is everything.  Thanks!

[ldoughty]

What is the scope of the added protection?

Will this also block the JavaScript admins upload, or does this only apply to content created 'on the fly', so to speak, in various text fields that students and teachers have access to?

[abunag]

How I'm reading the post, it appears that it would only be a change to the Rich Content Editor (the entry boxes that most faculty and students see when editing or submitting) and not anything in the Admin panel.  However, I'd like confirmation of that.

[chunter]

This would apply to teacher and student submitted content through the rich content editor or uploaded to files.

[bneporadny]

Deactivated user,

This s a great write up and explanation, but I'm with  @ldoughty does this only apply to on the fly or doe it also apply to the JavaScript code the us Admin upload? Because if it also locks down the JavaScript code that is uploaded then it kind of defeats the security aspect you are putting into place.

[a_p_g_robinson]

I thought it was already stripped out of user content?

What about iframes with the code hosted elsewhere? (We use that quite a lot!)

[jblumberg]

As I read this, it is a much looser approach to security than what is currently in place (someone please correct me if I am wrong).  As an admin, we already have the ability to upload custom JS on the sub-account level, this would allow use of custom JS on individual pages.

I am mixed feelings about this, the current way of getting dynamic content into Canvas is either:

1. Embed using an iframe (you can do custom JS in that iFrame just fine currently but it will not allow access to the Canvas API, which makes this more secure but also more limited).  You can store the html, css and js in the files section of the course and then iframe in the html page... this works now.  
2. Add custom JS at the sub-account level and likely trigger it only on the courses/pages that it applies to.  We have some JS/CSS built this way that works as a "styleguide" and just requires the use of id and class tags on individual pages to enable those elements.

I personally feel like the JS may get people into trouble, but there are a number of script embeds that only support the script tag and not iframes and supporting these would be really handy.

Even more important would be for the editor to NOT strip whitespace and CSS tags.  There are many CSS tags that it strips out and the stripping of whitespace makes it very hard to read complicated html when you re-edit a page.

I would NOT want students to EVER be able to add JS to a page.  We have sophisticated students who could easily add JS that makes API calls as the user logged in.  This would be a big security no-no.

I think a better solution would be to formalize a way to store html/js/css in the files section and then iframe embed this content.  This would be great for institutions that are used to custom generating code and this would sandbox this code from being able to make API calls with the credentials of the logged in user making it much easier to trust.  If you did this, then enabling SFTP access to the file section of a course would be really awesome!

Josh

[jpruden]

During this security meeting, was there any talk about making the security on the iOS app match the website?

Website = log out after 15 minutes of no activity

iOS app = NEVER LOG OUT EVER EVEN IF PASSWORD IS CHANGED

I'd argue that this is a much larger issue than the security issues surrounding Javascript...

smiles,

Jamie

[Renee_Carney]

 @jpruden  thank you for your post, but it's not on topic.  I just looked for a feature idea related to this and didn't find one.  Have you submitted one?  Or have you submitted a support ticket if you believe this is a support issue?  Thanks.

[jpruden]

Hi Renee,

Thank you for confirming that security is off topic for Instructure.

Yes, I did submit this as a feature idea... and as a support ticket. No traction at all... and this confirms it.

smiles,

Jamie

[cesbrandt]

To be honest, I'm torn on this. JavaScript is a wonderful tool for websites, but it won't be compatible with the mobile app. Furthermore, a piece of protection that preventing JavaScript provides is that it lessens the risk of someone that doesn't know what they're doing to accidentally damage content.

So, here's my feedback/response to this proposed policy change:

1. Will this enable the loading of course-wide custom JavaScript files similar to account-wide custom JavaScript?
2. Will there be a separate section of the edit pages where JavaScript would be loaded?
   • i.e., No inline JavaScript in the HTML code, meaning SCRIPT tags are still stripped as well as attributes like ONBLUR, ONCLICK, etc.
3. Will there be permission controls to allow administrators to restrict which users are allowed to manipulate the JavaScript?
   • i.e., Our institute has a team dedicated to the development of our curriculum materials and shells. This team and administrators should be the only ones allowed to manipulate JavaScript at the course level.

I may have more feedback/responses depending on the answers to these questions.

[a_p_g_robinson]

It would be nice if the mobile app did conform more closely to the web app in its handling of js. There seems to be no obvious technical reason why the app can't rendered the pages as intended.

[ordwaye]

Just to clarify this does not effect js in account and sub account themes?  I am correct in understanding that?  If so it seems like a good choice.  What you can do via the api with js is a bit disconcerting. 

[william_ono]

Would it be possible to have a more technically detailed description of the proposed change? From what's written here, I can't tell whether you're talking about allowing instructors to place script tags in content areas, allowing students to add scripts to every page within a course, or anything in between.

[cmoore2]

We're a Higher Ed customer.  I'm in favor of this change, but how do we know how many of our users are using JS?  Is it possible for us to search all user-generated content in an account/sub-account/course for usages of JS?  Via the API?  Via our CSM?

[jblumberg]

I agree with Alex here.  Canvas now supports pushing custom JS to the mobile app so matching features seems to make sense. 

I still think that the use case needs to be considered:

1. Are we talking about an individual power teacher who wants to cut and paste some <script> tag code into their content?
2. Are we talking about a institution that produces high grades online content and has professional web developers who want more freedom?

In situation #2, I would prefer the ability to sftp (or git push) CSS/HTML/JS into a course's files and a workflow that iframe embedded this content would be easiest and most secure.  This is almost supported already, but doing so requires a  bit of manual work and trickery... 

I personally do not want the web developers working in our eLearning department even utilizing inline styles (or to do so rarely).  Defining CSS/JS at the account level allows us to enforce style consistency across our courses that is very valuable.  I personally even discourage our content developers from ever using the Canvas styleguide since we want to ensure that our content stays the same even if Instructure modifies this styleguide and it allows us to port content to a new LMS if ever necessary.

Josh

p.s.  I REALLY don't want to lose access to the current Global.js and Global.css.  We heavily use this to improve our user's experience.  This is hugely valuable to us institutionally.

[jblumberg]

You can do this via the API.  I have written similar reports.  There is nothing built in, you would need to find a decent programmer at your institution.

[s_]

So this sounds interesting. As part of our institutions LTI team, we are always trying to push the envelope, and sometimes that means using theme based custom js. 

I am against allowing all inline javascript, but being able to embed allowed external snippets could be good.  What would be AMAZING for us is having a domain whitelist for our scripts.  

Being able to do something like this in the RCE HTML editor would be awesome:

<script src="www.university.edu/snippets/myScript.js"></script>

and because it's coming from university.edu it won't be scrubbed away.

Keep up the great work, looking forward to seeing where this goes.

[cmoore2]

Would Instructure continue to maintain a JS whitelist?

[cesbrandt]

You've basically described what we do. Our development team is split into two groups: designers and developers. The designers work with the SMEs to design the course materials, then the developers format those materials into shells using standardized and uniform styling.

I agree that there are situations where customization is needed when working with complex materials, but these are the exception, not the norm.

Furthermore, the more "advanced" the design, the easier it is for it to be accidentally broken by faculty that don't know how to work "properly" in HTML. The RCE doesn't know how to handle styling classes and JavaScript, making what is displayed in it VERY different from some of the content we actually put out. Trying to change content via the RCE can easily break the page display, and we're only talking about working with some inline CSS at this point. Add in JavaScript? There goes browser.

I'd have to say that my biggest concern for this is the risk of recursive looping preventing the ability to access or edit the content (i.e., to fix the loop). Sure, the server may be fine, but the user trying to get in to fix it would have a locked up browser, instead.

[JACOBSEN_C]

Hi, we are dependant on uploading JavaScript and CSS through the account/sub-account "Themes" admin feature.  Please do not take that away.

[laurakgibbs]

As a user who has actively been promoting the use of popular javascript widgets (Twitter, Flickr, Pinterest) uploaded to the Files area, I have to say this sounds abysmal. Could you possibly consider whitelisting some of those javascript providers at a system level, instead of expecting every campus admin to whitelist them?

For myself, I am fortunate enough to be at a campus which provides real webspace for its faculty members through the Domain of One's Own hosting project through Reclaim Hosting (yay for Reclaim!)... but for the many people who have asked me for help with widgets who do not have their own webspace, I have promoted the use of the Files solution: upload the javascript <script> in a plain HTML file in the Files area, and then iframe that into the Page.

If I understand your proposal correctly, all the people who did that with Twitter widgets, for example, will suddenly find that their widget no longer works, and unless they have access to https webspace of their own, they will not be able to fix it.

I understand the need to assess real security risks, but the widgets provided by Twitter and hosted at Twitter are NOT security risks. The idea that Canvas users will be denied the use of those widgets is very disappointing. Shutting off Twitter javascripts that people have in their Files does NOT improve Canvas security, and asking all those users to petition their individual campus administrators is a very ineffective solution.

So, I hope VERY MUCH that Instructure will whitelist javascript providers like Twitter, Flickr and Pinterest whose javascripts are not posing any kind of a security risk when running in the Files area of Canvas.

[bdalton_sales]

Javascript and HTML files hosted in the Canvas files area can be executed currently.  They can then be i-framed into a Canvas page currently.  This can be done by any user.

[a_p_g_robinson]

Ah - yes, I saw that below - never occurred to me to try that! - we currently iframe out to an external site.

Presumably things hosted in the Canvas Files area will not run in to cross-domain restrictions and I can see the potential for harm there.

I wonder if there is the granularity in the system to restrict that just to teachers?

[stuart_ryan]

Howdy  @jpruden ,

I would be really curious, do you have a link to your original feature idea for that? I would love to jump over there to have a discussion on it and throw around some ideas with you on the topic (as I have some thoughts I would love to contribute).

I will try to keep this discussion on-topic, however if you can provide a link to your original feature idea, I would love to jump in and discuss it with you there.

The great thing about the community is that we can do exactly this, share ideas, have a good discussion, and raise our ideas and concerns. When there is something that we feel truly passionate about, we can each act to champion that idea within the community (such as my personal favourite example that I logged, championed, and was implemented: https://community.canvaslms.com/ideas/6521-remove-colour-overlay-from-course-cards-that-have-an-imag...).

By advocating and championing your ideas, engaging with the community, and discussing your thoughts, concerns, and filling a feature idea out with supporting evidence (such as standards, best-practices and so on), we can help the product managers to understand the needs and priorities of the community.

This will also help your Customer Success Manager work to champion for your needs as well. The additional visibility the community gives over an idea, and seeing how widely this is supported by the community, all represents input into the product roadmap and development process Instructure undertakes.

Would love to discuss your concern over the iOS app further, I will await to get the link from you, alternatively, if you need to log a new feature idea for this, to help you out, I have prepared the following you could use as a new feature idea:

Title: Provide ability for iOS App to Log Out

Body: 

When someone logs into Canvas on the web, they are logged out after a pre-configured time limit. However, the same can not be said for the iOS app which currently stays permanently logged in.

What currently happens:

The iOS App remains logged in, even when the user's password is changed.

What I would like to happen:

<to be completed>

Business case/justification:

This section is great to fill out with the business needs, any relevant policies you could refer to and helps to provide the justification for the needed feature.

Hope that helps!

Stuart

[ProfessorBeyrer]

Allowing a client to maintain its own whitelist of JavaScript is a great idea. Each client could decide how much custom scripting it wants to allow and who among its users could contribute to the script. 

[ProfessorBeyrer]

Ooh, I'm so glad you contributed to this comment stream, laurakgibbs. If I didn't find you here I was going to share this with you. You are an inspiration for the use of other things inside Canvas and I am so glad your informed opinion is part of this discussion. The creative placement of scripts inside plain-text files is a great way to do things this way. I hope that the Instructure development team can spend their effort protecting Canvas code from all bad scripts instead of taking an understandable-but-drastic step that risks diminishing the scope for user innovation.

[laurakgibbs]

The fact that this discussion is happening is indeed such a strong and hopeful thing about Canvas,  @ProfessorBeyrer ‌! I have bookmarked this page to come back and check in over the coming days because I know I will learn a lot from the discussion too. 🙂

[natalie_norton1]

Would it be possible to get more info on what the definition of  “User generated JavaScript”, i.e. what level the JavaScript execution block would be at?  We are not sure if this would include JavaScript used through the theme designer, or if the proposed block is at a lower level?

It would also be useful to have clarity on whether the following might be affected: 

- files embedded via iframes (eg Word, PowerPoint, Sway)

- Canvas guides embedded via iframe 

- embedded external websites (eg our uni website) which have page transitions using javascript

- web based assignments submitted via url

Completely understand the need for security measures, but just need to understand what the potential impact on our content might be. Thanks! 

[cms_hickss]

Hi @stuart_ryan , I think these are the two Ideas that  @jpruden  is referring to with regards to logging out of the mobile app: 

• https://community.canvaslms.com/ideas/6628 
• https://community.canvaslms.com/ideas/10074-log-off-all-devices 

[Stef_retired]

For everyone reading this segment of the conversation, the feature idea referenced is https://community.canvaslms.com/ideas/10074-log-off-all-devices?sr=inbox&ru=6265 (it was submitted in November 2017 and is open for voting at this writing), and I hope you will continue the discussion there!

[Stef_retired]

Thank you for those links, cms_hickss‌! For the others on this thread, please note that the first linked idea resides in https://community.canvaslms.com/groups/cold-storage?sr=search&searchId=242c5b97-88a9-4a31-819d-37e12...‌, so anyone who wants to review it will need to join that group.

[d18089h]

How would this policy affect SCORM modules uploaded into the files area and accessed through the Canvas SCORM LTI? Would javascript be allowed in those SCORM modules?

[snugent]

Yes! I have the same questions as Natalie. We need to know exactly what this will impact. On the admin side we only using javascript to customize the login page. It would be nice to be able to customize the login page from the theme editor so we didn't have to upload customized javascript files. 

[laurakgibbs]

Oh wow, I had not even thought about blocks at the level of external content embedded via iframes as  @natalie_norton1 ‌ mentions here.

If that is the case, I would basically have to stop using Canvas except for the Gradebook. That would be the end of everything for me. 

I had assumed, perhaps incorrectly, that javascripts running on external https servers and iframed into Canvas would continue to work. All my Canvas Widget Warehouse javascripts are examples of that javascript functionality in Canvas:

I create a javascript.

I upload the script to my own https webspace at lauragibbs.net

I create a plain HTML page, also at lauragibbs.net, which runs the script.

I then use iframe to display the contents of that externally hosted HTML page in Canvas.

For example:

Laura's Widget Warehouse: Homepage: Laura's Widget Warehouse 

I also rely on javascripts for the blog I use as my Canvas homepage; for example:

Daily Announcements: MLLL-3043 Myth-Folklore - Spring 2018 

(javascripts displaying the content in the sidebar)

If the javascript ban is going to apply to externally hosted webpages displayed via iframe in Canvas, that will be the END for me. All the work I have done in Canvas over the past year will be rendered useless, and I will not have any reason to use Canvas for anything except the Gradebook.

Hoping very much that this is NOT what is being proposed...

[bfowler]

Request continued Admin-upload JS permissions at account/sub-account theme level. Please confirm.

[James]

laurakgibbs,

A lack of clarity and details when announcing something often leads to hysteria. The original post was a bit confusing and didn't supply particulars, and so people are reading into it things that aren't there.

Every now and then I get something completely wrong and this was one of those times. Mea culpa. Thank you Deactivated user  for the clarification.

This is a proposed loosening of the use of JavaScript within Canvas, not a tightening up of it.

The first bullet point is saying that this is an opt-in feature and that if you don't opt in at the admin level then nothing is going to change from the way it's currently done. The second bullet point is say that Canvas is going to make sure that they let the admin know that this is dangerous and that they should really understand what they are about to do before they do it. This is not something to be done lightly or without serious thought. But, if you have given it thought and you really need this, then we're not going to stop you.

For most people, nothing will change.

As long as iframes are allowed, you are going to be able to run the JavaScript within those iframes. I don't know if it's technologically possible for Canvas to keep that from happening and it would be contrary to why they're using iframes in the first place so they wouldn't want to anyway. Canvas won't get rid of iframes because that's how external content is embedded in a safe way that doesn't interfere with their page. There's a chain of thought there: Canvas needs to allow iframes and iframes can run JavaScript so Canvas is still going to allow you to run JavaScript within your iframe. This is the same as it is now.

There were several places where Deactivated user  mentioned user-generated content. That does not include the custom JavaScript that admins add through themes. It means the content that end-user, the teachers, students, designers, etc., create. We're taking about the content that is placed into Canvas through the Rich Content Editor or in uploaded files.

It may mean the ability for instructors to view dynamic web pages that students upload as an assignment submission. It might make it easier to embed widgets on a page that don't allow iframing.

With many things that Canvas does, they provide a framework without telling us how we could use it or how they envision us using it. I get that -- they don't want to limit our creativity. But the lack of explanation often leaves people with more questions than it answers.

I have real concerns about this for security purposes, especially for including scripts on a page without iframing it, but our institution won't be turning on the ability for users to add dynamic content. Since it defaults to off, we won't need to do anything to enjoy the same level of security that we now have.

Update:

I misunderstood the original blog post and I misunderstood what Brett was trying to say when he wrote: 

Javascript and HTML files hosted in the Canvas files area can be executed currently. They can then be i-framed into a Canvas page currently. This can be done by any user.

I took that as what they were trying to make it easier for people to accomplish because it's such a pain to do this and you have to be careful how you construct links because the IDs change every time you upload new content. It didn't hit me that was the problem they were trying to solve.

I actually feel much better now that we're tightening up security

"Sorry" to all the people who found my incorrect interpretation helpful.

[laurakgibbs]

Thank you,  @James ‌!!! I was hoping you would chime in here; you were the one who first explained to me the difference between trying to use a <script> tag in a Canvas Page as opposed to using a <script> tag in an HTML file that I upload to Canvas Files.

Your explanation here sounds good, and confirms what I had hoped, which was that this is essentially something of importance for administrators, and that those of us instructors just doing our usual Canvas things will be able to carry on with business as usual. And business as usual is VERY good in my opinion, so I am glad about that. Thanks again!!!

[phanley]

Chris Hunter wrote:

This would apply to teacher and student submitted content through the rich content editor or uploaded to files.

Is the basic plan to parse/alter the content as it's added/uploaded (e.g. replacing script tags with p tags or something like that) or zipping the files and only serving them back as zip files)?

[bdalton_sales]

"This is a proposed loosening of the use of JavaScript within Canvas, not a tightening up of it."   This is actually incorrect.  The change only affects JS and HTML pages hosted in the canvas files area being presented in Canvas pages as this is currently a security issue.  Currently, there are no controls around their use and this presents a security issue.  The proposed feature flag will enable the ability to stop files within the Canvas domain from being executed.  There are lots of legitimate use for this but the idea is to give the institutions control over the decision to allow this or not.  Turning them off would solve the security issue but break many peoples existing content.

[James]

Thanks for the clarification, Deactivated user 

This is definitely not how it comes across in Chris' blog.

[James]

laurakgibbs

And every now and then I get something backwards. This would mean that you would not be able to host your JavaScript within Canvas unless your administrator enabled the looser security model.

[laurakgibbs]

If that is the case, I really worry about users, like me, who are not in a position to ask special favors of their sysadmins (I am just an adjunct).

Plus, it should not be up to instructors to petition their sysadmins about whether a Twitter widget is, or is not, a security risk. I cannot see any way in which it is a security risk, but I am not an expert. I hope Instructure's security experts will look into this and, as I said above, I hope there will be whitelisting at the Instructure level for javascript sources that are popular with instructors and which are not, in fact, security risks.

Otherwise, it is throwing the javascript baby out with the security bathwater.

[myerdon01]

Would this affect publisher content that teachers add to their courses? 

[laurakgibbs]

I would say that is a real problem: there are people I have been helping to use Twitter widgets who are indeed putting the Twitter <script> call in a Canvas File.

I don't do that myself (I use real web hosting), but I would feel terrible if the people I had helped with Twitter suddenly had their widgets break.

In no way does turning off javascripts from Twitter, Flickr, or Pinterest increase Canvas security, at least not as I understand it.

So I certainly hope there will be some kind of effort to whitelist reliable script providers, like Twitter.

For Instructure to do something that they know will break people's content would be very very VERY sad to see.

[James]

I disagree, but I'll admit that I don't use external widgets the way you do and might think differently if I did. Since I'm seeing it from my perspective, I tend to favor improving security at the risk of losing some functionality that was probably never intended in the first place.

We've been through the issue of Canvas breaking things before and sometimes its necessary to move forward. There was a big uproar over the deprecation of the jQuery UI magic last year, but ultimately we found ways to do what we needed to do and Canvas will be better for it. If we're being honest with ourselves, uploading files to Canvas and then linking to them was a hack. We know that the preferred solution is to embed them within an iframe on another site and that we were offering it as a way for people who didn't have that option.

[irishb]

Regarding this proposal about limiting JavaScript

- it doesn't sound like it will effect the Theme js we use

but can you confirm that, please?

Thanks so much for your time. : )

Best wishes,

Bridget Irish

Curricular Technology Support | Canvas Admin
The Evergreen State College

[laurakgibbs]

I agree that external hosting is the solution, but the way that people use Canvas Files reveals that there are many (MANY) institutions that do not provide hosting for their faculty.

I paid for my own hosting for about 20 years before my school (finally) offered real web hosting to faculty and students (as I mentioned above: three cheers for Reclaim Hosting, very much a by-educators-for-educators hosting service).

And no one has shown me why widgets from Twitter, Flickr, or Pinterest would constitute a security risk, which is why I think whitelisting is a viable solution. Yes, that is some trouble for Instructure... but it respects their users' content. I think users' content should be respected if at all possible. I hope this will be possible.

Heck, I'll host people's Twitter widgets if it comes to that............ sigh.

[James]

You don't understand why Twitter is dangerous? There are rumors going around that it and Facebook were used to potentially influence the 2016 election.

Joking aside ...

I didn't write this earlier because I'm trying to get caught up on school stuff and juggling too many things and having an off day, but as I now understand Brett's explanation, we're not talking about a link to Twitter, which might be easier to whitelist. We're talking about code that is included in a file that is uploaded that may call Twitter. That means that to whitelist anything, Canvas would have to whitelist entire chunks of code -- probably by creating a hash of the code. But then if the code varied by a single byte, it would be a different file with a different hash. With obfuscation, minimization, and versioning, there are too many possible code chunks to validate as the Twitter code. If there is any customization in the code, like a variable that contains an account ID, then every Twitter feed is different and whitelisting based off a hash becomes impossible. If a school is going to go through the hassle of creating that, then they might as well host things for their faculty and approve them in the same way that they have to approve global JavaScript or CSS.

The next approach is to scan the code for maliciousness and approve it if something is found. That's like writing a virus or spam scanner and we know how quickly those are defeated. That's part of why Canvas uses a whitelist for the HTML editor rather than a blacklist. Rather than excluding anything that isn't known to be bad, they only allow the things that are known to be good.

You could (but don't) execute the script on the server and let it compile to remove the attempts to obfuscate the code and evade detection and see what it does. But for how long -- it might wait 2 minutes before it decides to unleash its evil payload. And there are some things that wouldn't even run on a server that depend on being in a browser so the server scanning for maliciousness may not catch it because it never executed.

Even if a script appears is safe, if it loads information from another site, it may not be. Someone might hack the remote site, deliver malware to your script, and then use it to do bad things. You might even experience DNS cache poisoning and think you're loading something from a legitimate place and get something else. You might have a site whose widget is good one day but then they start delivering ads (inappropriate or not) the next.

I may sound defeatist and that no one should ever use JavaScript because it can never be safe. That's not the case. But students trust Canvas and what appears within it -- sometimes with unquestioning blind trust. If something pops up there, they're more likely to believe it's legit or that the teacher wanted them to do it because it's in the course. And if JavaScript could execute content and get around the CORS security measures because it was coming from the same domain then we're setting ourselves up for problems.

I appreciate that they're letting us know about it before they do it. When security concerns are found, they're often fixed fixed and the dependent systems patched before the public becomes aware of it. At least Canvas is giving us warning and letting us comment about the change.

[chunter]

Thanks everyone for the great discussion and feedback so far! I have updated the post with clarifications. Keep the feedback coming.

Chris