What's important after all? Reliability.

[Kai Engert]

What's important after all? Reliability.

Mozilla is a symbol and a guarantee for independence when using the Web.

I read the Mozilla mission as a desire to be the safe harbour, because
it works, because it's available for everyone, because it's free and open.

However, being a safe harbour implies reliability. After the recent
events, such as the discussion around Jono's blog etc., I believe we
should feel warned. We should accept that it could mean that Mozilla
software is being perceived as less reliable than it used to be in the
past, and we should attempt to correct that.

Only if users can rely on Mozilla software to work correctly, be stable
and secure, not remove functionality, not break compatibility, only then
the broad majority of users will perceive Mozilla software as a viable
alternative to other software.

The Mozilla project and its contributors have a limited amount of
resources. In my opinion, those resources should be focused on the
above, and any new nice-to-have features should have a much lower
priority, or rather, only worked on if any other work concerning
reliability and security has already been done. In my opinion Mozilla
should focus on the boring but important work that assures reliability.

Recently it has been announced that Thunderbird will go into maintenance
mode. Maybe it would be good to do that for Firefox, too. Stop adding
new features until people are happy with the features we already have
started to implement.

Mozilla should focus on compatibility, reliability and security. New
features should only get worked on if they are required in order to
improve these priority areas. That's my opinion.

I'm not a visionary. I just want my browser (and e-mail client) to work
right in every aspect, and to protect my security as good as possible.
And I believe this was the argument that drove most users to using
Firefox in the past. These were certainly my arguments in the past
whenever I tried to motivate people to use Firefox instead of something
else. I propose to make it the highest priority that our users will
continue to associate these attributes with Mozilla software in the future.

Being the most widely used browser in the world is irrelevant. It's
important that Mozilla software will continue to be available and
compatible when people need it, now and in the future. Other browser
makers must always be aware that they will never be able to abuse a
market dominance, because Mozilla will always be waiting for users to
come back with our arms wide open to make them feel home in the web.

"It might not have the newest feature yet, but at least it works right
and protects me", that would be my preferred description of Firefox and
other Mozilla software.

Regards
Kai

--
Sending me encrypted e-mail:
- get my S/MIME cert from https://kuix.de/smime-keyserver/
- get my GPG/PGP key from http://pgp.uni-mainz.de/

[David E. Ross]

It seems that you are saying: "Focus on fixing discrepancies and
difficiencies before implementing new features." With one exception, I
thoroughly agree; and from comments by end-users in the support
newsgroups, I believe most users would also agree.

The one exception is that Mozilla products have long been touted as
standards-compliant. Thus, new features required to address HTML5,
CSS3, IPv6, etc should also be implemented.

What is not needed are constant changes to the user interface. Jakob
Nielsen -- a professional Web usability guru -- asserts that frequent
changes to a user interface drives away users.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[Kyle Huey]

On Mon, Jul 16, 2012 at 8:01 AM, David E. Ross <nob...@nowhere.invalid>wrote:

> The one exception is that Mozilla products have long been touted as
> standards-compliant. Thus, new features required to address HTML5,
> CSS3, IPv6, etc should also be implemented.
>

You do realize that most of the engineering effort that goes into new
features is for compliance with HTML5, CSS3, and other new/emerging web
specs, right?

- Kyle

[Kyle Huey]

On Mon, Jul 16, 2012 at 4:29 AM, Kai Engert <ka...@kuix.de> wrote:

> "It might not have the newest feature yet, but at least it works right
> and protects me", that would be my preferred description of Firefox and
> other Mozilla software.
>

Not implementing new features (at least in a timely manner) significantly
diminishes the influence we have on the future of the web. We don't want
to become a new IE.

- Kyle

[Boris Zbarsky]

On 7/16/12 7:29 AM, Kai Engert wrote:
> Mozilla should focus on compatibility, reliability and security. New
> features should only get worked on if they are required in order to
> improve these priority areas. That's my opinion.

