Hacker News Reader

Comment by DanBC | Hacker News Reader

> That's right. The almighty F-word was breaking how some stylesheets were loading for deviants who were accessing the site from computers with overly sensitive system-wide profanity filters installed. These users' browsers likely stopped parsing the stylesheet entirely upon reaching the word in the stylesheet, leading to a fairly ugly and/or broken page.

Wait what? What filters are checking CSS files, and why?

View on HN

Probably overzealous filter that looks at everything going over HTTP and stops passing the connection whenever it encounters a naughty word.

Unsurprisingly these types of filters don't have a lot of understanding of what is going to be displayed to the user vs not, but then again they probably don't need to to satisfy their target audience quite well.

There are several ways the user might be exposed to the contents of the CSS file, but the most straightforward is probably the content property - http://www.w3schools.com/cssref/pr_gen_content.asp .

.fword:before { content: "fuck"; }

Anti-filter method:

    .fword:before { content: "fu"; }
    .fword:after { content: "ck"; }

    <span class="fword"></span>

On a related note, I always wondered if CSS selectors (classes and ids) had any SEO weight, considering they are present in the HTML code. Just in case, for some time I used to carefully choose semantic names for my selectors, which in the end, is not a bad practice for code readability.

In deviantART's case, the F-word was inside a CSS comment, thus supposedly never displayed to the user. So it's weird to block a file for that case.

    The irony here is that we didn't have to do anything to fix this bug (well, we did have to rename an image file that had a vulgar name!).

I don't think that it's the actual CSS, but rather the linked content which triggered the filters.

They probably check everything. Makes sense since naughty words could be hidden in image URLs inside CSS or in Javascript.

Imagine what happens when someone names their content folder 'assets' and it gets rewritten to 'a<star><star>ets'.

(edit: why does double * get escaped away on here.)

Markdown parser turning your emphasis into <strong>

>(edit: why does double * get escaped away on here.)

* text * italicizes, like so: text.

(Putting spaces around the * avoids this behaviour).

This was years ago, but I remember I was unable to test one of our vendor API calls locally because it had to hit something like api.association-of-commercial-something-or-others.com... turns out the corporate filter didn't like the word "ass".

https://en.wikipedia.org/wiki/Scunthorpe_problem

My favourite stupid auto-sanitisation is "consbreastutional"

Also known as the clbuttic mistake.

Reply on news.ycombinator.com