Archive for the 'Web' Category

Me v Wordle: Redux

Wednesday 10th March 2010

After all those hours of effort trying to control Wordle’s opinion of me in the end the Dev8D organisers didn’t use the single-post URL I’d provided to create my Wordle badge – they used the whole blog feed. I didn’t mind though. The badges, which I’d expected to be of the lapel variety and therefore easily readable, were actually in a kind of laminate pass holder which hung from our necks almost down to waist level, rather too low to read comfortably. The colour scheme was very muted too – someone would really have peer at it quite close to in order to make out most of the words. And, had anyone done so, I wouldn’t have been unhappy with the words there anyway.

While this exercise was ultimately futile for its original purpose, I still found it interesting (otherwise I wouldn’t have spent so long on it!) to consider how I might represent myself in a few words, and then sculpting an article specifically to get that result out of Wordle, but making the article a real piece of prose about the very process of its own construction. As I said, I’m a fan of self-reference. But I wonder if this can also be considered, perhaps loosely, a kind of steganography. While it contains no encryption, the article has a deeper purpose which — had I not explicitly made it the subject of the article, but instead concealed it — could be entirely hidden from view. I suppose it’s a fairly basic cipher to encode hidden messages inside a larger article according to the word frequency… but Wordle does a bit more than that. I think that, in controlled circumstances, Wordle’s output can be made reproducible for a given input and set of parameters. In which case, it would be feasible to conceal messages in a way that could not be calculated from the text alone, that could not be reliably decoded without the additional knowledge of which website it needs to be pumped through, the precise configuration parameters to use, and what further processing is required on the result — say, the message could be in just the words that Wordle makes a particular colour in one of its fixed palettes, or that are given a certain orientation.

Indeed, as Wordle’s precise algorithm is secret due to patent issues, the precise layout for a given set of parameters might be rather unpredictable without actually trying it. That makes Wordle a kind of public-private key pair, the public key being the set of parameters fed into the engine, and the private key being the secret method by which Wordle transforms those parameters into a layout. This transformation is probably relatively feasible to work out by trial-and-error, and in any case the number of configuration permutations is sufficiently low that if necessary the results of all of them could be tested and mapped fairly easily, so it only offers a fairly low security cipher. But you gain added security from the fact that very existence of a hidden message is steganographically concealed within the larger article, and, perhaps even more so, from the surprising and obscure means chosen to conceal it!

Ok, so I’ve given the game away now. If you’ve been quietly hiding secret messages in Wordle tag clouds for ages… sorry. If not, don’t start now, they’ll be onto you. But, more generally, using innocent third-party web applications as a kind of cipher function might have potential. You’d have to ensure that the output from the website isn’t just the pure decoded message, otherwise the third party has it as well. Some sort of post-processing which requires pre-shared secret knowledge is key. This could include things like piping your message through multiple web applications, either serially or in parallel, with each contributing some small part of the overall message, which can only be merged into the whole by someone with an additional piece of knowledge of how that needs to be done.

These are just idle thought experiments… I don’t advise anyone to actually use this technique for anything really secret! There are several obvious weaknesses, although they can probably be ameliorated. However, I believe it’s worth considering novel means of passing around secrets. If quantum computers actually happen as the physicists predict, all current encryption technology may be rendered useless at a stroke, as it all relies on a computationally-unfeasible mathematical problem that, theoretically, quantum computers could make feasible to solve quickly. Quantum computers also themselves have the potential to offer novel encryption techniques, but at the moment, no-one really knows how these things are going to behave… and, for a while anyway, quantum computers will be the preserve of rich governments, corporations, and other organised well-funded criminal gangs… so us ordinary folk will be at a disadvantage. The survival of our networks might depend on us being a little bit cunning…

URL aesthetics

Tuesday 7th February 2006

Look at the state of this… the URL itself I mean, not the page it points to:
http://www.tbs-sct.gc.ca/rma/eppi-ibdrp/hrs-ceh/6/RMA-CGR_e.asp

Can you imagine trying to dictate this to someone over the phone, or read it out on the radio? Reckon you can memorise it? If you saw it in your history list would you remember what the page was about?

URLs should be:

  • designed for people, not computers and not filesystems;
  • as short as possible (maintaining hierarchy only as necessary);
  • as meaningful as possible — using words, dates, standard reference numbers, or whatever will make sense to your users, not a bunch of abbreviations;
  • single case, not a mixture of lower and upper case;
  • persistent (cool URIs don’t change), and therefore designed with persistence in mind. A URL is more likely to persist if it is sensible and economical in the first place!