Kai, I agree that these are important priority areas.

The fact of the matter is, increasing "compatibility" in anything other
than the incredibly short term means staying current with various web
standards being developed. The alternative, has been tried in the past,
and it was called IE6.

In addition to that, though, we should also work on letting users do
what they want to do with their browser. Obviously the things you list
are prerequisites for that, but they're not sufficient.

> I just want my browser (and e-mail client) to work
> right in every aspect

Yep. We all do.

And while the definition of "work right" for mail clients is pretty
static at the moment, the meaning of "work right" for a browser is
changing rapidly....

So you're right that we want users to perceive Firefox as compatible,
reliable, and secure. I think we _also_ want users to perceive Firefox
as the browser that does what they want.

> It's important that Mozilla software will continue to be available and
> compatible when people need it, now and in the future. Other browser
> makers must always be aware that they will never be able to abuse a
> market dominance

The simplest way to ensure that is to make sure our market share never
drops too low.

If it does, then I think it would be quite easy to abuse market
dominance, especially in this brand new world where you can't actually
switch to a different browser without getting new hardware.

> "It might not have the newest feature yet, but at least it works right
> and protects me", that would be my preferred description of Firefox and
> other Mozilla software.

I think for most people "doesn't have feature X that I rely on" and
"works right" are mutually incompatible.

-Boris

[Kai Engert]

On 16.07.2012 17:12, Kyle Huey wrote:
> On Mon, Jul 16, 2012 at 4:29 AM, Kai Engert <ka...@kuix.de> wrote:
>

>> "It might not have the newest feature yet, but at least it works right
>> and protects me", that would be my preferred description of Firefox and
>> other Mozilla software.
>>

> Not implementing new features (at least in a timely manner) significantly
> diminishes the influence we have on the future of the web.

Sorry, but I don't contribute to the Mozilla project in the hope that I
might potentially be able to influence someone in the future.

I want to give them something that works for them, today, based on an
open environment.

Being able to influence the future shouldn't be an argument when making
decisions about priorities.

If people stop using your software because they cannot rely on it, or
because it causes too much trouble, you've lost your influence anyway.

> We don't want to become a new IE.

Cannot happen, Mozilla isn't proprietary.

Taking breaks or slowing down for quality purposes doesn't have to mean
stagnation.

Kai

[David E. Ross]

I would suspect so. However, what end-users most readily see are user
interface changes.

[Kai Engert]

On 16.07.2012 17:58, Boris Zbarsky wrote:
> The fact of the matter is, increasing "compatibility" in anything
> other than the incredibly short term means staying current with
> various web standards being developed. The alternative, has been
> tried in the past, and it was called IE6.
>

> ...

>
> I think for most people "doesn't have feature X that I rely on" and
> "works right" are mutually incompatible.

Let's separately look at (a) web content and communication protocols
and (b) application user interface compatibility including extension hooks

There's no need for quick evolution of (b). If I understand correctly,
users and add-on would prefer slower innovation cycles.
Removing toolbar buttons isn't necessary for web compatibility.
Adding things is fine, removing things hurts people's expectations.

I agree that it's more important to evolve in area (a).

If it's widely agreed that a new feature improves security of protocols
that everyone relies on, I'd give it a high priority.

However, if it's just a nice-to-have feature, a new way to render
information, we shouldn't try to make the few early adopters happy as
early as possible.

Add it after it's been shown to make sense and we have resources
available to get it done. Only work on it after we're done with the
higher priorites.

> In addition to that, though, we should also work on letting users do
> what they want to do with their browser. Obviously the things you
> list are prerequisites for that, but they're not sufficient.
>

> ...
>
> So you're right that we want users to perceive Firefox as compatible,
> reliable, and secure. I think we _also_ want users to perceive
> Firefox as the browser that does what they want.

I agree, but IMHO fixing bugs in the prerequisites area should always
have an higher priority.
Work on new nice-to-have features should be postponed if engineering
resources are needed to help with bugs in the prerequisites area.
A delay won't hurt.

