Four Things I Would Recommend for

2 min read is an open source voice assistant. It provides functionality that compares with Alexa, Google Home, Siri, etc, but with the potential to avoid the privacy issues of these proprietary systems. Because of the privacy advantages of using an open source system, Mycroft has an opportunity to distinguish itself in ways that would be meaningful, especially within educational settings.

If I was part of the team behind, these are four things I would recommend doing as soon as possible (and possibly this work is already in progress -- as I said, I'm not part of the team).

  1. Write a blog post (and/or update documentation) that describes exactly how data are used, paying particular attention to what stays on the device and what data (if any) need to be moved off the device.
  2. Develop curriculum for using in K12 STEAM classes, especially focusing on the Raspberry Pi and Linux versions.
  3. Build skills that focus on two areas: learning the technical details required to build skills for Mycroft devices; and a series of equity and social justice resources, perhaps in partnership with Facing History and/or Teaching Tolerance. As an added benefit, the process of building these skills could form the basis of the curriculum for point 2, above.
  4. Get foundation or grant funding to supply schools doing Mycroft development with Mycroft-compatible devices

Voice activated software can be done well without creating unnecessary privacy risks. Large tech companies have a spotty track record -- at best -- of creating consistent, transparent rules about how they protect and respect the privacy of the people using their systems. Many people -- even technologists -- aren't aware of the alternatives. That's both a risk and an opportunity for open source and open hardware initiatives like

Google, Lawsuits, and the Importance of Good Documentation

8 min read

This week, the Mississippi Attorney General sued Google, claiming that Google is mining student data. In this post, I'll share some general, personal thoughts, and some recommendations for Google.

To start, it's worth watching a statement from the press conference where the suit was announced - this video clip was shared by Anna Wolfe, a journalist who covered the event.

At 1:46 in the video, the AG describes the "tests" that were run. To be blunt, these tests don't sound like actual tests - it sounds more like browsing and looking at the screen. Unless the student account they were using was relatively new, had never done any searches on the topic being "tested," had never browsed while logged in to any non-Google site that had ad tracking, and all testing browsers had their cache, cookies, and browsing history cleared, there are a range of benign options that could explain behavior that looks like targeted ads. And that doesn't even take into account the difference between targeted ads based on past behavior, and content-based ads delivered because a page describes a specific subject.

Without additional detail from the Mississippi AG on how they tested for tracking, the current claims of tracking are less than persuasive.

G Suite Terms, and (a Lack of) Clarity

An area where Google can improve is highlighted in the suit: Google's terms, and the way Google describes how educational data are handled, are not easily accessible or comprehensible (all the necessary disclaimers apply: I am not a lawyer, this is not legal advice, etc, etc). This commentary is limited to transparency and clarity. With that said, Google could blunt a lot of the claims and criticisms they receive with better documentation. The people who are doing this work at Google are smart and talented - they should be allowed to describe the details of their work more effectively.

Google has built a "Trust" page for G Suite, formerly known as Google Apps for Education. The opening paragraphs of text on this page highlight the confusing complexity of Google's terms.

Opening text from Trust page

In this opening text, Google links to five different policies that govern use of Google products in education:

However, this list of five different legal documents leaves out five additional documents that potentially govern use of G Suite in Education:

Of these five additional documents, two (the Data Processing Amendment and the Model Contract Clauses) are optional. However, these ten documents are not listed together in a single, coherent list anywhere on the Google site that I have found. The trust page also links to this list of Google services that are not included in G Suite/Google Apps for Education, but that can be enabled within G Suite. The list includes over 40 individual services, which are all covered by different sets of terms.

Moving down the "Trust" page, we see several different words or phrases used to refer to the Education Terms: "contracts," "G Suite Agreement," and "agreements." These all link to the same document, but the different names for the same document make it more difficult to follow than it needs to be.

Some simple things Google could do on the "Trust" page:

  • list out all applicable terms and policies, with a simple description of what is covered;
  • list out the order of precedence among the different documents that govern G Suite use. If there is a contradiction between different any of these different documents, identify what document is authoritative. As just one example, the Data Processing Agreement and the G Suite Agreement define key terms like "affiliate" in slightly different ways;
  • highlight what documents are optional;
  • create a simple template for districts (or state departments of ed, or universities) to document the agreements governing a particular G Suite/Google Apps implementation;
  • standardize language used when referring to different policies;
  • define the differences between the Education-specific contracts and the Consumer contracts;
  • in each of their legal terms, create IDs that allow for linking directly to a section of a document.

While the above steps would be an improvement, creating standalone, education-specific terms that were fully independent of the consumer terms would add additional clarity. From a product development place, this legal review would force an internal review to ensure that legal terms and technical implementation were in sync. To be clear, this is an enormous undertaking, but if Google did this, it would add some much-needed clarity. Practically speaking, Google could use this step to generate some solid PR as well. The PR messaging on this practically writes itself: "Google has always prided itself on being a leader in security, data privacy, and transparency. As our products evolve and improve, we are always making sure that our agreemets evolve and improve as well."

G Suite and Advertising

Google has stated on multiple occasions that "There are no ads in the suite of G Suite core services." Here, it's worth noting that "core services" for education only includes Gmail, Google Calendar, Google Talk, Google Hangouts, Google Drive, Google Docs, Google Sheets, Google Slides, Google Forms, Google Sites, Google Contacts, and Google Vault. Other services - like Maps, Blogger, YouTube, History, and Custom Search - are not part of the core services, and are not covered under educational terms.

Ads text from Trust page

There are differences, however, between showing ads, targeting ads, and collecting data for use in profiles. Ads can be shown on the basis of the content of the page (ie, read an article about canoeing, see an ad for canoes), and this requires no information about the person reading the page.

Targeted ads use information collected from or about a user to target them, or their general demographic, with specific ads. However, while targeted ads are annoying and intrusive, they provide visual evidence that personal data is being collected and organized into a profile.

On their "Trust" page, as pictured above, Google states that "Google does not use any user personal information (or any information associated with a Google Account) to target ads."

In Google's Educational Terms, they state that they collect the following information from users of their educational services:

  • device information, such as the hardware model, operating system version, unique device identifiers, and mobile network information including phone number of the user;
  • log information, including details of how a user used our service, device event information, and the user's Internet protocol (IP) address;
  • location information, as determined by various technologies including IP address, GPS, and other sensors;

While it is great that Google states that they don't use information collected from educational users, Google also needs to provide a technical explanation that demonstrates how they ensure that IP addresses collected from students, unique IDs that are tied to student devices, and student phone numbers are explicitly excluded from advertising activity. Also, Google should clearly define what they mean when they say "advertising purposes", as this phrase is vague enough to take on many different meanings, often showing more about the opinions of the reader than the practice of Google.

This technical explanation should also include how the prohibitions against advertising based on data collected in Google Apps can square with this definition of advertising pulled from the optional Data Processing Agreement:

"'Advertising' means online advertisements displayed by Google to End Users, excluding any advertisements Customer expressly chooses to have Google or any Google Affiliate display in connection with the Services under a separate agreement (for example, Google AdSense advertisements implemented by Customer on a website created by Customer using the "Google Sites" functionality within the Services)."

There are many ways that all of these statements can be true simultaneously, but without a technically sound explanation of how this is accomplished, Google is essentially asking people to trust them with no demonstration of how this is possible.


Google has been working in the educational space for years, and they have put a lot of thought into their products. However, real questions still exist about how these products work, and about how data collected from kids in these products is handled. Google has created copious documentation, but - ironically - that is part of the problem, as the sheer volume of what they have created contains contradictions and repetitions with slight degrees of variance that impede understanding. Based on seeing both Google's terms evolve over the years and from seeing terms in multiple other products, these issues actually feel pretty normal. This doesn't mean that they don't need to be addressed, but I don't see malice in any of these shortcomings.

However, the concern is real, for Google and other EdTech companies: if your product supports learning today, it shouldn't support redlining and profiling tomorrow.

Civil Rights Complaint Filed Against Portland Public Schools

5 min read

UPDATE - July 6: According to Willamette Week, Paul Anthony met with Carole Smith on January 26, 2016, and documented the core findings that drove his civil rights complaint. He filed his complaint on May 26, 2016. Between January and May, the Portland Public School Board - of which Anthony is a member - reviewed the District-wide Boundary Review Advisory Committee (DBRAC) recommendations. On April 12th, Anthony is quoted in this DBRAC-related story talking about implementation plans moving forward for East side schools. As noted in this document about the goals of DBRAC, ensuring equitable access to resources is a key goal.

So, if I'm understanding this correctly, a school board member had evidence that, in his estimation, rose to the level of a civil rights complaint. He had this evidence in January, and was part of a review process that was designed, in part, to address these very needs. Yet, during the entire review and discussion process, the documentation was never shared. Why not? Why sit on data that documents the exact issue the district is trying to solve when you are part of a group of people providing guidance and input to this process?

If I am mistaken here, and the documentation used to drive the civil rights complaint was introduced during a public school board meeting, please share the link to the meeting video, and I'll watch the video and update this post accordingly. But, if this information was never shared publicly as part of the DBRAC review process, or as part of any budget review process, I'd love to know the rationale for keeping it private, rather than for sharing it publicly in the middle of a process where the information could have been put to good use. END UPDATE.


Paul Anthony, a Portland School Board member appears to have filed a federal complaint alleging racial discrimination. According to the Oregonian, the complaint was filed in late May.

The Oregonian story linked above has some quotes from the complaint (note - I have not read the complaint, save for the excerpts covered in the Oregonian story), including:

"Superintendent Smith permits her staff to discriminate on the basis of race, color and national origin in access to educational course offerings and programs," the complaint says. "PPS data proves that students of color cannot access courses tied to long term academic achievement. For example, they disproportionately are not offered access to foreign language, academic supports, and electives that white students access."

I'm glad to see this issue getting increased attention. It mirrors and amplifies what people with kids have been saying for years. It also mirrors trends we see with how parent fundraising amplifies and enshrines the inequitable distribution of resources. But no one has the appetite or will to take on inequities based on parent fundraising. We allow the Equity Fund to apply band-aids, when what we need is surgery.

The Civil Rights complaint also begs the question of why the school board didn't use its oversight of the redistricting process to address inequitable access to resources. True leadership would have used that opportunity.

And while this might be covered in the text of the complaint, it would be great to see the ongoing problems with racial bias in discipline within Portland Public Schools addressed. We should have school and classroom level data about the source of referrals and suspensions. Looking at this data will make a lot of people very uncomfortable, but in an ideal world, this would have full teacher's and prinicipal's union support within the context of ongoing professional development for their members. Suspensions, expulsions, and disciplinary referrals don't happen out of thin air - they represent choices by teachers, principals, counselors, and other school staff. But, for all the obvious reasons, taking the needed hard look at this issue would almost certainly face strong and determined resistance.

Quoting again from the Oregonian article:

(Paul Anthony) said after painstakingly seeking the data and arranging it in spreadsheets, he couldn't get the traction he wanted on the issues.

In the imediate aftermath of the ongoing issues around lead in our school's drinking water, many people defended the school board by saying that the board doesn't have the ability to request detailed information outside of a general supervisory role. However, what we are reading about here is real, actual inquiry - and that's a very good thing. That's exactly what we want and should demand from members of the school board. The fact that this didn't happen around issues of lead - despite a well documented history of lead in school water in Portland, going back to 2001 - calls into question the role of the board in Portland's ongoing lead issues.

It's easy to beat up on the district. It's much harder - and more politically costly - to tackle the ossified issue of school funding. It's even more difficult to engage the teacher's and/or principal's unions over issues of racially biased discipline. If we're serious about equity, we can't approach this piecemeal, and we can't just take on the easy fights. An engaged school board willing to listen to the community, and take on the hard issues, is an essential piece of what school improvement will look like.

MySchoolBucks, or Getting Lunch with a Side of Targeted Adverising

6 min read is an application that is part of services offered by Heartland Payment Systems, Inc, a company in New Jersey. MySchoolBucks processes payments from parents for school lunches.

Before we proceed any further, we must highlight one thing here: this post IS NOT about the federal, state, or local school lunch programs. This post addresses a vendor that has inserted itself between students, schools, and lunches.

The premise of MySchoolBucks is pretty simple. Parents put money into an account on the site. Accounts are tied to a card used by the student to pay for lunch, and the system keeps track of how much money families have in their accounts.

To make this system work, MySchoolBucks collects a parent name, the name of any children enrolled in school, and the school they attend. Parents add money to their MySchoolBucks account via credit card, so MySchoolBucks also processes credit card payments.

However, reading the Privacy Policy of MySchoolBucks shows some oddities that have nothing to do with supporting parents, students, or schools with lunch. It's also worth noting that MySchoolBucks has a "feature" I have never seen before on any other policy: after six or seven minutes, the privacy policy page automatically redirects you to the home page. It's almost like the company doesn't want you to read their privacy policy at all.

But, for those of use who persevere, we discover some oddness in this policy.

In the opening "Glossary" section, MySchoolBucks defines a Business Partner as follows:

"Business Partners" means, collectively, third parties with whom we conduct business, such as merchants, marketers or other companies.

Then, in Section 4, MySchoolBucks states:

We (or our Vendors on our behalf) may share your Personal Information ... with relevant Business Partners to facilitate a direct relationship with you.

So, business partners include marketers, and marketers can be given personal information. As noted above, the personal information collected in this application includes parent name, child's name, and the child's school.

Taking a look back at at the glossary, we get this definition of non-identifying information:

"Non-Identifying Information" means information that alone cannot identify you, including data from Cookies, Pixel Tags and Web Beacons, and Device Data. Non-Identifying Information may be derived from Personal Information.

This definition omits that many of these elements can be used to identify you. Thousands of web sites collect this information, which means that there is a large dataset of what this vendor inaccurately calls "non-identifying information."

Further down in the policy, MySchoolBucks states that they share "non-identifying information" pretty freely.

We may disclose Non-Identifiable Information which does not include Protected Data:

  • with Business Partners for their own analysis and research; or
  • to facilitate targeted content and advertisements.

Because Heartland Payment Systems shares what they misleadingly call "non-identifying information" with marketers and 3rd party ad servers with no prohibitions on how it can be used, this "non-identifying" data can be combined with other data sets, and then tied to your precise identity.

Accordingly, the claim of "non-identifying" data is probably accurate from a very narrow legal perspective, but it does not represent the reality of what is possible when data from multiple datasets are combined and mined.

MySchoolBucks also supports login via Facebook, which creates additional problems:

You may register to use our Services using your existing Facebook account. If you opt to use your Facebook account to register to use our Services, you authorize Heartland to collect, store, and use, in accordance with this Privacy Policy, any and all information that you agreed that Facebook, Inc. ("Facebook") could provide to Heartland or Heartland's third party authentication agent through Facebook's Application Programming Interface ("API"). Such information may include, without limitation, your first and last name, Facebook username, unique Facebook identifier and access token, and e-mail address.

The inclusion of the unique Facebook identifier, combined with a device ID (which is likely collected as part of the "non-identifying information") would be sufficient to tie a precise identity to many occasions where a person clicked a "like" link, or shared a link on Facebook. If someone could explain why this information is needed to pay for a 2nd grader's lunch, I'm all ears.

There are other issues with the privacy policy and terms of service of MySchoolBucks, but getting into the deep weeds of every single issue with the policies obscures the larger point: paying for a kid's lunch at school shouldn't expose the student or parent to targeted advertising.

MySchoolBucks and Portland Public Schools

The site came to my attention a couple weeks ago when I was reviewing back to school emails for my child. My local school district uses this service. I attempted to find any information about this site on the district web site - in particular, any contract that would give more information on how student and parent data use was limited - but found nothing.

To be clear: the lack of information and disclosure from Portland Public Schools is unnecessary, and fosters mistrust.

Portland Public Schools could take three immediate steps to address these issues:

  • List out the district and school level vendors that have been designated school officials. Link to the privacy policies and terms of service of these companies, and upload the text of any additional contracts in place between these vendors and Portland Public Schools.
  • List out vendors used within schools where the vendor has not been designated a school official. Link to the privacy policy and terms of service of these companies. This list would require input and feedback from schools, as they would need to collect up information about the software used within each school to support teaching and learning.
  • Document the process and criteria used to select technology vendors for district wide services. Right now, the decision making process is completely opaque to the point where it's impossible to know if there even is a process.

The distinction between vendors who have been declared school officials and vendors that require parental consent is key, as the rules around data use and sharing differ based on the status of the vendor. The lack of any documentation around contracts is also problematic. Contracts are public documents, and these purchases are made with public dollars.

It's worth noting that this is information that should be on the Portland Public Schools web site already. At the very least, parents shouldn't need to wonder who is processing their children's information. I understand that there are numerous details competing for attention within the district, but at some point, excuses need to stop, and be replaced with results. The current level of awareness and attention to student privacy issues within Portland Public Schools is problematic, at best. The communications about these issues have been factually inaccurate, which begs the question: how can we trust Portland Public Schools to get the complicated issues right when they appear to be missing the basics?


Facebook, Privacy, Summit Public Charters, Adaptive Learning, Getting Into Education, and Doing Things Well

7 min read

One of the things that I look for within schools is how solid a job they do telling their students and families about their rights under FERPA. One crude indicator is whether or not a school, district, or charter chain contains any information about FERPA on their web site. So, when I read that Facebook was partnering with Summit Public Charter Schools, I headed over to the Summit web site to check out how they notified students and parents of their rights under FERPA. Summit is a signatory of the Student Privacy Pledge and a key part of what they do involves tracking student progress via technology, so they would certainly have some solid documentation on student and parent rights.

Well, not so much.

It must be noted that there are other ways besides a web site to inform students and parents of their FERPA rights, but given the emphasis on technology and how easy it is to put FERPA information on the web, the absence of it is an odd oversight. I'm also assuming that, because Summit clearly defines themselves as a Public Charter school that they are required to comply with FERPA. If I'm missing anything in these assumptions, please let me know.

But, returning to the Facebook/Summit partnership, the news coverage has been pretty bland. In fairness, it's hard to do detailed coverage of a press release. Two examples do a pretty good job illustrating the range of coverage: The Verge really committed to a longform expanded version of the Facebook's press release, and the NY Times ran a shorter summary.

The coverage of the partnership consistently included two elements, and never mentioned a third. The two elements that received attention included speculation that Facebook was "just getting in" to the education market, and privacy concerns with Facebook having student data. The element that received no notice at all is the open question of whether the app would be any good. We'll discuss all of these elements in the rest of the post.

The first oversight we need to dispense with is that Facebook is "just getting in" to education. Facebook's origins are rooted in elite universities. The earliest versions of the application only allowed membership from people enrolled in selected universities - Ivy League schools, and a small number of other universities.

Also, let's tell the students interacting on these course pages on Facebook - or these schools hosting school pages on Facebook - or these PTAs on Facebook - that Facebook is "just getting in" to education. To be clear, Facebook has no need to build a learning platform to get data on students or teachers. Between Instagram and Facebook, and Facebook logins on other services, they have plenty. It's also worth noting that, in the past, Facebook founder Mark Zuckerberg has seemed to misunderstand COPPA while wanting to work around it.

Facebook - the platform - is arguably the largest adaptive platform in existence. However, the adaptiveness of Facebook isn't rooted in matching people with what they want to see. The adaptiveness of Facebook makes sure that content favored by adverisers, marketers, self promoters, and other Facebook customers gets placed before users while maintaining the illusion that Facebook is actually responding directly to people's needs and desires. The brilliance of the adaptiveness currently on display within Facebook is that, while your feed is riddled with content that people have paid to put there, it still feels "personalized". Facebook would say that they are anticipating and responding to your interests, but that's a difficult case to make with a straight face when people pay for the visibility of their content on Facebook. The adaptiveness of Facebook rests on the illusion that they allow users to select the content of their feeds, when the reality of Facebook's adaptiveness as manifested in their feeds is more akin to a dating service that matches ads to eyeballs.

Looking specifically at how this adaptiveness has fared in the past raises additional questions.

Facebook's algorithms and policies fail Native communities.

Facebook's algorithms and policies fail transgender people.

Facebook's algorithms and policies selectively censor political speech.

Facebook's algorithms and policies allow racism to flourish.

Facebook's algorithms and policies ruined Christmas (for real - maybe a slight overstatement, but I'm not making this up).

