ArchLinux Webmin Adventure in PogoPlug Land

Gah. Decided to install Webmin on my PogoPlug Mobile – which is running ArchLinuxArm v5, incidentally – and spent a good hour or so trying to figure out why I couldn’t access the interface…

The installation is quite simple,

  1. As root, “pacman -Sy webmin perl-net-ssleay” to install the packages
  2. Tell webmin what IPs to listen on, “nano /etc/webmin/miniserv.conf” and add a line at the end which reads “allow=″ (making webmin accessible from any IP from to, “allow=″ (if you want to allow access from any IP – not recommended), or some variation of those.
  3. Enable and Start the webmin service using systemctl – “systemctl enable webmin” then “systemctl start webmin”

With those steps completed, webmin will start during the normal boot process. To access the interface, point your web browser to https://(name or ip of your arch device):10000.

That’s where I encountered a problem. Any browser trying to access the interface would return an SSL protocol error. systemctl showed the service as active with no errors, so everything was nice and confusing. Even after a full reboot, the error persisted.


And now: the stupid solution.

Even though the service wasn’t started until AFTER I modified the configuration, and even though I REBOOTED the system, the Webmin service still needed to be stopped and restarted using systemctl. Don’t ask me why.

  1. As root, “systemctl stop webmin”.
  2. “systemctl start webmin”.

After that, everything worked just hunky dory. Blah.

Help! I’ve Tumbl’d!

We now enter a time of transition. I’m still using as my content curation platform, but I’ve decided to use Tumblr as the preferred publishing platform. What does this mean? Well, my feeds stay exactly as they are, but now all of their posts will appear together on my tumblog, Rabble rabble.

We’ll see how this works out…

And The Beat Goes On

steeeempyGreetings from thousands of miles beneath the Earth’s crust! I bring you blessings from the Lava Men and an update on my ongoing goings-on.

I’m really getting into the workflow for my content curation/blogging activities. I’m so pleased with it, in fact, that I’ve added two more streams:

Security Sausage Spectacular covers all things computer security related: products and services; concepts; exploits; authentication and identification; forensics; recovery; and, of course, hacking the Gibson.

Hardware Hackery Hootenanny provides information about making, modding, and messing with just about everything, but mostly electronics. I have the Maker bug and the “take everything apart” plague, so there will be a lot of teardowns and blah.

I do have a gripe with my current setup: it makes traffic analytics a pain. That’s not’s fault, really; I’m using the free account right now and my posts on other social networks link to the pages, who in turn link to the target article… Since can only tell me if someone clicked my link, and not if someone +1‘ed it or Liked it, I’m not seeing a full accounting of traffic or response. There’s a pro account option, costing around $13 US I think, that offers more perks; I’ll have to check and see what it offers. Ultimately I want to export my content to my own domain, and that’s an option for the pay accounts.

Keep watching the skies…

Update On Life, The Universe, and Everything

As you can see by the big jump between post dates, I haven’t been tending to my personal site. Apologies for that. My blogging and social media efforts have been spread across many separate platforms and without a plan for keeping them all synchronized; not a strategy I would recommend.

Recently, however, I was pointed to a content curation platform called (Thanks Anne-Marie!) This platform shifts the goal from authoring to curation; the task is not to write an article, but to share a link and (perhaps) add insight. The difference between writing a blog article and “scooping” with added commentary may not be obvious right away, but I can tell you that it is psychologically very different. I may even write an article describing the experience…

For now, though, I’ll invite you to view my UX-related topic on

UX Wins, Fails, and WTFs

No; iMessage isn’t intercept-proof.

*** (April 5, 2013) Update: TechDirt has a nice post about the whole affair. They summarize the counterarguments against the DEA memo and the original CNET story; and they line up quite nicely with mine :) They also include snippets from Julian Sanchez that offer more details and some possible motives for this whole exercise. Woot!

Argh. This story is traveling around the OMGosphere. A DEA office sent an internal notice among its agents and investigators. The notice was meant to warn them about the inability of pen registers and trap and trace devices to log Apple iMessages. The devices in question work like the call list on your phone; every call you make and every call you receive are logged. Extend that idea to include SMS messages (mobile texts) and you get the idea. It’s a form of wiretapping, but it doesn’t necessarily include logging the content of the communication.

The DEA uses these devices to record evidence of contact and communication between suspects. If they’re logging the phone calls made and received by gang members, the record of their intercommunication history could be used in court to show collusion in criminal activity, for example. RICO Act type of stuff.

Most of this equipment is installed and maintained by the phone companies to meet their legal disclosure requirements; when an agency comes knocking and asks for a full bidirectional record of calls for a certain phone number, the company is required to produce it.

The DEA warning was issued because agents discovered that the communication records they received weren’t always complete. The missing events were iMessages sent between two Apple devices; two iPhones, an iPhone and an iPad, two iToilets, etc.

So, that means that Apple iMessages have unbreakable encryption and are so amazingly great that EVEN THE DEA CAN’T TRACK THEM!  Right?



Internet, there are times when I want to hit you with an atomic hockey stick.

DEA foiled again!

Why are SMS messages logged while iMessages are not? A few reasons that have nothing do with super Apple encryption framice plates.

1. SMS messages are handled by the phone company network. The capability to transport text messages between mobile phones is built right into the specifications of the mobile phone networks. When you send a mobile text message, the message protocol includes source and destination headers telling the tower where the message originated and who it’s for. The logging equipment at the phone company can simply take those headers and add them to the record.

2. iMessage is not a standard adopted by the Mobile Phone Industry. Apple handles the routing of iMessages. When you send an iMessage from your iPhone — assuming you send it via mobile data and not Wifi — the cell tower treats it like a bunch of ordinary data packets; you might as well be uploading a photo or streaming some music. The packets will have source and destination headers of their own, but only to move the packets to an Apple server. The actual source and destination of the iMessage will be part of the data packets’ content, not as cleartext metadata on the outside of an SMS message.

3. Pen registers and traps aren’t psychic. There are people in the world who think that a virus scanner is capable of identifying any kind of virus. Surprisingly, the scanner is not an oracle; it’s just pattern matching to a list of known patterns. Have you ever been bothered by anti-virus software begging you to update your virus definitions? The software needs to have the latest set of known virus patterns (or signatures) so that it can detect known threats. If the definitions haven’t been updated in 2 years, there are lots of new virussessesesesssii the scanner will miss. The wiretaps can work in a similar fashion. They can sit in the network and look for SMS-shaped things, voice call-shaped things, etc. They have been told how to identify those events; they don’t get a tingling spidey-sense when an SMS is nearby. It’s entirely possible that the wiretap equipment could be given an update allowing it to identify the signature of an iMessage, if not the ability to decode it. Depending on the iMessage spec, messages may have a structure that is observable even when encrypted; messages may have a specific preamble; all packets heading to a set of identified iMessage servers could be flagged, etc.

4. It is almost certain that Apple IS maintaining a log of iMessages in order to comply with legal requirements. If so ordered, they would be required by law to produce activity logs for individual iMessage accounts. In this case, the DEA agents weren’t aware that the Apple-held data wouldn’t be logged by the phone company. This wasn’t a triumph of Apple tech against evil government privacy violations. This was a temporary ignorance of modern communications tech.

Thus endeth the lesson.


NUIA eyeCharm – More Than A Controller

Read an interesting post in one of my UX groups on LinkedIn. The author linked to the latest KickStarter darling: the NUIA eyeCharm.

NUIA eyeCharm

The eyeCharm product, if funded, will clip onto a Microsoft Kinect, converting it from a room-gazing motion tracker to a face-gazing eye tracker; no small feat. The resulting device will let you control your PC with your eyes, according to the campaign.

As usual, I wrote a full response where a short comment is customary. Ho hum.

Beware of the Oversell :) This looks like a great product for end-users and HCI researchers. From the research side, this could really reduce the costs and hassles associated with the old-school eye track rigs. I don’t know how this device’s sampling rate and resolution compares to the head-mounted rigs, but this is much less obtrusive to the research subject and less likely to add confounding variables to the results. If this device becomes a common tool for researchers, it could make data from different regions, different labs, different investigators, and different participants more readily comparable by reducing the amount of variability in the setup.

Eye Tracker in Space.