URLs should not:

  • include implementation details (.asp) and language preferences (_e), both of which can be handled transparently by content negotiation;
  • use unnecessary punctuation. Some punctuation is ok, but four dashes scattered throughout the URL is too many.

Ideally, it should also always be possible to remove the trailing part of a path to obtain an index document for that level. If that’s not the case (which it isn’t for this one), it’s a probable sign that you have more levels of hierarchy than you actually need.

AJAX v Accessibility on Rails: Fallbacks

Monday 16th January 2006

I’ve tentatively placed a toe aboard the AJAX bandwagon, thanks largely to Rails which makes it possible, even painless, to achieve AJAX functionality without having to learn Javascript.1

While AJAX, done properly, can be a big win for Usability for those whose browsers support it, I am also concerned with issues of Accessibility, and indeed keeping things usable for those with non-AJAX browsers.

Standards-Schmandards have come up with some useful hints about how to make AJAX pages more accessible to screenreaders, such as providing an option to pop up an alert box instead of, or as well as, simply updating the page. This is good advice, but it’s only half the story. These methods don’t help those without Javascript at all, or with non-AJAX-aware browsers.

In this article I will detail one method to help ensure accessibility for such people, without compromising on AJAX spiffiness, and most importantly without causing much extra work for us poor developers. The example is in Rails, but may be of interest to those using other frameworks. (more…)

Quantum Imagination

Wednesday 21st December 2005

Imagine a creature, about the size of a football, which has long green fur, and several purple tentacles with a glowing red eye at the end of each.

You have never seen such a creature; you are never likely to see such a creature. But I bet you were able to imagine such a creature, and perhaps your mind also filled in additional details than the ones I described. Perhaps you added a mouth, teeth, perhaps the creature moved, the wind ruffled its fur. Maybe it had feet. Maybe it made a sound. Maybe you found that a whole environment sprung into existence around it.

Now try to imagine a sphere, a snooker ball say, which is spinning in one direction, and also, simultaneously, spinning in the opposite direction.

Again you have never seen this, but this time, you could not imagine it.

The simple difference is that the creature, however unlikely you are to ever encounter it in your day-to-day life, is possible. It is entirely feasible that this very creature exists somewhere in the universe. The ball spinning in opposing directions is impossible, by the very definition of “spin”.

Now, something amazing comes out of this seemingly futile exercise. Your mind is capable of imagining only what is possible. If something is possible, you can imagine it, just by someone describing it to you, even if it bears little or no resemblance to anything you have seen before — provided it can be described in terms that you understand. But if it is impossible, you cannot, no matter how well it is described.

Why?

(more…)

Mozilla Firefox tips

Monday 14th March 2005

For ages I’ve been wishing it were possible to highlight part of a webpage and just view the source for that part, rather than scouring the whole page’s source for the relevant section. Now I discover, to my annoyance and delight, that Firefox can do this… sort of…

If you hold down the CTRL key and left click on part of a web page, that section of the page will be highlighted. If you right click on the selection and choose ‘View selection source’, the source code for that part of the page will be displayed.

That comes from a tips & tricks article on the MozillaZine Forums, which is crammed full of useful snippets like this. Many of them have been sorted into this knowledge base article, but I didn’t see the above one in there.

It’s not quite accurate. ctrl-click actually selects a table cell, not any arbitrary block. So this limits its usefulness. But it’s helpful for sites that are still using masses of nested tables for layout.

The two extensions I cannot live without are Web Developer and Session Saver.

Ordering of dynamic pseudo-class blocks in stylesheet

Friday 4th March 2005

The best order for dynamic link pseudo-class blocks in your stylesheet is (from W3C):

a:link    { color: red }    /* unvisited links */
a:visited { color: blue }   /* visited links   */
a:hover   { color: yellow } /* user hovers     */
a:active  { color: lime }   /* active links    */

The order matters because these dynamic pseudo-classes are not mutually exclusive in CSS2 (some of them were in CSS1), and later rules override earlier ones if they clash. In the example above, if a:link were placed last, all links would be the same colour (red) irrespective of whether they are visited, active or hovered.

Actually this doesn’t only apply to links; in some browsers any element can have :hover, for example.