Facebook allowed advertisers to take a woman's picture and present it to her husband as part of a dating ad.

Facebook's algorithms and policies can't distinguish art.

Facebook's algorithms and policies experiment with human emotions, without consent.

I could continue - we haven't even talked about how Facebook simplified government surveillance, but you get the point: the algorithms and policies used by Facebook tilt heavily toward the status quo, and really miss some of the nuance and details that make the world a richer place. In an educational system, it's not difficult to see how similar algorithmic bias would fail to consider the full range of strengths and abilities of all the students within their systems. Facebook, like education, has a bad track record at meeting the needs of those who are defined as outside the mainstream.

In educational technology, we have heard many promises about technologies that will "disrupt" the status quo - the reality is that many of these technologies don't deliver more than a new UI on top of old systems.

There Is An Easy Solution Here

Fortunately, none of these problems are insurmountable. If Facebook released the algorithms to its learning platform under an open source license, no one would need to guess how they worked - interested parties could see for themselves. Facebook has done this with many projects in the past. Open sourcing their algorithms could potentially be an actual disruption in the adaptive learning marketplace. This would eliminate questions about how the adaptive recommendations work, and would allow a larger adoption of the work that Facebook and Summit are doing together. This wouldn't preclude Facebook or Summit from building a product on top of this work; it would just provide more choices and more options based on work that is already funded and getting done.

It's also worth highlighting that, while there will be many people who will say that Facebook has bad intentions in doing this work, that's not what I'm saying here. While I don't know any of the people doing work on the Facebook project, I know a lot of people doing similar work, and we all wake up wanting to build systems that help kids. In this post, I hope that I have made it very clear that I'd love to see a system that returned control of learning to the learner. Done right, adaptive learning could get us there - but "doing adaptive right" requires that we give control to the learner to define their goals, and to critique the systems that are put in place to help learners achieve. Sometimes, the systems around us provide needed support, and sometimes they provide mindless constraints. Adaptive learning needs to work both ways.

Open sourcing the algorithms would provide all of us - learners, teachers, developers, parents, and other people in the decision making process - more insight into and control over choosing what matters. Done right, that could be a very powerful thing.

Apple's Plan For Managing COPPA Consent Has A Couple Problems

4 min read

For schools running programs using Apple hardware, Apple has set up a guide to streamline the process of creating an Apple ID for each student.

This guide includes a section on creating accounts for students under the age of 13:


Under the Children's Online Privacy Protection Act (COPPA), Apple must obtain verifiable consent by a parent or guardian to our Privacy Policy and Parent Disclosure and Consent notice before an Apple ID can be created for a student under 13 years of age (see As part of the communications process with parents or guardians, your institution will need to assist Apple in ensuring consent is obtained from a student's parent or guardian.

