When dealing with the recent SSL fun, I met Marsh Ray, who found the problem in the first place. Marsh has a website, extendedsubset.com. I went looking for what an extended subset was one day and was a bit surprised to discover there was no such thing. So, after consulting with Marsh, I figured I should fix that and write down with some measure of rigour what an extended subset is.
Apparently, it is Facebook’s considered opinion that the way to avoid sharing data you don’t want shared is to not enter it
Barry Schnitt, a Facebook spokesman, said users could avoid revealing some information to non-friends by leaving gender and location fields blank.
I guess they’d agree, then, that the best option is to not use Facebook at all.
At the (always fun) New Security Paradigms Workshop this year, Cormac Herley presented “So Long, And No Thanks for the Externalities:
The Rational Rejection of Security Advice by Users”. In short, this paper looks at the cost to users of implementing security advice, versus the cost of failing to do so, and concludes that the advice we give is far too expensive.
I’ve been meaning to blog about it for a while, but today is a good day, because today I learnt that AOL are dropping support for SecurID. Why does AOL always get this stuff wrong? It’s supposed to be the users who ignore the security advice, not the provider who stops giving it! Also, you have got to love this quote
“We feel that users can have a better experience without sacrificing their security, and we’ve offered assistance in creating passwords that follow recognized protocols for complexity and measures to guard against online threats and hackers,” the company said in a statement.
Right, because the whole point of a one-time password device is to compensate for weak passwords. Not.
I was surprised to see
the encrypted (and thus anonymised) customer identity
in Richard Clayton’s analysis of Detica.
As we know from the AOL and Netflix fiascos, this is far from the truth. If you want anonymity, you also need unlinkability. But I’ve said that before.
Of late, I keep banging into the problem that people want systems to be “secure by default”: they don’t want to pester the user about security. They want the system to just do the right thing. The problem is, this just isn’t possible. One example I like to give is “rm -rf *“. Clearly this command is sometimes a very bad idea, and sometimes exactly what you want to do. If some piece of code I mistakenly trusted runs that command on my behalf, I might be very sad about it. Therefore, any system that wants to be “secure” has to somehow know that when I move to some directory and type rm -rf * I mean it, and when I run a piece of code I’m expecting to (say) edit some text, I don’t mean it, and it should not be allowed to do it.
How can the system discover this? Clearly it must be through some user action. The user must behave differently in some way in the two cases, so that the system can discover his intent. Therefore it is impossible to be “secure” without, in some way, consulting the user about his intent.
Obviously we can try to minimise the intrusiveness of the consultation – for example, this is the impetus behind the “designation is authorisation” paradigm that is so natural in capability systems. But we cannot make it go away.
ChromeOS provides us with some interesting examples. If we are going to have an operating system that only lets you use a browser, then clearly we’re going to have to let that browser do some things we would not normally expect a browser to do, like access the webcam or interact with your USB devices. There is simply no way to have those operations be secure by default – some web pages should have access to the camera and some should not, and there’s no way to tell which is which without involving the user.
Of course, we’ve traditionally allowed any program we install on a conventional operating system to access these things if it wants to, but the stupidity of that practice becomes very clear when we instead worry about what a web page can do. Why do we continue to grant these broad permissions to executables? Once more, it is largely because we don’t want to bother the user with these microdecisions (we saw what a great idea that was with Vista), but hopefully the increasing power of the web will force us to figure out good ways to discern intent without getting in the user’s way. It seems to me that one opportunity we have with web interfaces is that we can place the APIs at a higher level. This allows us to ask the user more meaningful questions than when the security boundary is at the system call level – and obviously by “ask questions” I include ways to discern the intent of the user without explicitly asking him, as is done, for example, in a file open dialog: clearly what is indicated is a single file which the user wants to open – modern browsers enforce that decision transparently, whereas modern operating systems just provide the file name as a hint to the executable – which can open any file it pleases.
Will the web teach us a better way? I don’t know, but one thing is clear: we can’t ignore these problems in the browser. “Stupid user shouldn’t have installed that evil executable” does not translate well into “stupid user shouldn’t have visited that evil web page”. We’re going to have to find some way to consult the user; we won’t be able to brush the problem under the table as we have done in operating systems.
One approach I am very interested in is to somehow use collective behaviour to make smarter default decisions. But more on that another time.
A final thought on the subject: what lunacy caused us to design systems where “cat foo” gets any more privilege than a read handle to foo plus write handles to stdout and stderr?
Powered by WordPress