Christian Heilmann

Posts Tagged ‘security’

TTMMHTM: Evangelist Handbook, Billboard charts API, collaborative editing, IE6 bashing, pretty JSON, fancy fast food and terrible bugs.

Friday, July 24th, 2009

Things that made me happy this morning

TTMMHTM: iPhone GPS and Atari sourcecode, reboot Britain, augmented reality tube app, cougars and sun in San Francisco

Monday, July 6th, 2009

Things that made me happy this morning:

On password fields masking and Jakob Nielsen

Friday, June 26th, 2009

Jakob Nielsen just posted on alertbox that we should stop password masking (you know, showing asterisks or dots instead of showing the password while the user types it in.

His argument is the following:

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users’ shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn’t even protect fully against snoopers.
More importantly, there’s usually nobody looking over your shoulder when you log in to a website. It’s just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

Which makes me wonder when was the last time that Mr.Nielsen left his house to communicate with the real world. As a frequent traveller I am constantly seeing people logging into web sites in hotel lobbies (when they check in for their flight for example and enter their bonus miles account details), in Internet Cafes or when they use their laptop in a public space. While it is harder to spot the keyboard (especially with fast typers) there is no problem whatsover looking over their shoulder or – using my 10x optical zoom camera – even spot what they enter on the screen from across the room.

However, password masking is not a 100% security measure but anyone working in security promising you a 100% security is nobody you should trust anyways.

I do agree though that password masking can be very annoying on a mobile device, as is entering any form (my favourite bugbear is Opera Mini Uppercasing the first word I enter in any text field – no this is my user name, not a sentence).

As I am changing my passwords every few weeks I do get confused from time to time, too, which is why I have written myself a GreaseMonkey script that adds a link to any password field that allows me to toggle its display:

Password shower greasemonkey script by  you.

This, in my book, should be a standard feature of browsers (or a convention we should start to follow when we design forms) – not showing sensitive information as readable text on a screen just because we don’t think anyone would ever watch us.

Let’s also not forget that browsers deal with an input field with the type of password differently than with one that is text. For starters browsers do not collect previously entered information and offer them as options to autofill the field – something that would be terribly dangerous for passwords.

Is it getting harder and harder to show very easy examples?

Tuesday, April 7th, 2009

I am right now teaching a four day class of DOM and Ajax in Sunnyvale, California and also do some tech editing for Scriptin with JavaScript and Ajax by Charles Wyke-Smith and I find one thing that is pretty worrying: easy examples of web development practices are dangerous to show these days.

I’m talking about practices that make it easy to get quick results and give readers and attendees “I am getting this – this is easy” fuzzy warm feelings.

One very obvious example is form validation and re-rendering of a form using PHP_SELF and displaying user data using $_GET or $_POST. Unfiltered they are a free invitation for any XSS attack and will turn your server into a spam-hub or bot-net drone. Explaining countermeasures of XSS normally is out of scope for an example that only shows how a form would work that you enhance progressively.

The same applies to simply outdated ideas like onevent handlers. It is easy to show an example that uses a few onclick handlers, but explaining event handling really well takes a bit of time. Again, this is something that really does not fit in the scope of a DOM course.

I do however think that it is important to get it in there, as there is no such thing as knowing one technology in the web development stack and being able to use it. There’s a lot of overlap with other areas and in order to be a good developer and play well with others you need to be aware of your effects and areas of overlap with your colleagues’ skill-sets.

The other extreme I find myself doing is being too over-cautious. I went through the tough times of the first browser wars and got a deep-rooted mistrust towards anything some browser tells me is OK to do and use. However, I get the feeling that it doesn’t really matter any more if Internet Explorer has a problem with name vs. ID or whatever other shenanigans we have to be aware of when we build things from scratch.

I do get the distinct feeling that not building on top of a good client-side library is simply a waste of time these days. Libraries allow us to write code, not to work around bugs and wonder what other safety measure we have to put in.

That’s why I started asking people in my courses to use Firefox with Firebug and use a good text editor to code along. Today I managed to breeze through how to write HTML that is ready for internationalisation and works with assistive technology, over simple DOM access to the document and at the end writing a validation script for a form using generated DOM content. By concentrating on how things are meant to work instead of debugging random issues I managed to get the students to reach far into the matter in a day – even those who never touched JavaScript before.

Maybe it is time to get beginners accustomed to a market that builds on working solutions and benefits from browser abstraction via libraries than teaching developing from total scratch – bad browsers and bad people taking advantage of any technology to gain access or spam us seem to have made this way of working redundant.

TTMMHTM: Design definition, my little pony, uriplay and a hidden wine cellar full of win

Tuesday, March 31st, 2009

Things that made me happy this morning:

First up a definition of design:

Design is 70% dealing with people, 3% the idea, 2% selling the idea, 2% the brief, 2% being pig headed, 1% printing, 3% eye for detail, .6% invoices, 2% coffee, .7% tracking, .1% warm glow, .6% panic, 1% 4am, .6% staring, .2% checking, 1% letting go, .8% keeping hold, .7% estimates, .3% checking, .4% proofs, .1% colour, .9% understanding, .4% marketing, 1% checking, .8% beach ball, .5% mice, .3% keynotes, .4% persuasion, .2% bragging, .5% smiling, 2% knowing when to stop.
  • Cheer up the chatbot is an Eliza style experiment to simulate human intelligence. Or is it? Play with it a bit and you find there is a difference. Then click the ????
  • Vodaphone have a hero shot on their homepage that shows the same idea as my geek tattoo
  • The future of web apps 2009 UK tour schedule is out – I will be speaking about YQL in Cambridge
  • My Little Pony gets a hollywood makeover, I find the Princess Leia Pony especially disturbing.
  • eCSStender is a scripting solution by Aaron Gustafson that promises to fix CSS support and allow us to extend CSS. I will have a play with that
  • People are now using Twitter to share recipes who’d have thought you can do that in 140 characters?
  • URIPlay is an interesting idea to make playing, finding and annotating media on the web much easier
  • You can now make paper from wombat poo.
  • Malwarebytes has some good information how to keep your OS challenged computer clean – think conficker
  • I want one of those awesome wine cellars in my floor – and maybe turn it into a missile silo