Fixing online safety where it counts

Facebook’s in the news again as yet another country wants them to add a “safety” or “panic” button to the site so that users (especially children) can easily report any improper contact from other users. This time it’s Australia asking for it, but a similar row erupted a few months ago with Facebook’s UK operation.

The trouble is that these law enforcement and child protection agencies are trying to address the problem in the wrong place. Facebook is an obvious target because of its size, and because it has definitely been the source of improper contact in the past. But what of the many other websites out there which allow inter-user communication – from forums, through IM proxies, all the way up to the social networking sites of which Facebook is just one example (albeit the biggest)?

Trying to get buttons added on a site-by-site basis is a Sisyphean challenge – no sooner has one site gained a button than there is another growing in market share which needs to be similarly adorned. No, adding buttons to sites is not the right solution. Instead they need to be added to the browser.

Adding the panic button to the browser itself isn’t as straightforward as it sounds. There would need to be agreement on how it works: Would the browser become responsible for submitting an abuse report to the authorities? If so, it would require some sort of API to obtain relevant information from the site itself. Or would it simply call a web service on the site, triggering an abuse report from that end, and hooking into whatever abuse reporting system the site already has in-place.

My preference would be for both. Hitting the button would call an API on the site, triggering any well-behaved site to store a log of relevant details, and returning an identifier to the browser. The browser itself would submit an incident report to the relevant authorities which includes the returned identifier (so that the two reports can be reconciled if needed), and attaching a screenshot, copies of cookies, or other pertinent data. The user would be able to review this information before sending it, and add their own notes. This isn’t too different to the automatic crash reporters that most browsers include now, except that the more sensitive nature of the information would require some additional safeguards.

The beauty of this approach is that the authorities only have to deal with the relatively small pool of browser vendors, not the much larger ocean of websites. If a website doesn’t support the API then a report can still be submitted, it just means slightly less evidence being available. The authorities might still need to bring a little pressure to bear on individual websites to support the API, but as this has no visible impact there’s likely to be less resistance than there is to adding a button to every page on a site.

By building this into the browser itself it’s immediately available on all sites regardless of size. Adults could opt to not show the button at all, while browsers and extensions that target children (such as Kidzui or Glubble) could enforce its visibility at all times. Consistent button design and default placement across browsers would make it easy to educate children about the button’s use without needing to get specific about any one browser.

So stop pestering Facebook with this, because the day after they give in and implement a safety button, some other bright star of the online world will hit the headlines with improper contacts. Fix the issue where it really needs fixing: at a place in the software stack that can address it for all websites, not just one.