Add course-level & account-level permissions for LTI installation

[stevenwilliams]

  This idea has been developed and deployed to Canvas

         

  Idea open for vote Wed. August 3, 2016 - Wed. November 2, 2016  Learn more about voting...

Currently, all users with editing access to a course site (via the course-level and account-level "Manage all other course content" permission) have the ability to install a third-party LTI tool within a course. This setting bundles together Modules, Collaborations, LTI, Home Page, Chat, Attendance into a single permission.

Unlike all the other content types included in this permission, which are all native to Canvas, LTI tools have the ability pass through a great deal of student data to a third-party site. This can create legal risks around FERPA and other laws related to student records and privacy.

Currently, some universities use Javascript in order to suppress the options to add an external app when a page is rendered within Canvas. However, this does not have any impact on a user's ability to add an LTI tool, and they can still do so via workarounds including importing a course archive that already has the tool enabled.

Adding granularity to this permission would allow institutions to better fulfill their obligations to protect the privacy of student data, and make decisions locally about who should have the ability to install tools that pass student information outside of Canvas.

  Comments from Instructure

For more information, please read through the Canvas Production Release Notes (2016-11-19)

[dsheryn]

It would be great if Brent could share his slides for the benefit of those of us who weren't able to participate originally 🙂  Thanks.

[brent_shaw]

Thank you for your kind words Steve and David.  You can find my slides at https://reach.ucf.edu/shaw/instructurecon2016/​

Even though I'm the guy that did the "FERPA and LTIs" talk about how much personally identifying information (PII) LTIs can send to 3rd party systems, I'm loath to block instructors from adding their own LTIs to individual courses.

A brief talk with a Canvas developer (who shall remain nameless because it was an informal conversation) who had a great idea - when a user clicks through an LTI, display the information being sent and perhaps allow the user to prevent selected data elements from being sent (ie an opt out of sorts).

It's important to understand that builders of LTIs can do everything they need to with the "Anonymous" setting (including grade pass back) that does not send what most schools would consider PII.  (I can't see anyone reasonably thinking the Canvas ID is PII.)

I've got to believe there are better solutions to issues surrounding FERPA and LTIs beyond just saying "NO!"  Preventing access to LTIs is the easy way out.

Cheers,

Brent

[stevenwilliams]

Thank you for sharing your slides,  @brent_shaw ​!

At InstructureCon 2015, I saw a demo of the LTI 2.0 spec that included an "Android-like" screen that automatically displayed when an instructor added an LTI tool to their course, showing the specific permissions and information that would be passed through to the tool (Android example: http://www.androidcentral.com/sites/androidcentral.com/files/articleimage/684/2012/02/permissions/gm...​). Since then, it sounds like work by Instructure and vendors on supporting the LTI 2.0 spec has slowed a bit, but I'm hopeful that the emergence of this standard will better support instructor understanding of the permissions required by any particular tool.

[chriscas]

I'll upvote almost any requests that have to do with adding more granular permissions to Canvas, including this one.  The LTI and FERPA session at InstructureCon was enlightening and has me thinking about a formal approval/vetting process for LTIs here (especially at an the account level).

[John_Lowe]

I plugged this idea in my recent blog post - The Need For Privacy: FERPA and Title IX .

[ronmarx]

Great idea! Instead of commenting on my own, I simply mirror what Chris Casey said about "adding more granular permissions to Canvas." In a K-12 district, this feature would be particularly useful in cases where a subject PLC, or individual teacher purchased an LTI solution. Very happy to UPvote this!

iRon_Mrx

[mary_speight]

Our university is piloting Canvas in the spring, so I'm very new to all of the permissions. We would also limit the LTIs for support reasons. Disabling "manage all other course content" seems to prevent faculty from adding LTIs, but what else does it restrict them from doing?

[stevenwilliams]

 @mary_speight ​, Canvas outlines course permissions in this document​ -- "Manage all other course content" has quite a few essential tasks bundled in with LTI tool management (including manage modules, edit syllabus, and access chat/attendance). More granularity in these permissions would be helpful for LTI tools among other use cases.

[mark_b_jones]

With the permissions as they are, it is my understanding that anyone who can edit course content can install an LTI.  And there are three ways (as i understand) FERPA data can be communicated to the LTI provider: via the LTI privacy configuration setting, the custom fields configuration setting, or by presenting the user web forms in iFrames that collect personal information and, to the user, appear to be part of Canvas.  My concern is that many LTIs are free, where we are not likely to have any contractual relationship, and that many who are tasked with developing course content will be unaware of or unconcerned with FERPA and the ramifications of specific LTI configuration settings.
So even if an LTI is being used in support of student instructional needs, that LTI can be configured such that more user data is communicated to the third party than is necessary, and, though I am not a FERPA expert, I doubt that the sharing of FERPA data, with parties without contractual agreements, would fall under an 'instructional needs' clause.

Adding granularity to permissions that govern editing of course content would allow us to limit who can install LTIs to those who have received training without completely preventing the development of course content for those who have not.

[tbunag]

Although saying, "No!" may be the easy way out, I think it is a beneficial and useful option.  I could imagine it also being useful in the early stages of training faculty on how to use LTIs properly.  Providing the option to limit addition of LTIs is a far cry from universally saying, "No!"  It simply allows institutions to monitor how and what information is shared with 3rd parties.

There's another aspect of this that hasn't been considered - accessibility.  Some LTIs have accessibility issues, and they could open up the institution to liability.