Follow Up Thoughts On inBloom Panel at Privacy Academy and CSA Congress 2014
9 min read
A few weeks back I was part of a panel discussion on lessons learned from inBloom with Virginia Bartlett (who was CPO for inBloom) and Omer Tene.
Jedidiah Bracy has a writeup on the session that is pretty solid; this piece adds in some details and expands on some thoughts that might have fallen through the cracks during the panel. While the conversation covered a lot of ground, we only had an hour, which is barely enough time to scratch the surface.
Here are some of the details that were touched on in the conversation, with some additional comments. This list is by no means complete, but these are some of the thoughts I've been coming back to since the panel.
inBloom Was A New Vendor In A Well Established Niche
A short list of other companies in the space include eScholar, Pearson SchoolNet, Infinite Campus, Agilex, and Clever. Many of these companies - with Clever being the one that is generating both the most buzz and the least critical scrutiny - support sharing data with other vendors, under a range of terms of service and privacy policies. Any of these vendors have almost certainly moved more data in the last month than inBloom ever did, under terms that are at best opaque.
All states have (and have had, for over a decade in most cases) detailed requirements around data collection. The Federal government has detailed requirements for states as well.
Much of the data collected at the state level is driven by the need for federal accountability reporting. Increasingly, though, vendors are looking to access student data to power various applications. The privacy concerns with both data collection by government for accountability reporting, and data collection by vendors to support learning applications, are longstanding, and predate inBloom. Additionally, these concerns continue to exist after inBloom's demise.
The Role (and Potential) of an Open Source Option
In this current landscape, with a small number of players at the district, regional, state, and federal level, data storage and collection is a zero sum game. All of the major options are vendor driven.
inBloom had an open source option. The code was freely available on Github. In practical terms, this meant that a district, regional provider, or state could access the code and run the software wherever they wanted, without ever interacting with any external vendors.
inBloom the organization did a poor job managing the open source component of the project. If they had prioritized and publicized that an open source version - that could be freely installed, and privately managed - was a central part of their vision, they could have avoided the charge and perception that they wanted to be central to the flow of student data.
More importantly, if they had been more active documenting and visibly supporting a freely available open source option, it would have given districts a real alternative to high priced, vendor-supplied alternatives.
Errata/Clarifications
In Jedidiah Bracy's writeup there are a couple minor points I want to clarify.
Gates, Murdoch, and Klein
In the panel, I talked about how perception of inBloom suffered - initially in New York, and eventually nationwide - due to connections between Rupert Murdoch, Joel Klein, and Bill Gates. Joel Klein was an unpopular and polarizing NYC Schools Chancellor who was hired by Rupert Murdoch. Some of the development work for inBloom was done by Wireless Generation, that rebranded as Amplify Learning. Given Joel Klein's polarizing presence, a Murdoch-owned subsidiary doing development work on a privacy related application in the wake of the phone hacking scandal, and the Gates foundation funding connection to the increasingly unpopular Common Core rollout, there was a little something here to make just about anyone unhappy.
inBloom Was Not Too Transparent
They started down the road to transparency, and then stopped. The information they provided made sense to people in the space, but they failed to make the technical aspects of the project comprehensible to people who don't read data specs as part of their regular life. Following through on documentation would have helped mitigate this.
They also made the mistake of not providing any context or background about the rationale behind many of their choices. For example, inBloom implemented the EdFi data spec, and one of the things that inBloom actually did well was to make the EdFi spec accessible. But, they never talked about how the EdFi spec is highly similar to the CEDS spec, and how the CEDS spec relates to the SIF standard. As a result, people saw this incredibly long list of data points and attributed them to inBloom's creation, when the reality was that inBloom actually just documented pre-existing data specs in a way that made them more readable.
This is one of many examples where inBloom's silence and lack of engagement was a horrible miscue. inBloom was definitely not too transparent. If they had shown up and discussed - as just one of many examples - the difference between what is supported by a data spec and what is required to be used in a data spec - they could have increased their transparency and actually contributed to the larger privacy conversation.
On The Awkward And Humorous Position Of Being Labelled
Since I started writing on inBloom I have been labelled by many people in the discussions. Interestingly, people with a industry slant have told me that I am too biased against industry, where people with an anti-inBloom slant have criticized me for not being adequately strident about inBloom, and for repeating industry talking points.
And I listen and laugh, mostly, although I will admit it gets old, in both directions.
But I figured that it'd be fun to attempt to clarify, so here goes:
I'm pro-kid, pro-parent, pro-teacher, pro-school, pretty much in that order. I'm strongly pro-privacy, and believe that just about every step in the chain - including student and parent understanding of data collection, teacher understanding of data collection, school/district understanding of data collection, contracts with vendors around tech services, local and state level data collection practices, vendor terms of service and privacy policies, and state and federal laws around privacy - is inadequate, in different and sometimes contradictory ways. I view privacy through the lens of social justice. I'm not a huge fan of data collection and use with kids, as the hype has far outstripped the actual uses, and I see way too many VC funded companies starting services that grab more data than they need with inadequate concern for student privacy. At best, it's sloppy and at worst, it's predatory.
I'm also fine with being wrong - it happens multiple times a day - and accordingly, I'm always glad to listen to differing viewpoints. As a result, I've been able to talk with a range of people. And, just because I talk with a lot of people doesn't mean I agree with them - while I do my best to listen, I will also confess to having my opinions, and on occasion being pretty stubborn about them.
This context has informed my take on inBloom. I never saw them as more than a well funded new player in an already crowded field. And with that said, over the course of writing about inBloom, I was more than a little shocked at the binary view that appeared to be required in the conversation: you either despised inBloom and, by extension, everything Gates-funded, or you were a mouthpiece for The Man and wanted all children hooked up to full body sensors while they watched Khan Academy videos. I don't think I fit neatly into either of those spaces, although there has been no shortage of people telling me otherwise, in both directions.
inBloom, like many companies, did some things right and some things very, very wrong. The attempted rollout in New York state provides some amazing examples of how not to do state level rollouts, but if there is a need to parse out blame, the top-down approach of NYSED paired with the silence from inBloom about their actual role provide some good starting points.
In many ways, I see the popularity and growth of a company like Facebook as the flipside of the inBloom experience in NY. If Facebook had been a government project, it would have failed miserably.
But, more than anything else, I'd love to see EVERY company moving student data get comparable scrutiny to what inBloom received. Eliminating a single vendor from the field doesn't move us closer to addressing the underlying issues of policy, contracting, and practice within schools and districts.
But We're Still Not Talking About Learners
And, with all this conversation about privacy, we are still missing the point. Our current models of data collection, and discussions of data privacy, all position learners as observed objects rather than active, informed agents. Within the current frame, data collection, like education, is something that happens to a learner - as opposed to something that the learner drives, shapes, and informs. Our conversations about data privacy have the same flaws as some of our conversations about what learning should be.
The privacy landscape and the educational landscape would look very different if we incorporated learner (or parent) control as a requirement at the outset. If school-level data systems included means for learners to review, challenge, add to, modify, or delete elements of their learning trail, privacy looks different. If educational records took the shape of a learner-controlled portfolio - and any app used within a school needed to be accessible - FERPA rights take on actual meaning.
But these details are completely ignored in much of the privacy conversation. Privacy - or lack thereof - is something given to or taken from learners. In this context, any connection between learner data and actual learning is incidental.
If, however, we ground our discussions on privacy in the absolute and unquestioned need for immediate student and parent access, we shift the privacy conversation. We also gain a clearer understanding of the actual point of learning.