> ... the meaning of "work right" for a browser is changing rapidly....

I think you're referring to evolution and support for new standards.

I'm talking about backwards compatibility. Yes, we cannot guarantee
backwards compatibility forever. I agree we cannot guarantee that the
latest browser still works with every 10 years old website that uses
lots of bad hacks.

But the less frequently we require users to use a new rendering engine
with new features, the less frequently will we get complaints about a
rendering engine with new bugs.

That's a different discussion, but I hope we'll eventually switch back
to a less frequent release cycle, too. I like ESR. I installed ESR on my
parents' computer. I personally would like to see the ESR schedule for
the primary distribution to our users, and use the current Firefox rapid
release cycle as the optional channel for early adopters.

We could even have a choice on the download page. Are you conservative
(ESR) or do you want to get new features as soon as possible (rapid
release)?

> The simplest way to ensure that is to make sure our market share never
> drops too low.

Maybe, but we should carefully weigh which strategies are reasonable to
strive for this goal. IMHO we shouldn't use the strategy of immediately
implementing each and every new feature that someone else plans to do,
not if it happens at the cost of reliability or security. Given the
amount of open bugs and our limited resources, I'd prefer a much more
conservative selection which few features should get attention.

> If it does, then I think it would be quite easy to abuse market
> dominance, especially in this brand new world where you can't actually
> switch to a different browser without getting new hardware.

It's Mozilla's mission to give users a choice. I don't mind if
proprietary browsers get more market share than Mozilla browsers. The
proprieraty browsers might (temporarily) try to be nice to their users
in order to gain market share. But users will drop the proprietary
browsers if they get too annoying, be it for forced obtrusive ads or
concerns about security or privacy or something else.

If Mozilla software remains usable, secure and functioning correctly
with the core web feature set, then people will come back to us, if ever
necessary. And if we're a very reliable, but less quickly innovating
browser, I'd assume that web developers would still ensure their site is
compatible.

But if Mozilla software were less secure than other browsers or were
working unreliably, then users might have to decide they have no choice
but to accept the annoyances of proprietary browsers.

On devices where the vendor controls both hardware and software, and
makes it difficult for other browsers to function, there's nothing we
can do about it anyway. But users still have the choice whether or not
they use such closed platforms.

GNU/Linux has been a success and is growing in various flavors. Mozilla
is free and open software, and it will always be possible to make it
work on a free and open operating system.

Even if the market share of Mozilla software dropped further, we
shouldn't be worried. Given that Linux is prospering and growing and we
have Mozilla software available on it, users will have the choice to
leave the proprietary platforms and switch to something that still gives
them control, if ever necessary.

Regards
Kai

[Boris Zbarsky]

On 7/16/12 2:46 PM, Kai Engert wrote:
> Let's separately look at (a) web content and communication protocols
> and (b) application user interface compatibility including extension hooks
>
> There's no need for quick evolution of (b)

Well, with some exceptions. For example, the extent to which (b) relies
on (a) means it gets the same evolution speed as (a). And to the extent
that (b) is holding (a) back we need to evolve (b) to make progress on (a).

> Adding things is fine, removing things hurts people's expectations.

Adding toolbar buttons is bad for extensions compat too, for what it's
worth.

> I agree, but IMHO fixing bugs in the prerequisites area should always
> have an higher priority.

I can't agree with that as a blanket statement, because not all bugs are
created equal.

Obviously fixing _important_ bugs in security/compat/reliability is
pretty high on the priority list.

But there are other things (e.g. basic user interaction performance)
that are more important than some compatibility bugs, in my opinion.

> Work on new nice-to-have features should be postponed if engineering
> resources are needed to help with bugs in the prerequisites area.

Please define "nice-to-have".

> A delay won't hurt.

It sure can.

If we're delaying work to significantly improve user-perceived
performance because it might break some small number of long-tail
websites, that can _definitely_ hurt. And in particular, it hurts the
majority of our users.

>> ... the meaning of "work right" for a browser is changing rapidly....
>
> I think you're referring to evolution and support for new standards.

Yes.

> I'm talking about backwards compatibility.

Every single new DOM property we add is a potential incompatibility. We
try to avoid doing things that will obviously break sites, of course,
but it's trivial to create a site that will break on _any_ addition to
the DOM. Just as an example.

> I agree we cannot guarantee that the
> latest browser still works with every 10 years old website that uses
> lots of bad hacks.

OK, good. ;)

> But the less frequently we require users to use a new rendering engine
> with new features, the less frequently will we get complaints about a
> rendering engine with new bugs.

Well, sure, but we'll get a larger number of complaints at those less
frequent intervals. Is the actual user pain less, or are we just
hearing about it less often and not paying attention to the volume when
we do hear?

> That's a different discussion

Indeed. I'd really like to stick to the topic, because I think sorting
through the prioritization is important and I'd like to avoid dragging
in the release cycle stuff.

> Maybe, but we should carefully weigh which strategies are reasonable to
> strive for this goal. IMHO we shouldn't use the strategy of immediately
> implementing each and every new feature that someone else plans to do,
> not if it happens at the cost of reliability or security.

The tradeoff is that if we are not implementing some new specification
then we have no voice in the standardization process. What typically
happens then is that whatever the first mover implemented gets
standardized, and when we _do_ get to implementing it out of necessity
we have to rearchitect existing things because the specification is
designed around whatever was easiest to do in some other architecture.

>> If it does, then I think it would be quite easy to abuse market
>> dominance, especially in this brand new world where you can't actually
>> switch to a different browser without getting new hardware.
>
> It's Mozilla's mission to give users a choice. I don't mind if
> proprietary browsers get more market share than Mozilla browsers. The
> proprieraty browsers might (temporarily) try to be nice to their users
> in order to gain market share. But users will drop the proprietary
> browsers if they get too annoying, be it for forced obtrusive ads or
> concerns about security or privacy or something else.

How does an iPhone user drop their proprietary browser?

How does a user switch to Mozilla (as in, how do they have a choice) if
all websites sniff the UA string and lock out any browser that's not on
a whitelist, with Mozilla not on the whitelist? This isn't even a
hypothetical question; this could happen _really_ easily.

> If Mozilla software remains usable, secure and functioning correctly
> with the core web feature set

Which is a huge "if" unless we actually work on said core web feature
set. Which is what we're mostly doing.

> Even if the market share of Mozilla software dropped further, we
> shouldn't be worried.

At what point should we be worried? 1%? 0.01%? 600 users?

-Boris

[Wes Garland]

On 16 July 2012 14:46, Kai Engert <ka...@kuix.de> wrote:

> There's no need for quick evolution of (b). If I understand correctly,
> users and add-on would prefer slower innovation cycles.
>

This is possibly true for add-on vendors, but for users, I think it's a
load of crap. Most users have no clue what kind of innovation happens
under the hood, but they would certainly miss them if they suddenly went
back to Firefox 3.6. The only innovation users have real input on, IMHO,
is the UI.

> However, if it's just a nice-to-have feature, a new way to render
> information, we shouldn't try to make the few early adopters happy as
> early as possible.
>
> Add it after it's been shown to make sense and we have resources
> available to get it done. Only work on it after we're done with the
> higher priorites.
>

I don't believe Firefox's mandate includes producing a behind-the-curve,
catch-up-with-the-Jones browser. I believe implementing bleeding-edge specs
is squarely within the goals of The Mission. We have to help lead the way
toward improving the web. We cannot afford to leave this to Google and
Microsoft. The Web is too important.

>From my POV as an app developer, the faster the innovation the better,
provided QA keeps up (and it is great right now). I love all the new speed
and functionality we've gotten over the last year and a half or so. I
couldn't care less about what colour my back button is.

Work on new nice-to-have features should be postponed if engineering
> resources are needed to help with bugs in the prerequisites area.

> A delay won't hurt.
>

I don't know what you're specifically talking about here, but I believe you
are making claims based upon a false premise. That premise being that
innovation in one area must starve other areas for resources. That is
provable untrue.

Given the
> amount of open bugs and our limited resources, I'd prefer a much more
> conservative selection which few features should get attention.
>

Number of open bugs is a completely useless metric when talking about
software quality. It's talk like this that gives people ideas about closing
inactive bugs en masse.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Philipp von Weitershausen]

On Mon, Jul 16, 2012 at 12:40 PM, Wes Garland <w...@page.ca> wrote:
> I don't believe Firefox's mandate includes producing a behind-the-curve,
> catch-up-with-the-Jones browser. I believe implementing bleeding-edge specs
> is squarely within the goals of The Mission. We have to help lead the way
> toward improving the web. We cannot afford to leave this to Google and
> Microsoft. The Web is too important.

This.

[Nicholas Nethercote]

On Mon, Jul 16, 2012 at 4:29 AM, Kai Engert <ka...@kuix.de> wrote:

> What's important after all? Reliability.

This is a motherhood statement
(http://en.wiktionary.org/wiki/motherhood_statement). And the rest of
your post is full of similar statements.

This kind of discussion never goes anywhere without specifics. I
suspect you think that Mozilla shouldn't be doing Boot2Gecko, or
something like that, but you haven't said anything nearly that
specific. Until you do, this discussion is doomed to go around in
vague circles.

Nick

[Henri Sivonen]

On Mon, Jul 16, 2012 at 9:46 PM, Kai Engert <ka...@kuix.de> wrote:
> Let's separately look at (a) web content and communication protocols
> and (b) application user interface compatibility including extension hooks
>

> There's no need for quick evolution of (b).

If our only extension API was a high-level API designed to be an
extension API that can be maintained as stable, it might be possible
to evolve the Web engine implementation while retaining the
compatibility for extension hooks. But that's not the only kind of
extension API we have. The pre-JetPack extension API is basically
having no extension API but instead letting extensions use internal
interfaces. The traditional Firefox extension model means that either
the internal implementation details cannot change (i.e. no standards
correctness or performance rearchitecting) or extensions break with
host app updates that change internal implementation details.

This makes *guaranteed* extension stability in the traditional Firefox
extension model pretty fundamentally incompatible with the current
release model. (And I don't mean breakage caused by metadata that
declares compatibility with particular versions; that problem has been
addressed. Furthermore, the solution to the metadata problem relies on
the observation that actual breakage is nowhere near as bad as the
lack of a *guarantee* of non-breakage would seem to imply.)

Chrome, Safari and Opera address this problem by providing a stable
extension JS API that's designed to be a stable extension API instead
of letting extension spoke at whatever internals. JetPack is on track
to becoming that sort of API for Firefox, but it's crucial that the
stable JetPack API be bundled in Firefox such that it's
behind-the-scenes implementation changes as Firefox's implementation
details change as opposed to requiring "repacks" on the extension
side. (Evening Chrome, Safari and Opera, extensions also rely on APIs
that are part of the Web Platform, so Web Platform changes could break
extensions in addition to breaking Web sites, but extension breakage
is more likely to the extent Web sites are written to work on multiple
engines but extensions are written for a particular engine. )

Another (complementary to JetPack) way to address this problem would
be to introduce stable C-linkage APIs for the sort of tasks that
antivirus packages insist on doing and that they currently do in less
stable ways. As far as I know, no such C-linkage APIs are being worked
worked on, and the precedent in Windows itself isn't encouraging
(Windows has an API for requesting that antivirus software scan a
downloaded file, but if the antivirus software scans all disk writes,
using the API means the file ending up being scanned twice--making
things worse when the API is used).

Of course, for new APIs to make a difference, the installed base of
extensions needs to use the new APIs.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Philip Chee]

