Monthly Archives: August 2012

My iFrame usability-gaffe (dommigheid met iFrames)

A couple of days ago I created a small survey to see what people consider sexism (a hot topic currently in the local press and online). For that purpose I embedded a Google Docs Form in an iFrame in a HTML-page on my own site. While following up on the results as they got posted, I noticed a significant amount of respondents were male and aged below 15. Weird, as I had expected that group to be somewhat absent from the results and as the next age-group, 15-20, was indeed barely present. What the heck was happening? My stupidity, that was what was happening!

A long time ago I wrote about problems with iFrames and (simple) solutions for some of those issues on this blog, and more specifically:

When a visitor clicks a link at the bottom of a long page inside an iframe and the target is a shorter page inside the same iframe, then he/she will see a blank page which is … well not very usable, no?

And that was exactly what was happening; after having filled in the first, long page of the Google Docs Form, respondents clicked on “Continue” and -depending on the screen resolution- all they saw was a “Submit”-button and not the questions (age, gender and optional e-mail) before that were hidden from view. How utterly stupid of me, especially as I created a small JavaScript thingie, frameMagic.js, to fix just that problem. I implemented frameMagic.js (and made a small change in there for it to work on iFrames without an id) so the number of male participants aged under 15 should drop considerably as. And I guess I’ll have to do some math to make the results less skewed.

(in Dutch: door een stomme technische fout van mij en mij alleen, is er een significant aantal antwoorden op de “Korte zomerjurkjes-seksisme-enquête” toegekend aan de categorie “man van jonger dan 15 jaar”. Het probleem is rechtgezet en ik zal de antwoorden op een correcte manier  herwegen om min of meer relevante dingen te kunnen zeggen over de resultaten.)

Quick hack: making Journalist slightly more responsive

I’ve been using the Journalist WordPress theme ever since I migrated to my self-hosted instance, away from back in 2007. The Journalist is a pretty basic theme, 2 columns and fixed width. The last version on dates from mid 2008, but the developer did work on support for threaded comments and sent me a beta-version (1.9.1) in January 2009 which I currently use. A couple of months later, after having been stalked by yours truly for info on further development, Lucian replied he was busy with other projects and that he could not do too much “free” work any more (which is completely understandable). Ever since, I’ve been making small changes left and right, fixing minor bugs and making small improvements.

But the problem with fixed width themes such as Journalist; they’re not responsive. Although responsive design is great and all, I didn’t really bother with it until I needed some responsiveness to be able to test upcoming changes to my own WordPress plugin. And that’s why I added the following in /wp-content/themes/journalist/style.css:

@media only screen and (max-width: 880px), only screen and (max-device-width: 880px) {
  #container, #content { width: 98%; }
  #sidebar { display: none; }
  #bubble { background: none; height: 32px; margin-top: -24px; position: static; }
  #bubble p { background: none; color: #000000; font-size: 14px; }

This is just a quick hack, making the main content div variable in width, hiding the sidebar and moving the tagline from the bubble on the right to the left, underneath the site title for all screens with a width of 880px or less.

Feel free to use and to provide improvements in the comments or via the contact-form! And Lucian, if you happen to read this: any chance anyone could resume work on the Journalist?

Content Security Policy; Great! or Wait?

A couple of days ago I had another look at Content Security Policy, a technology that allows a site to tell a browser resources are allowed to be loaded to protect against XSS and some other types of web application vulnerabilities. CSP was originally devised by the Firefoxians, but is in the process of being standardized by the W3C with support in Firefox, Chrome, Safari and even the upcoming Internet Explorer 10.

The functionality offered by CSP (blocking requests that are not allowed) is pretty close to what WP DoNotTrack tries to do, so I decided I’d try to integrate CSP in my plugin, based on the following assumptions:

  • CSP-mode will only work for WP DoNotTrack if it is configured to use a whitelist
  • As most WordPress+plugins installations are bound to have pages with at least inline JavaScript and/or style, I have to add “unsafe-inline” to allow those to continue to work (which indeed limits the level of protection against XSS-attacks)
  • Given that a lot (most?) WordPress installations implement WP Super Cache of W3 Total Cache, it will -at least in a first stage- only kick in if WP  DoNotTrack is configured to filter unconditionally
  • Ideally the JavaScript-based component of WP DoNotTrack would “see” that CSP was activated and would not perform those nifty JavaScript AOP trickery

The “proof of concept”-quality code I ended up adding to wp-donottrack.php was pretty simple:

function wp_donottrack_csp() {
 global $listmode;
 if ($listmode==="1") {
  $csp="default-src 'self' 'unsafe-inline'";

  if (is_array($whitelist)) {
   foreach ($whitelist as $white) {
    $csp.=" *.".$white;

  header("X-Content-Security-Policy: " . $csp); //FF & MSIE10
  header("Content-Security-Policy: ". $csp); //new standard
  header("X-WebKit-CSP: " . $csp); //chrome & safari

add_action('init', 'wp_donottrack_csp', 10, 0);

With this code on my testblog I started playing around in a couple of browsers. Based on that experience I found the following limitations:

So in this particular context (and specifically the absolute need for “unsafe-inline”), I’ve decided to hold off implementing CSP (I might implement iFrame sandboxing as support for that is coming with IE10 and will probably also land in Firefox 17). But if you have full control over a particular website or -application (meaning you can remove all inline JavaScript and CSS and all instances of evals in insourced JavaScript) and you want to harden your installation to stop cross-site scripting, you really should start thinking about implementing CSP (as Twitter seems to have done already)!