The instructions quoted above indicate that the school is the broker for arranging parental consent. This is a fairly standard practice among edtech companies (whether or not this is good practice is a different conversation). We will also look at the linked Parental Disclosure Consent doc later in this post.

Apple's guide includes step by step instructions for creating Apple IDs. The first step merits a close reading:


Step 1. Prepare Apple ID request. To create new Apple ID accounts, you will need to upload a correctly formatted, comma-separated value (CSV) file containing a list of students who need Apple IDs. To download a template, go to Import Accounts and click Download Account Template. To edit the template, use an application such as Numbers, Microsoft Excel, or another application that can save CSV files. To complete the template, you will need to provide the batch number or batch name, student name, student Apple ID, student date of birth, and the parent or guardian email address for each student request.

To highlight a couple key points, Apple's process requires that every school prepare a text file (CSV stands for comma separated values) with the name, birthdate, and parent contact of every student. Text files are notoriously insecure - anyone who gets this file can access the information within it. So, Apple's recommended method for creating student IDs requires creating a comprehensive list of sensitive student data in one of the least secure formats available.

This post explaining the process goes a step further; they use student Gmail addresses for the Apple ID. Practically, this means that if this file was ever compromised, the people who accessed the file would have student names, dates of birth, parent email, and student email.

In case people wonder why this is a concern: when you store data in an insecure format, you expose your students to greater risk - as happened with these students in New Orleans. And these students in Escondido. And these students in Seattle. And these students in Maine.

By encouraging the use of CSV files to move sensitive student information, Apple encourages insecure data handling practice. It's unacceptable for any age group, but it somehow feels worse for students under the age of 13. The fact that this is accepted as sound practice by edtech staff anywhere is also problematic.


Parent Disclosure

The full text of the Parent Disclosure doc is essential reading, but we will highlight a couple sections here. For example, after Apple has parental consent, they are clear that they will collect a range of information from all students.


We may collect other information from your student that in some cases has been defined under COPPA as personal information. For example, when your student is signed in with his or her Apple ID, we may collect device identifiers, cookies, IP addresses, geographic locations, and time zones where his or her Apple device is used. We also may collect information regarding your student's activities on, or interaction with our websites, apps, products and services.

Apple states very clearly that they will tie location and behavior to an identity for all students, of all ages.


At times Apple may make certain personal information available to strategic partners that work with Apple to provide products and services, or that help Apple market to customers. Personal information will only be shared by Apple to provide or improve our products, services and advertising; it will not be shared with third parties for their marketing purposes.

In this clause, Apple clearly states that they (Apple) will use personal information to improve Apple's advertising and marketing.

According to Apple's published policies and documentation, participating in a school's iPad program requires student data flowing to Apple's marketing and advertising, and encourages sloppy data handling by schools.

, , ,

Building An Application To Simplify Software Inventory

3 min read

In an earlier blog post, we described a process that could be used by schools and districts to inventory the applications used to support teaching and learning. This inventory covered details of contracting, educational rationale for the application, and the privacy implications of the application. Much of this evaluation will be identical across schools, so it doesn't make sense for different schools to sink time into doing indentical work across the country.

Since we put that post out, we have talked a lot internally about what it would require to build that application. We have also talked with educators, administrators, privacy advocates, vendors, and parents about the idea, and have received enough feedback where we don't feel like we are missing anything obvious. To round out the application, we would want to include some information about the text of privacy policies.


  • Date policy reviewed
  • Date policy was updated
  • Date policy was archived
  • Policy copy - text
  • Policy copy - image

The information in this section would allow us to do a few things. First, it would allow people to see how current (or out of date) a review was. Second, if a policy had been updated after a review, that would be a flag that the review was out of date and needed a touchup. Third, the text archives would allow us to maintain a verifiable changelog of policies over time, as policies are often changed with no announcement or explanation. Fourth, maintaining a text version onsite would allow us to automatically check for changes in the policy, which would in turn alert us to the need to revisit or update a review.

When the application was done, schools or districts could pass the application a list of names, and would receive a complete dataset of reviews. As described in our earlier post, they could augment these reviews with the contracting and pedagogical rationale that was specific to their use. However, this application makes it possible for districts to research apps more quickly, and document their technology use more thoroughly.

The project would be built on the following assumptions:

  • Code that runs the site would be open source;
  • Data that is stored in the site would be openly licensed;
  • Compiling the reviews would be the largest initial hurdle. Based on conversations I have had with various schools and districts, though, there is no shortage of people who need this information, and are tackling it on their own. Ideally, we would work with interested partners to help facilitate the review process;
  • Over time, maintaining the reviews will require additional time from people reviewing updated terms and new apps, and people reviewing the reviews;
  • Over time, maintaining the software will require ongoing outreach to make sure that we are measuring things that answer questions people care about (or should care about);
  • Maintaining project infrastructure will also be an ongoing expense.

If you have any ideas/feedback on this, please, let us know.

, ,

Taking Inventory of the Tech Schools Use

10 min read

This post was originally published at Educating Modern Learners.

Anyone working in or around education technology in the last two decades has likely experienced the tension between district-level technology policies and classroom-level technology implementation.

In very general terms, district-level decisions tend to minimize risk, often at the expense of teacher autonomy and creativity. On the other end of the spectrum, classroom-level implementations – where a teacher brings in an application outside of district- or school-level approval processes – can get teachers the resources they want to use with less hassle. However, over time, classroom-level implementations that sidestep school- and district-level review often result in a patchwork of applications, with little or no review for privacy, security, or effectiveness. Complicating matters even further, district-level reviews and contracting processes aren’t always adequate – and even if they are, district policies are often not explained in terms that make sense or are relevant to teachers.

Disconnects Within Educational Systems

The disconnect between classroom needs and district needs increases when district review schedules do not align with classroom schedules. Because of this longstanding and inherent tension between a district’s need for stability and a classroom teacher’s need for flexible and timely adaptation, we create a situation where districts are not fully informed of software use at the school level, and district security needs are not understood at the classroom level. The fallout from broken processes often results in students, parents, teachers, school administrators, and district staff all having an incomplete and inaccurate vision of the technology used while learning.

The fallout from broken processes often results in students, parents, teachers, school administrators, and district staff all having an incomplete and inaccurate vision of the technology used while learning.

The good news is that this broken communication can be fixed with a simple inventory, and taking inventory of software used to support teaching and learning within a school is not rocket science. It requires time, and the process of documenting software used to support teaching and learning will almost certainly uncover shortcuts in the contracting and vetting process, but we can’t continue to allow the mistakes and habits of the past to shape the learning environments of the present.

Inventory To The Rescue

In this post, we will create a replicable process that can be used by students, teachers, school administrators, and/or district staff to document the technology used in your learning environments. One of the barriers to implementing pedagogically sound technology programs is a clear sense of what is being used, and why. An inventory, evaluation, and privacy review of existing technology needs to be part of how we implement software used in learning. The point of documenting software and technology currently in use is not to be retroactively punitive

In all likelihood, there will be holes in what can be documented initially at both the school and district level. If people at the school level are fully forthright, there will almost certainly be apps used within schools that violate district policy – and depending on the context, that could be attributable to district red tape, school-level intransigence, and/or teachers being under pressure to get their work done. If people at the district level are fully forthright, the inventory will reveal shortcomings in both the contracting and review process. However, the point of documenting software and technology currently in use is not to be retroactively punitive, and “success” does not require all schools and teachers to fall in line with district policies. The goal here is to establish a baseline, and learn how to do better – including questions to ask ourselves, our vendors, and our students – as we move forward. “Doing better” requires changes in district policies, school implementation, teacher practice, and vendor policies. All stakeholders have a role to play.

