Developers are users, too.

Jesper and Steve like to talk about “users just want to see the naked dancing pigs“.


What they mean is that when users have selected an action that they want to do, whether it’s looking at a purported picture of a naked celebrity, or getting rich by forwarding email to all of their friends, acquaintances and soon-to-be mortal enemies, those users are not going to let something like a security warning get in their way.


Different security professionals take different tacks on this – Bruce Schneier and Marcus Ranum seem to think that this means that you just can’t teach users. Jesper and I believe that this simply means you should try harder to educate users, and give them the information in a way they can understand and appreciate.


Jesper also likes to talk about NULL DACLs – not like an empty DACL, which rejects everyone’s attempt to access the protected resource, but a NULL DACL. If you set a NULL DACL on a file, it will allow everyone to have any access to the file.


Why on earth would you do that? Why wouldn’t you just want to use the default setting, which is appropriate for most uses?


I went through the documentation for SetNamedSecurityInfo, and found the reason:


pDacl

[in] Pointer to the new DACL for the object. The SecurityInfo parameter must include the DACL_SECURITY_INFORMATION flag. The caller must have WRITE_DAC access to the object or be the owner of the object. If you are not setting the DACL, this parameter can be NULL.

 So, if you’re reading that with the intention of not setting the DACL, you read “The SecurityInfo parameter must include the DACL_SECURITY_INFORMATION flag”, so you set that, and then you read “If you are not setting the DACL, this parameter can be NULL”, so you set pDacl to be NULL.


When you look at your watch, you are asking it a question, and it’s usually “how long until…” or “how long since…”, and not “what time is it?” As a result, if someone asks you the time after you’ve just looked at your watch, you will generally have to look again in order to answer that question.


The same is true of documentation – developers will ask the documentation a question. They won’t read it as if it were a novel (okay, so I do, but then I’m a little freaky). Given the question “how do I use SetNamedSecurityInfo on a file without changing the DACL”, the immediate answer appears to be “by calling SetNamedSecurityInfo(…DACL_SECURITY_INFORMATION…,…,NULL,…);” – exactly the behaviour that Jesper calls out in his presentation “Is that App really safe?


So, developers are users too – they have their own naked dancing pigs as a goal, and they read only the minimum necessary to get them there. Just as a secure developer needs to consider the behaviour a user will have, and design the security dialogs accordingly, so too a technical writer needs to consider the behaviour a developer will have, and place security warnings close to the description of risky parameters.

2 Responses to Developers are users, too.

  • Aaron says:

    There are a lot of things that developers are.. cattle, monkeys – these fit quite well I think. They – just – don’t – get – it. Why is it that the infrastructre or security engineer understands but the developer still doesn’t?

  • alunj says:

    The security engineer understands it, because it’s the security engineer’s job. I’d dispute that the infrastructure engineer, in general, understands it – I’ve certainly met many who don’t.
    As to why developers don’t get it, frequently it’s because they don’t have a reason to do so. They are given a list of features to craft into their code, and a deadline in which to do that. Security is not listed as a feature, and is unlikely to be tested for.
    Security must be a decision from the top down.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>