2

If you are building a web application to be used by US schools, you will probably have to worry about COPPA compliance.

Children's Online Privacy Protection or COPPA is new to me, probably because it was passed in 1998 and then quickly forgotten. However, it has a number of very strict rules about storing identifying information of children under the age of 13 and the penalty is $11,000 per violation, so this is not something to ignore.

Here is quick summary of requirements:

  1. Post a clear and comprehensive privacy policy on their website describing their information practices for children’s personal information;
  2. Provide direct notice to parents and obtain verifiable parental consent, with limited exceptions, before collecting personal information from children;
  3. Give parents the choice of consenting to the operator’s collection and internal use of a child’s information, but prohibiting the operator from disclosing that information to third parties;
  4. Provide parents access to their child’s personal information to review and/or have the information deleted;
  5. Give parents the opportunity to prevent further use or online collection of a child’s personal information;
  6. Maintain the confidentiality, security, and integrity of information they collect from children.

Some of these are easy to satisfy. Add a note in your privacy policy, make sure you store the information securely. But #4 makes me the most worried. Are they expecting a backdoor such that a parent will be able to access this information? How do you obtain verifiable parental consent? Is any of this really possible in the context of a web application?

Stéphane Chazelas
  • 628
  • 5
  • 7
rook
  • 46,916
  • 10
  • 92
  • 181

4 Answers4

5

I've seen a similar example implemented in a site with online coursed for students.

The parent would create a "parent account", pay for the course and then be able to create a "student account" for their kid. The kid would now have access to the courses for a certain period of time and the parent would be able to track his progress, see what videos he has been watching etc.

So I don't think you have to create a backdoor, just a new type of accounts, let's call it supervisor. If a child wants to register your site, his account should be created by the supervisor.

One way of obtaining parental consent is by using credit card information and maybe a small one time transaction(1$), just to check that the data is valid.

Dinu
  • 3,166
  • 14
  • 25
  • What if the school is using the software, and automatically registers every child. – rook Jan 15 '13 at 16:34
  • Automatically create parent account associated with the children accounts. Of course, the main problem here would be how to give the parents their credentials, this should be solved in collaboration with the school. – Dinu Jan 15 '13 at 16:36
  • 1
    I would specifically avoid the credit card authentication mechanism. Introducing credit card transaction of any size brings with it the necessity for PCI compliance. This can be a costly and time consuming headache for an organization that isn't dealing with transactions normally. For more info: http://www.pcicomplianceguide.org – grauwulf Jan 15 '13 at 16:55
  • 1
    Introducing the pay mechanism just for this is indeed a big headache. If a school is involved and they are the ones registering accounts, then they should also register the parents and so you would not need such complex verification. – Dinu Jan 15 '13 at 16:59
  • @grauwulf - An alternative is to use an external provider to do the credit card check, then, my understanding (IANAL) is, it doesn't add PCI compliance overhead because you don't have to actually touch the PCI. – AJ Henderson Jan 15 '13 at 17:27
2

Hummm tricky, but certainly possible.

This is coming off of the top of my head so your mileage may very. You've been warned :-)

My first thought would be to have multiuser accounts with different roles. For example: STUDENT & GUARDIAN. This way you can set up the accounts and be up and running with an automatic registration, for the STUDENT users, but still 'provide access' to the student accounts to guardians through a secondary registration. Guardians would then be able to register to the system by using some kind of PII to identify themselves as well as the child. For example: social security / EI number, student id number, first and last name, and DoB. You would, I presume, have to cross reference this with the student records to assert identity but that should be pretty straight forward. Once registered the guardians can be associated to the student account as a secondary role, GUARDIAN. For privacy reasons I would recommend having independent registration for guardian type accounts, even if you then linked those accounts for normalization concerns.

Like I said, it's a little tricky since it's not a normal web account model but it's definitely doable.

Best of luck on your project.

grauwulf
  • 955
  • 5
  • 10
1

From a pure cryptographic standpoint, simply having an encrypted "user key" that is stored twice and encrypted with both the child and parent's keys would allow for the forth part.

The verification of the parent is really the hard part and that's probably best left to a lawyer to define what is sufficient proof.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
1

I know this is probably simplistic, but we use this principle all the time in our requirements phase, and when I explain the cost of protecting PID compared to just not storing it, oftentimes we realize we don't really need PID.

One of the things to ask is "Do we really need to store PID at all? Do we really NEED a first, middle, and last name? If we can use a Student ID and only, because we already full name tied to student ID elsewhere, why have it here? We explain it to business as "If you don't gather it, you don't need to protect it."

Along with that, comes data retention - how long do you keep the data. This has always been a sore point where the business wants to keep it forever, and IT wants to limit how much unnecessary we're keeping. When you factor in securing sensitive data, it's one more argument for forcing the business to really think about how long they need it. Once it's deleted and the backups are destroyed, there's no need to protect it, because you no longer have it.

Of course, you still want to do everything in your power to protect the app from the usual threats, but when it comes to sensitive data, my first recommendation is to only store what you need, and only for as long as you absolutely need it.

David Stratton
  • 2,646
  • 2
  • 20
  • 36