On Mon, 16 Jul 2012 15:14:06 -0400, Boris Zbarsky wrote:
> On 7/16/12 2:46 PM, Kai Engert wrote:

>> Adding things is fine, removing things hurts people's expectations.
>
> Adding toolbar buttons is bad for extensions compat too, for what it's
> worth.

Do you have an example of this? I am an extension developer. I have been
active on multiple extension forums (irc, mozillazine, news.mozilla.org)
since 2004. I have never come across a situation where Firefox adding a
toolbar button broke any extensions at all. Adding a new toolbar button
(functionality) might make an existent addon redundant of course.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Kai Engert]

I believe the Web depends on Web Security (SSL/TLS etc.) to be reliable,
but we get too little help.

I would appreciate if Mozilla made it a higher priority to fix related
bugs and to improve related functionality.

I think it should be a top priority to prepare for the next round of
hacker attacks (like DigiNotar) targetting today's trust system that Web
Security relies on.

I don't know the full list of items being worked on, but in my opinion
many things being worked on, work unreleated to
security/stability/correctness, are less important than improvements to
Web Security. I would prefer if several C programmers switched their
priority to help improve Web Security, until we are in better shape.

Examples:
We still don't have a dynamic push system (independent of software
updates) to quickly revoke trust from compromised Certificate Authorities.
We still use an outdated engine for validating certificates and don't
get sufficient help to get the new engine into a deployable state.
Support for dynamic revocation checking by the browser is still
insufficient (new OCSP features, CRL downloading).

We need more manpower and attention to core Web Security.

Regards
Kai

[Boris Zbarsky]

On 7/17/12 5:55 AM, Philip Chee wrote:
> On Mon, 16 Jul 2012 15:14:06 -0400, Boris Zbarsky wrote:
>> On 7/16/12 2:46 PM, Kai Engert wrote:
>
>>> Adding things is fine, removing things hurts people's expectations.
>>
>> Adding toolbar buttons is bad for extensions compat too, for what it's
>> worth.
>
> Do you have an example of this?

I don't have a link offhand, but I seem to recall a bug where an
extension was relying on toolbar button ordering and using childNodes[n]
stuff. Yes, that was a bad idea, but it's not the first bad idea in
extension code....

-Boris

[Boris Zbarsky]

On 7/17/12 7:07 AM, Kai Engert wrote:
> We still don't have a dynamic push system (independent of software
> updates) to quickly revoke trust from compromised Certificate Authorities.
> We still use an outdated engine for validating certificates and don't
> get sufficient help to get the new engine into a deployable state.
> Support for dynamic revocation checking by the browser is still
> insufficient (new OCSP features, CRL downloading).

Thank you. These are clear, actionable suggestions on how we should
reprioritize....

Is anyone other than Brian and you working on any of this? I assume
not, right?

-Boris

[Gervase Markham]

On 17/07/12 17:43, Boris Zbarsky wrote:
> Thank you. These are clear, actionable suggestions on how we should
> reprioritize....
>
> Is anyone other than Brian and you working on any of this? I assume
> not, right?

https://wiki.mozilla.org/NSS:BurnDownList is Kathleen Wilson's page for
attempting to track and prioritize NSS and SSL improvements.

Part of the issue is that, in some cases (e.g. our approach to
revocation) there is not consensus on the best way forward. There is an
NSS team meeting in a few weeks to try and sort some of this out:
https://wiki.mozilla.org/NSS:FaceToFace2012

The NSS team is distributed across several companies, including Red Hat
and Google; of course, we can't always rely on their priorities aligning
with ours.

It's certain that we could do with more help here. Mozilla is always
looking out for smart people to become part of the project; if you like
a challenge and hack in C, NSS would be a good place to contribute. We
also have two open positions in this area:

http://careers.mozilla.org/en-US/position/oZWpWfw0 (security)
http://careers.mozilla.org/en-US/position/oMxuWfwt (privacy)

Gerv