UMO Bits N Bytes
Chris Crews has some issues with why Update is still static, and why we’re not unlocking DevCP at present. I realize that we’re sort of putting out our extension/theme authors in the process, and I would like to apologize for the ongoing delay and the frustrating aspects of that, for authors and users alike. However, as much as it would seem that we’re being overly cautious and possibly paranoid, I can’t say that I agree with his assessment of UMO as “safe” to re-enable. For a project whose refrain includes “security” over competition, we simply cannot compromise on the security of our web apps or our users.
Given the various holes we’ve found thus far, there’s no justification for any assumption that the rest of the code is safe. In fact, the only sane assumption is to assume that for every glaring issue, we have 3 or 4 lurking, waiting to be found. So as much as it royally sucks to do things this way, its the only real choice we have.
We have a good group of people, and an evolving plan to get update back to full function, and to move it forward as a high-volume web app. The best answer to “When will Update be running at 100%” is the same as we always gave for Firefox “When its ready.”
The “when it’s ready” answer for Firefox was replaced last October (IIRC) by a release date which was met. UMO may still not be ready now, but it was launched 3 months ago, and it’s been letting the side down since.
I hope the Foundation are devoting some resources to getting things going… there are no free rides
January 25th, 2005 at 2:42 pmSorry – read things in the wrong order. I should’ve read the post you were referring to first.
I can kind of see his point – it’s obviously not true that you can’t compromise on security, as the site was up and running with known security flaws for a couple of months.
I also don’t see much logic in shutting down to avoid potential future flaws. Applied to Firefox itself, would that not mean cancelling 1.1 if any flaws are found in Firefox 1.0?
There may be good reasons for this, but I’m not really getting a sense of what they are.
Surely a bigger risk in any case is the extensions themselves – they’re not (AIUI) audited, which is surely a bigger risk that someone slipping some dodgy HTML into a comment.
January 25th, 2005 at 3:10 pmWhy does open sourcing work for client-side software and not for web-apps? UMO could be in beta (or alpha) too, just:
January 25th, 2005 at 3:11 pm- make sure every visitors has to click a font-size:24pt “Yes, I accept the risks!” link before browsing UMO
- add a CVS module
- add a bugzilla component
- add a UMO category in which anyone can try to hack their entries.
The checkins to branch argue that you’re not simply addressing security (Feature additions (“site offline”) have been added to a supposedly stable branch. ), as does having a peer doing code reviews that is known to be very inexperienced with PHP (in fact, the past has shown mostly copy/paste PHP experience at best.).
“When its ready” is simply not justifiable with a site that’s already in production, you already have users depending on you, because the client does. If mozilla.org dropped the ball by not monitoring UMO more closely prior to now, and therefore has absolutely no clue how it works, then that needs to be stated. By leaving the status-quo, you’re also saying that Update 0.9 shouldn’t have been enabled either, which means why should anybody trust Mozilla Update if it’s been untrustable without anybody at mozilla.org noticing for 6+ months?
January 26th, 2005 at 8:32 am>The checkins to branch argue that you’re not simply
> addressing security (Feature additions (“site offline”)
> have been added to a supposedly stable branch. ), as
> does having a peer doing code reviews that is known
> to be very inexperienced with PHP (in fact, the past has
> shown mostly copy/paste PHP experience at best.).
Actually, we’ve frozen all CVS commits while we sort things out, and the review process will not remain as-is.
>“When its ready” is simply not justifiable with a site that’s
> already in production, you already have users depending on
> you, because the client does. If mozilla.org dropped the ball by
> not monitoring UMO more closely prior to now, and therefore
> has absolutely no clue how it works, then that needs to be
> stated. By leaving the status-quo, you’re also saying that
> Update 0.9 shouldn’t have been enabled either, which means
> why should anybody trust Mozilla Update if it’s been untrustable
> without anybody at mozilla.org noticing for 6+ months?
Our reputation for security is not simply “no holes here” its how aggressive and focused we are when a hole is found. The lack of oversight was unfortunate, but isn’t justification for continuing to expose ourselves to potential problems. That’s like saying “Wow, my wheels are pretty loose, but since I’ve been driving on this for months, I’m just going to take the chance.”
Its not ready. It wasn’t ready when it went live. Hindsight being 20/20, that was a mistake. We can’t change the past, we can only change the present.
January 26th, 2005 at 1:51 pm“Hindsight being 20/20, that was a mistake”
On what grounds was it a mistake only in hindsight? AIUI (not that I was involved), everyone knew it wasn’t ready at the time, but it was decided to launch anyway.
What is it that’s been seen with hindsight that wasn’t seen at the time? Or is it just different people’s views of the same thing?
The site itself says that it’s “undergoing a design update and rewrite based on user input”, which doesn’t sound like the whole story to say the least…
January 26th, 2005 at 4:40 pminvesting option…
…
January 24th, 2007 at 11:17 am