logoalt Hacker News

codedokodeyesterday at 8:42 PM5 repliesview on HN

I think the header/metatag is designed poorly. The RTA proposal is that every operator of every site must verify the content and add the header to mark the site as "safe" or "unsafe". This is unnecessary burden that they have to bear if this proposal is given a green light and this is wrong.

Instead, the default should be, that if there is no header or it cannot be parsed, then the content is unsafe. And if there is a header, it describes the page rating, like what kind of dangerous content it may contain. The header may be added to any displayable content like HTML, text, images, audio or videos, but not to machine-readable content like JS files or AJAX responses.

So only those who wants their site to be accessible by minors, have to add headers. For social networks, the user might have an option to mark his content as "safe".

This means that with my proposal existing site operators need not to do anything to mark their sites as "unsafe" - all sites are "unsafe" by default. This means that millions of site operators need to spend 0 dollars to adapt their sites. How great is that?

The browser on a device with parent mode, should not allow displaying any content which doesn't have a header or that is marked as unsafe, or that contains header with invalid value. The parents may whitelist some sites.

There should be a reponsibility for intentionally marking unsafe content as "safe". We should also think what to do with foreign operators, intentionally putting invalid headers for unsafe content. Maybe they should be added to some kind of blacklist that the browsers would periodically update.

Search engines like Google could work by default in "safe" mode, but add "unsafe" header if the user wants to turn off restrictions.

> If a site is not adding the RTA header then progressively fine them into oblivion.

I think my proposal is better because it requires only fining those who intentionally misrepresent content safety.


Replies

AnthonyMousetoday at 4:56 AM

> Instead, the default should be, that if there is no header or it cannot be parsed, then the content is unsafe.

That's something the client should be doing. You can configure your own device (or your kid's) to have whatever default you want.

The actual problem is that classifying the entire firehose of user-generated content is precarious and uneconomical, so the default tag is going to be whatever minimizes liability. If untagged implies "unsafe" and "unsafe" minimizes liability then the majority of content will be untagged. If untagged implies "safe" then the majority of content will end up explicitly tagged as unsafe, because tagging it as unsafe minimizes liability.

But either way if you disable "unsafe content" you'll end up disabling almost everything, specifically including the huge amount of "safe" content which isn't tagged as safe because accurately classifying it is uneconomical.

lokaryesterday at 10:14 PM

The page having a simple rating assumes there can be one mapping from content to rating for the whole world. I doubt we can even have one for North America and Europe.

show 5 replies
fc417fc802today at 1:00 AM

The problem with your proposal is that it's already the status quo. Various whitelists exist but service operators don't generally bother with these things. What you end up with is a largely unusable experience if you enable whitelist filtering.

The core problem is the lack of buy in. Unfortunately that likely needs to be forced. I think it's not unreasonable to legally require people to make a claim about the nature of what they are serving up. They already need to be aware of the legal status of what they're doing anyway so it hardly seems as though making such a determination should pose a burden when you consider that it's an alternative to either requiring ID, requiring the client send age bracket information, or other heavy handed interventions. The choice here isn't "the status quo vs a header" but rather "some other age related regulation vs a header".

An easy way to enforce this "voluntarily" (ie coerce) without sending government agents after every small time website operator would be to require that mainstream browsers and other client software (based on MAU or similar metrics) refuse to process content that does not send a classification header. Doesn't matter what the header says or what the status of the user account or parental controls or whatever else is, it has to send the header regardless or it will be blocked without exception. That would presumably trigger broad compliance with the relevant regulations.

show 1 reply
Benderyesterday at 8:47 PM

For what its worth this header has been around for a very long time. It's actually the second iteration and much simpler than it's predecessor.

Parents today can accomplish what you are suggesting by installing parental control software and only allowing access to things they explicitly approve.

This can also be done via headers explicit blocking of all the things and was suggested in another thread. [1] Some people liked the idea.

[1] - https://news.ycombinator.com/item?id=47952999

show 1 reply
xoayesterday at 9:07 PM

Yes, exactly, this should be really simple as a foundation: by default the Internet is for adults. All of it. Where it's desirable for things to be available for kids, create the economic incentive and easy tools for parents to use and run on a white list, not a black list.

I'd actually go somewhat further though and ask whether it's a good idea to even do this via web pages at all. We have a great potential system for this already: DNS. Do something useful amongst all the ridiculous vanity and spam TLDs for once and set up a ".kids" gTLD, or ccTLD for that matter so that different countries can set their own regulatory standards naturally (ie, .kids.us, .kids.uk etc). Domains could also be used for some broad buckets for people who don't want to drill in, ie, .1-6.kids, .7-12.kids, .13-17.kids, or whatever is deemed appropriate, but simple age brackets that would offer some sane defaults. 1-6 could simply not allow any ads, user generated content or algorithmic feeds whatsoever for example. There are a lot of knobs to turn. And then at the registry level it can be ensured from the get-go that anyone getting a .kids domain is fully identified, located in the country in question, has valid ID, has specific credentials or is an accredited organization, or whatever other criteria makes sense.

But ultimately the point would be to create something that is built right from the ground up, and in turn that doesn't interfere with what has already been built at all. Something that can also be worked with at the gateway and thus cover every device on a LAN, and for that matter can easily be plugged into the vast number of powerful tools we have for working with that stuff. It'd be easy to put a nice UI on all this, even to make it higly automated. For example, have a setup wizard where you enter children, put in date of birth for each, and it'll spit out a password for each one. This then auto-provisions the network such that each kid has their own VLAN (password for PPSK or even wired connection) and is automatically limited to the domain groups of their age bracket, which then changes as their age changes.

Parents should be able to dig further in and get more granular with content categories, metadata for which could be required for anyone hosting a site within that domain, but I think there is the potential to make something both pretty bullet proof and pretty accessible, using existing tech stacks, and without impinging on the present internet at all including privacy and anonymity.

show 2 replies