I’m sure i>Clicker won’t be particularly happy with this post, that’s ok, because I’m not happy with them. The one thing as an LMS administrator that you should feel very, very sanctimonious about is sharing data. We have an internal policy that we’ll never share student numbers. I also think that we shouldn’t share usernames, however some folks feel that’s ok. I guess it depends on your username convention. First dot last as a convention is great, except in these cases when you’re trying to maintain privacy. Now, if you’re making a single sign on connection through LTI, you can have the originating LMS username obfuscated, which essentially boils down to a paired database table that has two usernames in it – the one handed off to the third party via LTI, and the one in the LMS. Typically, I’m a little bristly about this as well, because you become reliant on the system not changing how this is handled, and if there’s an HTTP call mixed in there, it still could be sniffed out while in transit… but that’s not what this post is about.
Since last year, I’ve been bugged by i>Clicker to do an integration to make sign-up with their service seamless for students. There has been some requests for integration between i>Clicker and the gradebook in D2L from some of the more heavy users. The first request, I’ve always put off because, frankly, I don’t do anything a private enterprise wants me to do, they aren’t my boss, nor are they a member of my community. They serve one purpose, and that’s collecting money. The second, however, does benefit a select user group on campus. We were thinking about this since last year’s summer of integration, and April had a couple minutes free (more on that in forthcoming blog posts), so we scheduled some time to finally make it happen.
We schedule a call, to walk us through the integration and see if there’s anything that we have questions about. I don’t need anyone to walk me through an integration, but I often like to raise privacy, data collection policies, and other awkward questions to the poor sucker who’s on the end of the other line. Typically they are ill informed. I didn’t even get to the awkward stage, as a request was made that was frankly shocking. I was asked to turn on passing the Org Defined ID – or our student number – to facilitate the connection. Not just at the tool level, but at the configuration for the Tool Information. See below:
Now if I understand this panel correctly, it not only changes the configuration settings for the tool in question, but for all the tools. ALL the tools. So not only i>Clicker, but anything else you have connected through using the External Learning Tools administration panel. I asked our technical account manager about changing it, and he basically said, “yeah, that’s not good.”
So in the middle of this exchange where I explain how we don’t pass the student number under any circumstances, the i>Clicker representative seemed to be a little miffed about my protests. He wasn’t particularly nasty about it, but certainly didn’t seem to understand why this was an issue at all. Looking at i>Clicker’s website, students are asked for their ID. It’s different asking a student to give them their ID (consent) and setting up access to everyone’s ID (no consent).
What makes me wonder is, how many other institutions even give this a thought? Surely we can’t be the first person to balk at the idea of handing over student data like this? Or maybe we are being too paranoid? I mean, I guess there’s people who have faith in the third-party vendors, but I’d prefer having a license, stating exactly what they are doing with data, how they’re using it, how long it’s retained and an agreement signed between the two parties. That way if the external party violates the agreement, the institution can hold them liable for the data breech – something a little stiffer than “oops”.