Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

First, Do No Harm : Second, Hunt Griefers for Fun and Profit

DZone's Guide to

First, Do No Harm : Second, Hunt Griefers for Fun and Profit

· Web Dev Zone
Free Resource

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

When I chose the title “It’s Not Polite to Flash the Audience” for my discussion on photosensitivity, it was deliberately a bit flip to balance the seriousness of the topic. I had also thought about “First, Do No Harm” but it seemed a little too preachy at the time. Either way, I never imagined that I’d need to think about photosensitivity being an opportunity for twisted minds to physically assault users via the web as happened a few weeks ago. Some [pick any nasty epithet here] decided to post JavaScript and animated images designed to trigger migraines and seizures in users with photosensitive epilepsy. Worse, the message board was located at the Epilepsy Foundation (A full background story, including a description of the attack by an affected user is available at Wired). This goes beyond “normal” griefing—this is assault, plain and simple. Since the attack, there’s been a lot of speculation about who was responsible for the assault and whether they can be caught and, while I’m one of many who would love to have a few minutes with the perpetrator, I’m not very hopeful that the investigation will lead very far. There’s something important that can be done, however, and that’s to get information out there to help prevent things like this from happening wherever possible.

I’ve gotten several requests for more information about photosensitivity since this happened, so I spoke with Andy Hunt at Pragmatic Bookshelf about the issue. Andy reacted similarly to the problem and we’ve decided that, as a public service, we’re going to release Tip 27: It’s Not Polite to Flash the Audience from Design Accessible Web Sites free of charge. Reading back through the tip, however, I wish I had covered the issue more deeply than I did—the tip introduces the idea of photosensitivity and a couple of tools for testing video, but I didn’t go into other kinds of content like I should have. So let’s look at the issues of photosensitivity and user-submitted content like message forums.

The first route of defense for the site developer or administrator is to NEVER allow <script> or <object> content in user posts. This, of course, is a good idea anyway because of the security risks of allowing your users access to these tags. That simple filtering takes care of rogue Flash, Java, and JavaScript, but we still need to deal with with animated GIFs, and here lies the problem. For whatever reason, animated GIFs still seem to be popular in the “still thinking digital watches are a pretty neat idea” parts of the web (with all due apologies to Douglas Adams)—so there is still significant demand for browsers to default to supporting repeated GIF animation. Blocking animated GIFs in user submitted content is difficult at best. The only real options are:

  1. Block <img> entirely: This isn’t appropriate to many forums because it unnecessarily limits discourse.
  2. Filter the src= attribute for *.gif: This doesn’t really work either. An off-site url to a GIF file can easily leave out the file extension but send a correct GIF mime type.
  3. Only allow uploaded images and src= references to your site: This isn’t feasible for technical (do we want to store a ton of graphics for our message boards?) and liability (they uploaded a picture of a giraffe doing what??) reasons.
  4. Moderate all image submissions: If you have enough moderators to handle it, this might be possible, but most of us don't and it’s still an impractical approach.

At the end of the day, only the last solution addresses non-animated images with potentially seizure-inducing patterns. As developers, there are some things that we can’t easily address, and it may be that the best we can do is to provide a notice reminding our users that the forums contain user-submitted content which has not been fully vetted for accessibility—this is generally a nice thing to do when you don't have absolute control over the content anyway.

This means that site administrators need to be aware of problem images that appear on their sites and remove them as quickly as possible and users with photosensitivity will need to be careful, as in public spaces, to be aware that certain patterns may show up that could be a potential threat to them.

For users with photosensitivity concerns, there are also ways for you to configure your web browser to minimize your personal risk from animated content:

  • Firefox: The Content tab preferences has checkboxes for enabling or disabling Java and JavaScript. The turns off Flash while leaving placeholders that allow you to start the content if you wish. Changing the animated GIF settings in Firefox, however, is unnecessarily painful, requiring you to alter the value of image.animation_mode to none or once under about:config. If you’ve never done this sort of thing in Firefox, more detailed instructions are available at mozillaZine.
  • Opera: Altering your preferences for potentially flashing content in Opera is about as easy as it gets. Settings for animated GIF, Java, and JavaScript are easily available in the quick preferences. For Flash, FlashBlock for Opera 9 is available.
  • Safari: Java and JavaScript are easily turned off under the Security tab in Preferences by unchecking Enable Java and Enable JavaScript. To eliminate Flash or Animated GIF, you can use SafariStand (OSX Only)
  • OmniWeb [OSX Only]: Setting your preferences in Omniweb isn't as easy as in Opera, but it makes up for it with improved customization for your settings. Animated images can be set to animate fewer times or not at all In the Ad Blocking preferences tab, and Java and JavaScript can be controlled from the Security Preferences tab. Flash content can be controlled via the Blocked URLs button under Ad Blocking preferences. OmniWeb Help has detailed information on blocking flash content under the URL omniweb:/Help/reference/preferences/AdBlocking.html. One particularly nice feature of OmniWeb is that preferences can be set on a per-site basis, so you don’t have to turn off functionality for all of your web browsing just to accommodate jerks with technology at some sites. [Thanks to Mike Hostetler for pointing out how advanced OmniWeb’s treatment of preferences is]
  • Internet Explorer: The No Flash! tool allows you to easily turn off Flash, Script, and GIF animations. Turning off Java in IE is somewhat more involved but Microsoft provides directions at their support site.
Original post by Jeremy Sydik at http://jeremy.sydik.com/2008/04/10/first-do-no-harm

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.

Topics:

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}