Sunday, January 25, 2009

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.

No comments: