Posted Nov 29, 2012 10:15 UTC (Thu) by hummassa (subscriber, #307)
[Link]
That is GOOD. Naysaying is not weaponized enough as it is. And yes, for many reasons, UI changes *are* security issues /per se/, especially if the user gets irritated or confused. The process of security is dependent on the usability of the tools, and usability *is* dependent on some interface conservadorism in 99% of the cases, the other 1% being exactly /exceptio probat regulam in casibus non exceptis/ :-D...
Security implications for user interface changes?
Posted Nov 29, 2012 17:43 UTC (Thu) by mathstuf (subscriber, #69389)
[Link]
Why do security tools have the *worst* interfaces then? The nss and openssl command line tools use crazy abbreviations and acronyms without explanation and then the manpages approach uselessness via terseness.
Security implications for user interface changes?
Posted Nov 29, 2012 18:06 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
because the people writing them are too close to the problem. As a result, they write things that are obvious to them and so they don't see a need for more documentation.
It also hurts that in many cases, the problem is actually hard, and if you tried to explain when you would want to use each option, as opposed to the terse explanations that they have, it's a very slippery slope to having books on the subject (with significant disagreements between the books over what the 'right' way to do things is)
Security implications for user interface changes?
Posted Nov 29, 2012 18:21 UTC (Thu) by mathstuf (subscriber, #69389)
[Link]
I'm fine if they put "Beware: dissertations recommended" on some commands and options, but trying to find out what domain a certificate is for? If I hadn't remembered "x509" being so familiar, things would have taken a lot longer than they did (which was already too long, IMO). The certutil commands for inserting things into your nssdb are also crazy. AFAICT, you can't add the 'u' (a client-side certificate) flag to entries without actually using it as a client certificate. It's also sad when the easiest interface to your tool is the configuration pane of a browser (the Chromium family in this case).
Security implications for user interface changes?
Posted Dec 3, 2012 2:25 UTC (Mon) by giraffedata (subscriber, #1954)
[Link]
... it's a very slippery slope to having books on the subject
You didn't finish the thought. The problem with having books on the subject is that people don't have time to read books on the subject.
It's actually impossible to explain some things - the time it takes to explain it is more than a person has to listen.
Security implications for user interface changes?
Posted Nov 29, 2012 10:32 UTC (Thu) by epa (subscriber, #39769)
[Link]
From the outside it all looks rather perverse. The developers have started discussing an imagined security threat, rather than simply considering that it might be worth keeping the feature because users appreciate it. If they have considered that and still decided that the feature is to be dropped, there isn't anything more to discuss unless someone wants to pay for it.
When it was announced that Firefox 64-bit nightly builds on Windows would be discontinued, I stopped using them and dropped back to Waterfox (a third-party Win64 build) instead, which is usually a bit behind the latest upstream release. But I wouldn't expect the Firefox developers to take the slightest notice of that as some kind of threat to the Internet. They can just produce the best software and then it's up to everyone else whether to run it or not.
Security implications for user interface changes?
Posted Nov 29, 2012 12:26 UTC (Thu) by sorpigal (subscriber, #36106)
[Link]
Everyone knows that building complex software is about making things that are neat, not about serving the needs of users.
Or, if it's about serving the needs of users it's about serving the needs that we don't hear about from actual users, not the needs users go out of their way to express.
Or, if it's about serving the needs we hear about from actual users, it's important to focus in on one or two corner cases (like grandma) and not the vocal minority; you see, the ones who talk very little are representative of a much larger group who, we assume, have similar needs.
The ones who do not talk at all are such a huge group that their needs obviously trump the needs of the vocal minority and the not-very-vocal minority. The best part about the silent majority is that since they express no needs at all *any change whatsoever* that seems neat can be justified as a service to them, the most important group.
Security implications for user interface changes?
Posted Nov 29, 2012 15:03 UTC (Thu) by epa (subscriber, #39769)
[Link]
In the case of Firefox, statistics on web browser usage are collected by several sources (not least Google, who want to see whether the money they pay for search bar placement is well spent), so there exists a quantitative way to test how well the project is serving its audience.
In your analysis you forgot about one important audience: those who do not use the program at all yet. (When starting a new project everyone falls into this category, and even for Firefox the majority of the world's population does not use it.)
Security implications for user interface changes?
Posted Dec 2, 2012 10:04 UTC (Sun) by man_ls (subscriber, #15091)
[Link]
Statistics on browser usage are not exactly quality feedback. Consider this scenario: Firefox 85 comes out with 10 new end-user features, 5 new enterprise features and with a new advertising campaign. Usage goes down 0.1%. Who is to blame? What did they do wrong? Is the world moving on? Are there any features in the competition which Firefox did not implement? Did MS or Google come up with a (possibly dirty) strategy to steal users? In the absence of detailed feedback it is impossible to know.
Statistics are good only to check whether things go broadly according to plan or there is a need to dig deeper into why.