inBloom — Data, Privacy, and the Conversations We Could Have Had
In the larger landscape of student privacy, inBloom is an interesting point on the timeline. The conversations that occurred about inBloom in 2013 and 2014 were revealing, although not always as intended. Many of the points people attempted to make about inBloom revealed as much about the proclivities of the speaker as they did about inBloom. inBloom was never as new as the hype stated, but was nowhere near as bad as its most vocal critics claimed. From the outset, though, inBloom was big — from its launch, to its vision, to its timeframe to achieve its goals, it was uncompromisingly ambitious. It was also a Rorschach for education policy — people saw what they saw, and the discussions unfolded accordingly.
Technology offerings inside and outside education fail on a regular basis, and most of these companies are forgotten quickly. inBloom has proven to be one of the odd exceptions, because unlike most projects, it unified many of the contentious strands running through the education world at the time. The paper that accompanies this post does a great job describing these disparate elements, so I won’t rehash them here. Rather, I will focus on some details from 2013–2014 that frequently fell between the cracks.
Conversations about inBloom are often not about inBloom
Most conversations about inBloom were only partially about inBloom. This paradox was made worse because inBloom was two distinct things: a software project, and a non-profit organization that supported the software project. This duality led to some confusing exchanges where it was unclear if a person was referring to the software, or the project, or both. Sometimes, this confusion existed both within the speaker and the audience.
This might seem like a minor detail, but imagine the following scenario (which played out more than once):
inBloom critic: “inBloom collects and distributes student data to vendors.”
inBloom supporter: “But inBloom can’t see the data that’s stored. The data are encrypted, and districts hold the keys.”
inBloom critic: “That’s ridiculous. inBloom is where the data are stored.”
And this conversation would continue indefinitely, with both sides talking past one another, because the critic was talking about inBloom the software, and the supporter was talking about inBloom the organization. While it might seem like a small point, this initial confusion made it difficult to discuss the merits of the initial claim, and made it near impossible to get to any kind of agreement or common understanding of the more detailed technical points.
Some of the conversations required technical and policy knowledge
In talking about inBloom, the discussion would often veer into areas that are dominated by nuance. A small list includes things like encryption (which itself includes details like levels of encryption, keys, encryption in transit, encryption at rest, etc), Family Educational Rights and Privacy Act (or FERPA), district control over student data as required under FERPA, and/or the difference between a data standard and the implementation of that standard — and to be clear, this is a very incomplete list. Each of these topics is a complicated conversation in and of itself.
To drill down on just one of these elements, inBloom implemented the Ed-Fi data standard, which leans heavily on the CEDS data standard. A data standard is exactly what the name implies: a common (or standard) way to share data. When multiple groups agree to use a data standard, the data collected by these groups can be shared and analyzed more easily.
However, every definition covered in a data standard does not need to be used in a specific implementation. The CEDS data standard has over 400 individual elements, but every implementation of the data standard doesn’t necessarily require every element. If we use the metaphor of a menu (which is poetically accurate, if not fully technically accurate), the data standard is the full menu, and what we order is the implementation.
When critics of inBloom (the software) said that inBloom collected 400 pieces of information on learners, a more accurate statement would have been that “the data standard implemented by inBloom contains 400 data elements” — but while that is accurate, it’s not particularly exciting. To make this even less exciting, a quick look at the data required for Federal accountability reporting shows why the CEDS standard supports 400 different data definitions: schools need to collect a broad range of information to support both state and federal accountability measures.
This is one of many examples where the details matter, but the details are both complicated and boring. Sound bites were easier, and the quality and accuracy of the overall conversations suffered as a result.
What does “new” mean?
inBloom branded itself as something new, and while this makes sense from a marketing place centered in the tech world, it was less than helpful in the policy space inside the education world. Student data collection — and student data concerns — predate inBloom. Starting in 2005, over 47 states received federal funding to rework their longitudinal datastores. The goals of these datastores were codified into law by the Bush administration and extended by the Obama administration as part of the America COMPETES act.
Bad practice with student data became mainstream during the Web 2.0 boom in the mid-aughts when countless companies launched “free” services, and educators signed up for them with little or no thought to the consequences. A significant number of these companies didn’t even have privacy policies, and when these companies went bankrupt, the data that had been given to these companies was never heard from again. These habits — a “free” service paired with a complete lack of critical thought regarding privacy — shaped how industry viewed the education space, and these bad habits have yet to be fully exorcised.
Not Every Benefit Is Exciting
On a very practical level, inBloom (the software) offered an opportunity for districts to just handle data more efficiently. This isn’t exciting, but excellence in education often consists of a large number of unexciting things done well. One clear benefit that comes from better data use is scheduling — better data systems allow for more students to get the classes they want. There are myriad inefficiencies that exist in the data systems used within school districts, and many of these barriers are more prevalent in poorer and larger districts, where good resources are harder to come by and more costly to maintain. inBloom could have addressed some of these needs, and raised the bar for districts that are currently under resourced and/or are paying for systems that don’t fully meet their needs.
However, these basic benefits were often lost in the more “exciting” conversations about tech integration, or buried under the more contentious conversations about student data privacy. While tech integration and student privacy are both incredibly important, so are reliable schedules and other core services.
Other vendors were happy to see inBloom fail
Because inBloom (the software) had the potential to unify and streamline services offered by other vendors, many vendors were directly or indirectly threatened by inBloom. While many of these vendors remained silent, others commented quietly (or not so quietly) on the demise of inBloom. While the “safest” stance for vendors was silence on inBloom (as many vendors were afraid of drawing attention to themselves), many vendors recognized — accurately — that inBloom posed a threat to their business model.
Ironically, one of the ways inBloom could have had a positive impact on the industry was their security practices. This was often lost in the conversations about privacy, but inBloom’s security practices for handling data were as good or better than many of the other offerings in the space. If more districts and educational agencies had the opportunity to see how inBloom was securing data, some of their competitors would have had some explaining to do.
Use the (open) source
One of the distinguishing features of inBloom (the software) was its status as an open source project. In theory, this means that anyone can install the software, add features, and redistribute their work. Practically speaking, of course, it’s more difficult than that (for example, modifying software of a complex project requires technical skill), but an open source project is more accessible than comparable proprietary projects. While inBloom released source code for the project, getting the full inBloom stack up and running is not an exercise for the faint of heart.
inBloom (the organization) could have used the status of inBloom (the software) as an open source project in two distinct ways:
- if it had prioritized a streamlined, accessible setup process, they could have increased adoption among districts, increased the community of developers using their service, and increased the community of developers building on their service. One of the stated goals of inBloom was to increase interoperability, and making an open source datastore more accessible to both districts and vendors would increase adoption, which leads to improvements in interoperability.
- inBloom (the organization) was thoroughly pilloried for the perception that they wanted to create an enormous collection of student data. If inBloom (the organization) had publicized an accessible open source option that a district could install without ever having to work with inBloom (the organization), it would have undercut these charges (This is yet another example where the confusion between inBloom the organization and inBloom the software didn’t help: because of inBloom’s status as an open source project, one could state — accurately — that a district could use inBloom without ever working with inBloom).
Conclusion
It feels odd to be writing about inBloom in 2017. Yesterday’s news shouldn’t stay relevant — except, of course, yesterday’s news remains relevant if we don’t convert the lessons of yesterday into tomorrow’s actions. Education technology can feel somewhere between forgetful to ahistorical at times, and we often lose opportunities or work harder than we need to because we don’t fully understand the contexts that have already been created.
Educational technology is a human endeavor, and we forget that at our peril. Most importantly, we can’t gloss over the “student” in student data, and we can’t fail to make the connection between student privacy and student agency. Underneath the outcry over inBloom, we had a large number of people who wanted to know how information collected from students would be used. Technical answers to these questions are not enough. Without grounding our use of data in immediate benefits to — and complete transparency with — learners, people won’t trust data systems. If we are serious about using technology to transform education, that needs to extend to how we view and support learner agency, and how we ensure that the benefits of technology are equitably distributed.
Points: This piece is part of a series of responses and reflections on the new report, The Legacy of inBloom, which draws on interviews and research to trace the closure of inBloom, and analyzes the factors that contributed to its demise. See also:
- inBloom’s collapse undermined personalized learning and data standards efforts by danah boyd
- inBloom: Analyzing the Past to Navigate the Future by Brenda K Leong and Amelia Vance
- The inBloom Legacy by Olga Garcia-Kaplan
- Rationalizing Those “Irrational” Fears of inBloom by Audrey Watters