The process of taking a complete inventory will highlight places where all stakeholders need to improve. School and district staff need to tighten up contracting processes, and do a more thorough job evaluating software and systems for privacy and security. Teachers need to triage applications for privacy and effectiveness. Vendors need to clean up their privacy policies and terms of service and stand fully behind their product, and ensure learners that their work today is not getting fed to a data broker tomorrow – and teachers, students, parents, and administrators need to demand responsible and safe behavior from vendors.

Steal This Process!

The core of any inventory system starts with a list. To jumpstart this process, we created a Google Spreadsheet that you can copy and modify for your local use. The structure of this spreadsheet could also be starting point for a more structured database.

The process of taking inventory includes four steps:

  • General information – a list of software or services, with contracting information;
  • Purpose: What Does It Do – a description of how the software or service supports learning or administrative needs;
  • How: Types of Records, and Data Collected – a description of the data collected by the software;
  • Privacy: How Is Data Protected (or Not Protected) – an overview of basic privacy details

General Information

  • Name: Name of Application
  • Web Site: Web site of the company
  • Authorized By: Who brings in the application, or authorizes its use? (District/School/Teacher/Other)
  • Contract: Does the application require a contract to use?
  • Contract Location: If yes, where is the contract?
  • Contract Duration: What is the duration (start and stop dates) of the contract?

Purpose: What Does It Do

This section summarizes what the app does, and why it is useful or effective.

  • Description: what does the application do, and/or how does it support learning? Is the application used/supplied by the district to manage student, parent, and teacher data? Example applications here could include a gradebook, a student information system, a system designed to manage IEPs, systems designed to support communications about snowdays, etc. Is the application used to support learning? Examples here range from a district-supplied textbook from Pearson to a schoolwide use of IXL to a math app or a music app used by an individual teacher.
  • Access: How do students access this application? Is the application a web site available online, a program that is downloaded, an iPad or tablet app, a Chromebook app, or any of the above?
  • Indicators: what indicators show that the app is effective, or supports the goals it aims to achieve?

How: Types of Records and Data Created

This section provides an overview of data collected by the app, and where the data is stored. It is likely that some vendors will not support or share some of the information outlined in this section. If a vendor does not support a feature or describe their data process, the column can be marked “unknown” or “unsupported.”

Also, this section contains two questions related to the Family Educational Rights and Privacy Act, or FERPA. This only applies to the United States; if you are outside the US, omit these questions and delete these columns from the spreadsheet.

  • Data Stored: What data is collected and stored by a learning application? This field can be a link to a detailed data specification, or a general list of data points that can often be found in privacy policies.
  • FERPA: Does the app create educational records as defined by FERPA? It’s worth noting that many apps will collect data that is considered an educational record under FERPA, alongside data that is not considered an educational record. The data that is not part of an educational record would therefore be governed by a vendor’s terms of service. The point here is to get a sense of what the legal obligations are with respect to the data collected in the application. The US Department of Education provides some solid resources around FERPA.
  • Other Data: Does the app collect data that is not considered an educational record under FERPA?
  • Student Review: How can students and parents review, modify, correct, or delete data collected by the application?
  • Storage: Where is data collected by the app stored? Is it on a local server controlled by the school or district, on a server controlled by the vendor, or in another form of remote storage?
  • https: does the app use https at all times? In this doc we try and avoid absolutes, but if an app collects data and is not using https it should not be used.
  • Security Measures: how is data protected? Many apps contain some details about this in their terms of service of privacy policies.

Privacy: How Is Data Protected (or Not Protected)

This section highlights some elements of how vendors will use or transfer data, as defined in their privacy policies and terms of service. To complete this section of the inventory, you will need to read and review the terms of service and privacy policies of software and services. See here for tips on triaging privacy policies and terms of service.

  • Privacy Policy: What privacy policies govern use of the application? Link to the policy.
  • Terms of Service: What terms of service govern the use of the application? Link to the terms.
  • Additional Terms: Are there additional terms or conditions that govern how the application can be used? Link to any applicable terms or policies.
  • Opt Out: How can students and parents opt out of using a specific application?
  • Affiliates: Do the privacy policies and terms of service allow for data to be transferred to partners or affiliates?
  • Business Transfer: Do the Privacy Policies and Terms of Service allow for the sale or transfer of data in case of an acquisition, merger, sale, or bankruptcy? Most apps currently allow this, and this is an area where vendors can improve their current practice. The effect of allowing sales in case of merger or bankruptcy means that we can’t predict where data collected in an educational setting will end up, or how our student’s data will be used over time.
  • Cancellation: If the teacher, school, or district ends the contract, does all school/district data get deleted?
  • Data Sunset: Does the vendor have data sunsets (a period of time after which user data will be permanently deleted)?
  • Portability: How can parents or students download data collected and stored by the application?
  • Parent/Student Deletion: How can a student or parent fully delete their information from the application?
  • Changes w/o Consult: Can the vendor change the terms without consulting users?


As mentioned earlier, the spreadsheet and the process described in this writeup are intended for you to take them and use them. Modify them as needed. If there are things you feel should be added here, please let us know.

Once the inventory has been completed, the list can be made public so school communities have a clear sense of what technology is used, and the privacy protections in place with each service. Getting the details documented lets us start the conversation from an informed place. We can’t build on or improve current practice without a clear sense of what current practice looks like.

, ,

Improving FERPA Access and Awareness, in Portland and Beyond

6 min read

In late August, I wrote about how different school districts and charter chains informed people about FERPA rights via their web sites. In the small number of schools and charter organizations reviewed, practices varied widely. Some organizations had no information obviously accessible online, where a smaller number of organizations did a pretty good job of making information about FERPA available. As a continuation of that work, I wanted to look at how parents and students are notified of their FERPA rights in the back to school paperwork. Online resources are one facet of the issue, but many districts still rely on paper forms to both gather information from families, and inform families of their rights.

In Portland Public School District in Portland, Oregon, parents received intake forms to start the new academic year. This blurb about FERPA - but not mentioning FERPA by name - describes how parents and students can learn more about and hopefully access their rights.

This screenshot shows the text as it was sent home to parents:

The text below quotes the screenshot to make the language sent home to parents more accessible:

For annual notices on Directory Information, Student Records, Military Recruiting and Protections of Pupil Rights, please see the District Parent and Student Handbook.

If you do not want your student to have access to district-provided email or on-line educational tools, please contact your school.

Under federal law and school policy, the school district may release the following information without prior parental consent: Student name, participation in officially recognized activities and sports, weight and height of members of athletic teams, degrees, honors, and awards received, major field of study, dates of attendance and the most recent school attended. If you do not want this information released, please contact your school to submit a written request. This form must be completed each year. Student photographs are commonly used in yearbooks, newsletters, websites and other school-related publications. If you do not want your student’s photograph used or released for these purposes or for news media, please contact your school to submit a written request. [Non-Release of Student Directory Information Form]

Student photographs are commonly used in yearbooks, newsletters, websites and other school-related publications. If you do not want your student’s photograph used or released for these purposes or for news media, please contact your school to submit a written request [Publicity Denial and Non-Release of information to School Directory Form].

Many schools or PTAs publish school directories that include parent/guardian contact information. If you do not want your name and contact information released for the school directory, please contact your school to submit a written request [Publicity Denial and Non-Release of information to School Directory Form].

This Is Confusing

To break this down, this single section - buried among multiple other forms - instructs parents to take the following different steps: 1. review the District Parent and Student Handbook (which is not included in the packet, and does not included any information on where to find the Handbook); 2. contact the school to ask about email and online tools; 3. contact the school to get a Non-Release form; and 4. contact the school to get a Publicity Denial form - and the Publicity Denial form covers two separate situations.

To summarize: parents who want to lean more about their rights under FERPA have been sent to 4 places for 5 reasons. None of the places to get additional information (with the exception of the general "contact your school") have been clearly defined. The directory information section lumps yearbook pictures alongside directory information, and then repeats the same clause verbatim and points parents to a different form.

Digging Deeper Doesn't Help

Things just get worse when you actually try and find specific information. Searching the PPS site for the District Parent and Student Handbook brings up this page as the first hit. The page title - District Parent and Student Handbook - is reassuring, but the contents link you to three separate documents: "Student Responsibilities, Rights, and Discipline Handbook", a "Calendar Template", and a "Parent/Student Handbook template". None of these documents align cleanly with the document referenced in the original form, and the content on this page appears geared toward school admins and not parents.

Attempting to find the other forms referenced in the original document ("Non-Release of Student Directory Information Form" and "Publicity Denial and Non-Release of information to School Directory Form") isn't any easier. Both forms are linked here, on this page which links over 25 forms covering random policies ranging from requesting VPN access to the "Dashboard SIS Metro Data Confidentiality Agreement."

The current process for learning about FERPA rights in Portland Public Schools is arcane to the point of worthless. From some superficial reviews of the processes in other districts around the country, I get the sense that PPS is about average. From looking at the available documentation from charter school chains, my preliminary take is that public schools are doing better than their charter counterparts.

Making FERPA More Accessible By Meeting Parents and Students Halfway

Here is how Portland Public Schools - and just about any other school district or charter chain in the US - could inprove their process for parents, students, and schools and ensure that they are in line with both the spirit and the letter of existing Federal privacy laws:

  • Create a single page on their web site that describes FERPA rights, including the right to opt out.
  • Create sane options that make sense to parents for opting out of information sharing. For example, parents should be able to opt in to sharing information in an internal private school directory and yearbooks while not having information publicly available and shared without notification.
  • If they are not doing so already, schools should maintain an access log of when Directory Information is shared. This log should be accessible in the school office during the school year, and copied to the district at specified points throughout the year. District staff would maintain this access log over time, going back 5 to 7 years.
  • The process for parents and students to access and review educational records as guaranteed under FERPA should be clearly defined. Implementation of student and parent rights should err on the side of ensuring that parent and student voice is supported and present in a student's educational record. While this issue goes beyond FERPA, student and parent rights under FERPA can be used constructively to support student voice.
  • Provide training for PPS and school staff on aspects of FERPA, including what constitutes an educational record, and how to handle parental requests to both opt out of directory information and review student records.

FERPA is one small piece of the larger privacy puzzle - of equal concern is the gray area of data collected by edtech vendors that isn't covered under FERPA as an educational record. If we can get greater clarity of parent and student rights under FERPA, we can use this foundation to advocate for meaningful changes from schools, districts, vendors, and state and federal lawmakers.

, ,

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.


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.

, ,