Risk
2/2/2007
12:11 PM
50%
50%

How We Could Protect Pre-Teens Online

Are you familiar with COPPA, the Children's Online Privacy Protection Act? It's a worthy bill, aimed at preventing the online collection of personal information from children under 13 years of age. What most people don't know is, it's turned out to be rather cumbersome for companies to comply with. The result has been that there are few social networking sites which provide a safe place from pre-teens to hang out and chat.

Are you familiar with COPPA, the Children's Online Privacy Protection Act? It's a worthy bill, aimed at preventing the online collection of personal information from children under 13 years of age. What most people don't know is, it's turned out to be rather cumbersome for companies to comply with. The result has been that there are few social networking sites which provide a safe place from pre-teens to hang out and chat.COPPA's regulations mandate certain things in a Web site's privacy policy, when parental consent is required, and what a site's responsibilities are when they offer services to those under 13. Sure, children can simply lie about their age to register. Any many do, as a trip to MySpace will quickly prove. Interestingly, if you look deeper within the profile pages at MySpace and other similar sites, you'll often find that kids tell their true ages, which are often lower than the minimum required to register.

What I'm proposing is, what if we encourage kids of a certain age to gather together and chat in appropriately monitored venues (not necessarily MySpace, but other, as yet unestablished sites)? If done correctly, it could provide safe gathering places where kids can gather completely separated from the sometimes sewer-like atmosphere of the sites used by high-schoolers and young adults.

Here's my idea: What if the minimum age wasn't the gating factor, but that the controls allowed only children of a certain age group to talk together. For example, you couldn't be older than 14 to talk to kids between 10-14 and you could effectively block kids who were younger than that from using a site. And let's say you didn't need to install software on you own PC to do that, that this would be universal. No child could get on an inappropriate site via any computer. How? It's a controversial idea, but one that needs to be discussed: the Social Security number.

If this idea is implemented properly, a child's identity won't be compromised. "This could be easily done via a third-party government agency," Brandon Watson, founder of IMSafer, told me in my investigation into this issue. IMSafer is software and a service that monitors IM traffic for text that's likely coming from (or going to) a predator or pedophile, and sends an e-mail alert to the person who set up the service.

"The idea could be, for a particular site, that if you want to sign up, you enter in your Social Security Number, and maybe one other identifier, say your town, to ensure the number is not a duplicate," Watson said. "Say the service might have a rule for that site that a user has to be older than 16. The service wouldn't store it, wouldn't do anything but say yea or nay."

There it is, as easy as pie. A simple approved/not approved solution. Every time your kid wanted to register, he or she would go through the process through this third party, the site would be apprised of his or her approval status, and admittance would be gained or denied. Same for the predators.

Of course, there is worry that the numbers would be stored, stolen, etc. But I am afraid that all the lawsuits against social networking sites, all the Congressional hearings, and all the good intentions in the world are not going to be as effective a solution. Just asking the predators for their birth dates isn't a solution. Remember, they are bad guys, and bad guys lie. There is a solution. We now need to implement the technology and the rules to make it do exactly what we want it to do: Protect children without compromising their privacy.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-6477
Published: 2014-11-23
Unspecified vulnerability in the JPublisher component in Oracle Database Server 11.1.0.7, 11.2.0.3, 11.2.0.4, 12.1.0.1, and 12.1.0.2 allows remote authenticated users to affect confidentiality via unknown vectors, a different vulnerability than CVE-2014-4290, CVE-2014-4291, CVE-2014-4292, CVE-2014-4...

CVE-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-8626
Published: 2014-11-22
Stack-based buffer overflow in the date_from_ISO8601 function in ext/xmlrpc/libxmlrpc/xmlrpc.c in PHP before 5.2.7 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by including a timezone field in a date, leading to improper XML-RPC encoding...

CVE-2014-8710
Published: 2014-11-22
The decompress_sigcomp_message function in epan/sigcomp-udvm.c in the SigComp UDVM dissector in Wireshark 1.10.x before 1.10.11 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?