There’s much more to the end-user market than gaze-based control, however. This product has great potential for people with different physical abilities; people coping with ALS (Lou Gehrig’s Disease), for example, usually retain positive motor control over their eyes despite losing control of their limbs. In that case, users have fewer viable control options. The general user population would have less to gain by using this as a pure controller; eye movement is a more restrictive way to make unambiguous command signals… A mouse allows you to quickly select individual pixels, whereas gaze lets you focus on a larger high-probability target area that can be made more precise at the cost of increased gaze time or additional signals. I wouldn’t choose to type documents by eye tracker if I could use the keyboard in front of me.

It would make more sense to use this tracker in concert with other input devices, and also for non-control signalling. I hate zooming using the mousewheel; this tracker could detect a slight squinting of my eyes and cause the display to zoom-in. What about using gaze in a search interface to quickly determine which results are least interesting and using that information to improve follow-up searches without having to manually add other search terms?

There are oodles of augmentative possibilities, here. Thanks for the post!To do: link original thread

[Analysis] Minuum and the Quest for a Better On-Screen Keyboard

Update: It looks like they reached their $10000 funding goal within a day. I guess it’s time for my dancing cookie-dispensing robot idea to greet the world…

Everyone’s aflutter about Minuum, the on-screen keyboard concept looking for funding on Indiegogo.  The reactions fit into the usual classifications: this sucks, this is stupid, this is amazing, this is genius, this will change the world, this has no hope, try mine instead, you’re stupid, you’re stupid but I’m smart.  Very informative.

Continuing my quest to over-analyze everything as though it were a fine wine (or decent winegum), I provide you with my initial analysis of their initial promo material, initially initialed intricately in triplicate.

The Analysis

A writer of type.

They hate typewriters.  Or, or, they badmouth typewriters but like to show them in their fundraising video.

I know, it’s just a marketing video, it’s a commercial, it doesn’t represent their intellects nor their capabilities.  But it is annoying to hear the same half- or quarter-truth repeated by designers promoting their latest interface improvement.  The fractional truth in question: the influence of typewriters on modern interface design.

It’s almost obligatory for someone to mention typewriters when presenting a new interface design – especially anything keyboard-ish.  The argument goes something like this:

  • typewriters are over a century old
  • they had a big problem with keys getting stuck together
  • so they made the layout less-efficient and slowed everything down
  • modern devices aren’t anything like those old wing-dingers with their cogs and cranks
  • therefore it’s stupid or at least strange to make modern interface devices work in some way similar to those old contraptions
  • It may even be treason.

To which the proper response is “Yes, but…”

Yes: It’s true that the QWERTY layout isn’t optimal in terms of key location relative to letter frequency (the more common a letter is used in the English language, the closer it should be to a fingertip; the least commonly used letters should be farthest from the fingertip in that case, kinda sorta), and it’s true that modern keyboards and on-screen/virtual keyboards don’t have the mechanical issues that called for the use of QWERTY.

But: there are oodles of good reasons to use some typewriter-related concepts, there are many ways that on-screen keyboards are fundamentally inferior to typewriters, and it’s misleading to invoke the typewriter in comparison to your product without elaborating.

The QWERTY layout is really the only thing that an onscreen keyboard takes from the typewriter. The relative size and separation of the keys on the screen is to make targeted touches easier for the user – they can easily judge whether they’re between two keys, directly on one key, or somewhere else.  Physical keyboards and typewriters give us all sorts of tactile feedback that we don’t get on a screen, so it’s hard to touch type.  We just can’t feel precisely where our fingertip is on the virtual keyboard; there are no raised edges, no valleys between keys, no concave surface to invite a fingertip in for a rest.  This loss of feedback has a much larger impact on interface efficiency than is generally recognized, and I’ll be addressing it in a future article.

So the user gets no tactile feedback cues to guide the finger placement.  That’s a negative for any on-screen keyboard, but at least they all have it in common.  What, then, separates the good screenboards from the okay, the okay from the bad?

