W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: "vastly increases reverse-engineering costs" and version proposal

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 02 Jan 2010 21:05:27 -0800
Cc: Larry Masinter <masinter@adobe.com>, "public-html@w3.org" <public-html@w3.org>
Message-id: <8E20A58D-1433-4F73-86E3-B4F0AA7B044C@apple.com>
To: Adam Barth <w3c@adambarth.com>

On Jan 2, 2010, at 6:09 PM, Adam Barth wrote:

> On Sat, Jan 2, 2010 at 1:45 PM, Larry Masinter <masinter@adobe.com>  
> wrote:
>> However, in the case of HTML, it seems that the
>> "reverse-engineering costs" is mainly used as a reference
>> to the cost of determining what popular software (IE) did,
>> because other HTML engines wanted to be compatible
>> with the market leader.
>
> Speaking from personal experience, I've found it necessary to reverse
> engineer behaviors of IE, Firefox, and Safari.  If you look through
> the archives, you'll see some of the results of that effort posted to
> this list.

During the initial and ongoing development of Safari, we've spent a  
great deal of time reverse-engineering IE for Windows, IE for Mac  
(completely different engine), Firefox and the Gecko-based  
predecessors of Firefox. We have also spent some amount of time  
reverse-engineering Opera, as they often have had to solve the same  
problem of "split the difference between Trident and Gecko in a way  
that maximizes compatibility".

>> I would claim that if there are market forces that
>> promote (a) (as happened at least in Browser Wars 1.0),
>> that little or nothing that is actually written in the
>> standard can matter.
>
> The current dynamics of the browser market appear to be that Firefox,
> Chrome, and Safari are incentivized to converge on a common behavior.
> The spec is a useful vehicle for negotiating and documenting that
> common behavior.  Opera is likely on the same convergence path, but I
> don't have as many personal contacts there, so it's hard for me to say
> for sure.

My observation is that Opera is increasingly converging on common  
behavior with Firefox, Safari and Chrome. Historically, they made more  
of an attempt to emulate nonstandard IE behaviors, but increasingly  
they are tracking the other way.

> IE is stuck in another equilibrium point where they appear
> to be required to support many non-standard APIs and behaviors.
> Whether they will eventually converge to the consensus behavior
> remains to be seen.
>
>> * What are the costs associated with reverse engineering?
>> When are those costs "vast"?
>
> Vast is of course relative to some scale.  As a rough estimate, it
> seems safe to say that browser vendors burn at least millions of
> dollars a year on reverse engineering.  I suspect this cost was even
> higher in the past.
>
>> Although there is some literature on the general costs
>> or processes of reverse engineering, this particular argument
>> seems to be addressed at the past cost of determining
>> Internet Explorer behavior.
>
> You seem to be assuming that everyone is reverse engineering IE.
> That's not really true.  The Chrome team has a specific reverse
> engineering protocol that goes something like this:
>
> 1) Observe that a web site doesn't work
> 2) Does the web site work in Safari?  If yes, then adopt the Safari  
> behavior.
> 3) Does the web site work in Firefox?  If yes, then adopt the Firefox
> behavior and try to convince Safari to do the same.
> 4) Does the web site work in IE?  If yes, then the story gets more
> complicated because matching IE often involves deviating from
> standards, etc.  Sometimes sites in this category go to evangelism,
> sometime they implement hacks, sometimes they convince Firefox and
> Safari to adopt the IE behavior.
>
> Notice that the protocol causes the web platform to converge on a
> consensus behavior.

We follow a similar process for Safari, except that we don't usually  
test if a site works in Chrome first, since that rarely comes up.

To expand further on step 4: many sites are developed with dual code  
paths - they are designed to work in either IE-like or Gecko-like  
browsers. This phenomenon actually predates the current generation of  
browsers - when we were first Starting Safari development, often the  
two code paths were IE and Netscape Classic. In any case, the reason  
this is important is that emulating a particular IE behavior to make  
one site work can cause a cascade of failures on other sites, as you  
end up either breaking the standards code path or falling into the IE  
code path. You may end up pulling on a thread where you have to  
emulate more and more proprietary IE features, until you get to some  
that just aren't practical to copy, like ActiveX or VBScript.

In fact, a big reason we have sought to converge with Firefox rather  
than IE is that the Gecko engine is easier to reverse-engineer. It's  
open source, it's much closer to what is written in standards, and its  
oddball behaviors tend to be less strange and quirky. We found this a  
compelling reason even though at the time we started Safari  
develpment, the browser market was over 90% IE and IE had clearly  
superior Web compatibility.

Regards,
Maciej
Received on Sunday, 3 January 2010 05:06:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC