Trustedness in Ubiquity and Other Places

I have started to use Ubiquity and it is, of course, as amazing as people have been saying it is. And I see questions being raised about how one gets new commands and how one can trust sources for new commands. I hope that, as these questions get answered, the answers can apply to other areas of concern within Mozilla.

Almost two years ago, I was asking Window Snyder why the add-ons on AMO all had warnings from lack of certificates or authentication. It seemed that MoCo could not decide how to decide whether an add-on is "certifiably safe" or not. Perhaps there is a way to determine whether a command is "certifiably safe" or not. I have a feeling that certifying safety falls in a weird area between what the community around Mozilla can do and what the corporation feels that it should do. When MoCo takes off its nice and fuzzy gloves and puts on its "corporate" hat, what reason do they have for taking on this risk? These kinds of risks are notoriously hard to judge. Or rather, one can see when a problem is less likely to occur, but one can never guarantee there will never be a problem and one can never find a limit to how much damage might be caused. So, there is a clear benefit of moderate import and a slight risk but with no way to guess the cost. A corporation which has to show due diligence will probably not sign up for this risk.

I hope I am wrong. Perhaps this is a way to certify these. And maybe a "casual" certification will work. Sort of like saying, "it is not certified, but this add-on is up on AMO and we like the developer and you should like the developer too but we're not responsible for any problems and yadda, yadda, yadda...", and so on down into the fine print. And maybe this works well enough for everyone, except for dealing with the occasionally nasty security dialog.

But it also seems obvious that the more places one needs trusted content, or trusted sites, or trusted chrome, the more ways there are to stub one's toes. I guess we'll see.

Amusing iPhone Sound Volume Interface

I waited long enough to be almost the last multicellular organism on the planet that did not have an iPhone. Well, we share our phone plan with my wife's parents and my father-in-law was hot for an iPhone and so here we are.

Some of the interface ideas in it are amazing. Then some are, well, something else.

Everybody has seen the thing where you turn the iPhone on its side and the app that is running rotates. I was looking at the calculator in portrait mode and I was just, literally, seconds away from pointing out I would need some scientific calculator stuff and then turned in sideways and there it is. Very cool.

But the interface for setting the sound volume has a strangeness. For one thing, you do not hear a tone that increases in volume as you increase the volume. You just have to eye-ball the volume indicator. Really. There is no auditory feedback for changing the sound volume. It really boggles the mind.

Then you turn it sideways. The hardware does not change its behavior. So, picture this. In portrait mode you press the down side of the toggle and the sound goes down and a visual "volume progress bar" thing slides to the left. Push on the up toggle, the volume goes up and the "volume progress bar" thing slides to the right. So far, so good. But turn it sideways and you press on what is now the right side of the switch and in my "right-hand-is-right-ish" view, this should make the sound increase. But the volume decreases and the "volume progress bar" slides to the left. And if you press on the left hand side of the toggle, the volume increases and the sound goes up.

I cannot decide if it is my brain that is wrong or, is it possible they just thought it would be ok to respond backwards?