As always: it depends.  There are all sorts of objective and subjective ways to measure and compare screenboards, but which measures really matter?  Minuum‘s premise is that the default style of screenboard is usually something large with typewriter-like layout and separation between the keys, something that often covers half of the screen in a way that is distracting or otherwise negatively affects users, so it would be of benefit to have something that is functionally equivalent to a big screenboard but much smaller and less obstructive.  I agree that the large boards are obstructive and disrupt the flow of the experience, but I have some issues with their solution…

Even though the half-screen virtual keyboards eat up so much space, the user is able to trust that the keys will always be in the same locations on the screen, no matter what they do (except for switching to alt characters, number boards, etc.), and pressing a key always results in that position’s character being added to the input buffer.  The Minuum type of predictive entry starts as a sort of compressed QWERTY board which lets you choose a “first candidate” character.  A mini-board pops up above the first board and includes guesses about what character you were actually trying to hit; this can be characters to the immediate left and right, or the next letter of a word that it thinks you’re trying to spell.  It’s not obvious from the video whether a second selection is necessary if the first guess was correct; it could just wait for a delay and then push the guess onto the input buffer.

The point here is that flat QWERTY is the only constant part of the board; the virtual keys are lined up shoulder to shoulder in one long, thin row and it would be difficult to choose the desired key on the first click. The mini pop-up board’s contents are not static – they can change depending on tiny differences in finger position on the first pass and depending on predictions about the word or string you’re trying to type. This means that the only constant part of the board is hard to use on its own, and that you’ll have to do a two-stage selection using a board that isn’t static. 

I’m not saying that this won’t work or anything like that. I’m just saying that the way this operates goes against some UX principles at first glance. If the prediction algorithm works well, you’ll be saved a lot of extra key presses, and that’s good; after typing the first 5 letters of “antidisestablishmentarianism”, it lets you click on the finished word and saves you all that isestablishmentarianism.  If you’re typing a lot of non-dependent (non-predictable) text or strings, like alphanumeric passwords or LULZSPEAK TXTING LING0, you’ll have to more actively scan the mini-board for the correct character (since you won’t know what characters it will include) or use the “magnifier” feature (which is really a 2-stage board without the prediction feature).

In general, the more the user has to actively think about something, search through sets, make judgments, etc., the less optimal the interaction will be. If the board layout remains constant and the fingertips are moving to a fixed location each time for a specific key, the process becomes less and less a conscious task. Physical keyboards are great for this because the keys are always in the same absolute position and there are many little tactile and auditory clues and cues that feed back to the motor control, helping to make precise key presses without needing to visually track the finger’s position or do any conscious processing.

Now, I must stress that I don’t have any more information about Minuum than anyone else who has only seen the promo video, so I’m speculating about some of the details and about what manner of beast will be the final product  Feel free to point out any glaring mistakes in my reasoning or understanding.

I wish them good luck in fundraising and good luck in the market.

Fake Finger Attack! Run!

As someone who enjoys pointing out flaws and saying “I told you so” (I know, ‘people in glass houses’…), I thoroughly enjoyed news from Brazil that a fingerprint scanner was defeated by a…


The unfortunate lady, a doctor, worked at a hospital in São Paulo and was allegedly forced to cover up for lazy colleagues.  The hospital uses a fingerprint scanner (of unknown make and model, at this time) to track employee attendance; employees must scan a finger to clock-in and clock-out.  According to her lawyer, her colleagues preferred watching episodes of E.R. dubbed in Portuguese (that’s unconfirmed) to actually working in a hospital.  But how to get around this bulletproof security system?  Remove a finger, like a disgraced Yakuza member?  No, no. Put down the knife.

Let’s make a fake finger!

The current news releases don’t have much detail on the methodology, but it sounds like precise casts were taken of one finger for each lazy person, then used as a form for a finger replica.  I presume they would have to be very careful with the casting and forming to preserve the fingerprint, but a little intense focus on crafts can pay dividends of George Clooney episodes.


If only someone had warned them about fingerprint scanner vulnerabilities!  Oh, they did.  In fact, this sort of “replay attack” is a fundamental weakness of biometric security.  If someone steals your password, there are gazillions more that can replace it.  Your supply of replacement fingers is more limited.  Your supply of replacement eyes for retinal scanners is even smaller.

On that note, I’m off to form a new band called Fake Finger Attack.