Netscape Announces Bugs Bounty with release of Netscape Navigator 2.0 beta

Program harnesses power of the Internet to help Netscape refine Beta versions and ensure highest quality software.

Or at least this was the headline on the announcement from http://www.netscape.com

MOUNTAIN VIEW, Calif. (October 10, 1995) -- Netscape Communications Corporation (NASDAQ: NSCP) today introduced the "Netscape Bugs Bounty", a program that rewards users who help Netscape find and report "bugs" in the beta versions of its recently announced Netscape Navigator 2.0 software. The beta versions of the popular network navigation software are available today for downloading on the Internet for free evaluation.

I was immediately overjoyed when I read that first paragraph. The sheer delight and mention of rewards -- whether its frequent flyer points or just simple little gold stars and pats on the head -- motivates me to just go out and do it. Go out and do whatever the offeror needs, so I can collect my nice juicy reward. A win/win situation. But something about this announcement seemed a little "too" polished ... (maybe it's just seeing how the last "Netscape bug situation" was spinned, ... I don't know). But I decided to read on, wanting to find out how Netscape "rewards" users who bring them "bad news". It was a slow afternoon, and I had just finished listening to that odious Dominick Dunne on Larry King. What the hey, I thought. Let's read on and discover more about the Bounty from Netscape.

The contest begins with the beta versions of Netscape Navigator 2.0 -- available for Windows, Macintosh and X Window System operating environments -- that are on the Internet today. FULL RULES FOR THE CONTEST will be available on Netscape's home page at http://home.netscape.com. As the rules will explain in detail, users who are the first to report a particular bug will be rewarded with various prizes depending on the bug class: users reporting significant security bugs as judged by Netscape will collect a cash prize; users finding any security bugs will win Netscape merchandise; and users finding other serious bugs will be eligible to win a choice of items from the Netscape General Store.

Gee this was sounding, really really good. But that FULL RULES thing was highlighted on my screen (I was running Lynx 2.2 at the time ...), so I had a quick little old jump over to the FULL RULES. And with just a <cr> I was off ... and rule-reading before the big hunt ... The rules started off ...

We're in the process of building a series of new technologies, such as Java, into Netscape Navigator 2.0. Navigator 2.0 will usher in a new way to use computers and networks, as well as create new opportunities for people to build applications.

Wow, I said. New opportunites to build applications ;) New ways to use computers. New ways to use networks. All ushered in by Netscape. That all sounds really, really GOOD!! I was eager, and ready for all of this newness.

We're eager to make sure that our new product is as bug-free as possible. To that end, in addition to our internal testing, we're now offering prizes and bounties for certain types of bugs found in the beta versions of Navigator 2.0 starting with the beta versions listed at the bottom of the page.

Oh good. Finally a company that's interested in making a product as bug free as possible. And Prizes and Bounties!!! Joy!! Joy!! My adrenaline began to flood. Every neuron was piqued. I was ready to read on. This was slowly turning into as satisfying a hunt as any one I'd ever been on, even though we were only hunting for little old Bugs, and not big cats. None the less, it sounded like a fine afternoon of sport. Especially after Dominick Dunne.

This contest begins on October 11 and ends when Navigator 2.0 ships release versions on supported Macintosh, Windows, and Unix platforms. If the release date for the final version varies by platform, then the contest will continue until Netscape has released final versions of Netscape Navigator 2.0 on all 3 platforms.

For questions regarding this contest email "contest_questions@netscape.com" All questions and notifications will be handled via email. Netscape may choose to respond to your questions individually, or as part of a generalized response. Netscape will strive to respond as fully as possible, but can not guarantee a response to all questions we receive.

Hmmm, I thought. This is odd. Here I am potentially reporting a very important problem, to Netscape, and the company is saying that they might not even choose to respond to questions. I began to wonder whether Ford could have ever gotten away with not responding to queries about their products. Especially defects. I wondered what would have been the reaction if Ford decided not to answer mail that inquired about the wee little problem with their Pinto's. But this was a different industry. This was software. Internet software. The hottest, sportiest, new-fangleddy dandiest stuff around. Not responding to mail, but of course!! They're busily harnassing the power of the Internet to deliver software that's bug-free. They can't be bothered with small things like customers. They want bounty-hunters. But no need to let the glow fade so fast. I'm sure that they'll just be swamped with mail ... now let's get to their "proactive reward program" (although I don't know how you reconcile running a contest to improve your product with ignoring mail ... must be some newfangled modern hip-hop do-op bee-bop communications graduate theory thingy, that I just don't quite know how to parse.)

Anyone who finds a severe bug (as defined by us) that hasn't been previously found and can be reproduced by us will be entered in drawings for prizes from our GENERAL STORE.

Hmmm, a severe bug (as defined by them). Is this like a Level One?? I wonder what that would be. But let's get to the meat of the matter, what are the prizes that Netscape is offering to harness the power of the Internet while they ignore and don't (selectively) reply to email.

Netscape will conduct 2 drawings and will award 50 prizes in each drawing, for a total of 100 prizes. 50 will be nifty Netscape Mozilla mugs and 50 will be snazzy Netscape polo shirts. We'll award either a mug or a shirt, our choice, to the submitters of each of 100 bugs drawn randomly.

<cough> ... 'scuse me ... a nifty Netscape Mozilla mug?? 50 of them do you say?? Let's, see. Last time I checked a single share of Netscape Communications Corporation (NASDAQ: NSCP) was trading for about $60 plus change. I calculated the wholesale cost of the mugs at approximately $1.20 each, which would bring the total mug promotion budget (50 * $1.20) to the equivalent of one single share of NSCP. Gee, that certainly motivates me. But then again, there's those snazzy Netscape polo shirts. ;-) Shame that Netscape isn't Microsoft. I'm sure that other vendors might at least offer the Great Powerful Internet Bugs Hunters.a choice between the snazzy shirt or the nifty mug? But I guess most of the shirts and mugs weren't reserved for the Bugs Hunters. They were probably in de press kits.

We'll conduct the first drawing when we ship Beta 2 for all platforms and the second drawing when we release the final version of Netscape Navigator 2.0.

If you find a Security bug that hasn't been previously found, and can be reproduced by us, we'll contact you via email and offer you your choice of any item in the Navigator products or Bazaar section of our General Store.

Wow, I thought. I was stupified. If I found one of the Security bugs, I could get a copy of one of the Buggy Products absolutely FREE!!! Gratis!! What man could turn his nose up at that kind of offer. This lil old rest-stop cum cafe, the one that's putting out the bounty offers on the info-highway ain't like no little greasy spoon where you stop for chile and then get CHARGED when you find a cockroach on your spoon staring you down eye to eye. Heck no, this is a CLASS operation. Dinner's on the house.

And if the security bug you find is severe as defined by Netscape, and hasn't been previously found, and can be reproduced by us, we'll write you a check for $1000.

Now we're really talking ...If you find a really, really severe bad problem, we'll reward you with the equivalent of 16.5 shares of Netscape. A veritable REWARD OF REWARDS!!

No purchase is necessary. All entries become the property of Netscape, and may be modified, revised, edited, incorporated into Netscape products and otherwise used at Netscape's sole discretion.

Oh, oh ... incorporated into Netscape products??? This is sort of a non-consensual waiver of all of your rights by participating in this contest?? Now this made me want to stop and cogitate for a lil bit. I thought ...(but only for a second, of course, cause there were bugs to hunt) and I thought ... and I thought that security bugs were much too important to stop this over such a trivial matter, as negotiating my rights away for the benefit of possibly getting a mug. But there was no time to stop and think. Security bugs were going to be our target. Big Game. Non of that discretionary mug stuff for us ... we can't be bribed that easily ... no sirree, bob.

Netscape is not responsible for late, lost, or misdirected entries. All taxes on prizes are the sole responsibility of winners. By participating you agree to these rules and the decisions of the judges, which will be final Any disputes concerning this event will be settled by arbitration.

Tax on a mug?? Ok ... I think we understand each other now. The budget's tight, and all. The plan really wasn't well thought out, and of course we all know that the IPO didn't do that well, and blah, and blah, blah, blah. Ahh, but a hunt's a hunt. So a hunting, we will go. (Phew, isn't this a long post to the list??? I haven't really said anything about the SECURITY BUG yet, have I?? Sheesh, I'm so, so verbose.) But first, what is a SECURITY BUG, anyway?? What does Netscape's marketing machine consider a REAL SECURITY BUG?? If we know that, then we'll know where to look. Before we get to that ... one last quote from Netscape's spokesman, Homer.

"We are continuing to encourage users to provide feedback on new versions of our software, and the Netscape Bugs Bounty is a natural extension of that process," said Mike Homer, vice president of marketing at Netscape. "By rewarding users for quickly identifying and reporting bugs back to us, this program will encourage an extensive, open review of Netscape Navigator 2.0 and will help us to continue to create products of the highest quality."

Gee, don't worry, Homer. The POWER OF THE INTERNET will help you to create products of the highest quality. And the POWER OF THE INTERNET will encourage a real extensive open review. And watch for my new home page coming to a web site near you. The one titled, "I DEBUGGED NAVIGATOR AND ALL I GOT WAS A LOUSY SHIRT." But back to the question of what is a Security Bug?? Because I'm not sure if Marketing is going to agree (in its sole discretion) with what a security bug is (even if it has been hunted down). So at the risk of boring everyone to tears, I'll simply provide some external standards on the matter, just so I don't jeopardize my bounty or my shirt or my mug. Let's start with some Orange Book standards. The Orange Book, DEPARTMENT OF DEFENSE STANDARD, DEPARTMENT OF DEFENSE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA (DoD 5200.28-STD) which we're all intimately familiar with, since it of course sets the standard for everyone from the Small Business Administration to the National Science Foundation, (I think). Anyhow, it makes these points: DoD Directive 5200.28, "Security Requirements for Automatic Data Processing (ADP) Systems," stipulates: "Classified material contained in an ADP system shall be safeguarded by the continuous employment of protective features in the system's hardware and software design and configuration . . . ."[8, sec. IV] Furthermore, it is required that ADP systems that "process, store, or use classified data and produce classified information will, with reasonable dependability, prevent: a. Deliberate or inadvertent access to classified material by unauthorized persons, and b. Unauthorized manipulation of the computer and its associated peripheral devices."[8, sec. I B.3] The concern here is with the latter standard. The unauthorized manipulation of a computer and its associated peripheral devices. And this is where we jump onto the scent of the track of the Security Bug. And this is where we introduce a little old document called pushpull.html. from Netscape's Web site. It's titled: An Exploration of Dynamic Documents.

The Great Idea

The general idea is that browsers have always been driven by user input. You click on a link or an icon or an image and some data comes to you. As soon as people saw they could do that, they wanted to give a server the ability to push new data down to the browser. (An obvious example is a stock trader who wants to see new quote data every 5 minutes.) Up until now, that hasn't been possible.

And I can think of many people who would _also_ like to push down data to a browser. But, that's not a great idea. Guess what?? It's not even a good idea. It might even be a bad idea.

Netscape Navigator 1.1 gives content creators and server administrators two new open standards-based mechanisms for making this work. The mechanisms are similar in nature and effect, but complementary. They are:

Server push -- the server sends down a chunk of data; the browser display the data but leaves the connection open; whenever the server wants it sends more data and the browser displays it, leaving the connection open; at some later time the server sends down yet more data and the browser displays it; etc.

Yes, the client "processes data" and then possibly displays it, while in

Client pull -- the server sends down a chunk of data, including a directive (in the HTTP response or the document header) that says "reload this data in 5 seconds", or "go load this other URL in 10 seconds". After the specified amount of time has elapsed, the client does what it was told -- either reloading the current data or getting new data.

Hmm. Netscape's clients blindly trust and follows server's instructions and does what it is told to do. If it's told to load a particular document in five seconds. It does that. It dances to the server's instructions. Something which should cause any Security Administrator's hair to stand on end, as the server takes control of the client's machine and "manipulates it".

In server push, the magic is accomplished by using a variant of the MIME message format "multipart/mixed", which lets a single message (or HTTP response) contain many data items. In client pull, the magic is accomplished by an HTTP response header (or equivalent HTML tag) that tells the client what to do after some specified time delay.

For server push we use a variant of "multipart/mixed" called "multipart/x-mixed-replace". The "x-" indicates this type is experimental. The "replace" indicates that each new data block will cause the previous data block to be replaced -- that is, new data will be displayed instead of (not in addition to) old data.

So here's an example of "multipart/x-mixed-replace" in action:

...

Content-type: multipart/x-mixed-replace; boundary=ThisRandomString

--ThisRandomString Content-type: text/plain

Data for the first object.

--ThisRandomString Content-type: text/plain

Data for the second and last object.

--ThisRandomString--

The key to the use of this technique is that the server does not push the whole "multipart/x-mixed-replace" message down all at once but rather sends down each successive data block whenever it sees fit.

And this is the problem. We have a pipe. And we have a server making a decision when it will send the next data block. I guess the server could also decide dynamically what that data block is going to be once it has opened it's pipe to the client. That is way too much trust for a client to place in a server that it doesn't know if it can trust.

The HTTP connection stays open all the time, and the server pushes down new data blocks as rapidly or as infrequently as it wants, and in between data blocks the browser simply sits and waits for more data in the current window. The user can even go off and do other things in other windows; when the server has more data to send, it just pushes another data block down the pipe, and the appropriate window updates itself.

Yep, the appropriate window just "updates" itself at the command of the server. A good faith update ... or let's call it a good faith process.

So here's exactly what happens:

Following in the tradition of the standard "multipart/mixed", "multipart/x-mixed-replace" messages are composed using a unique boundary line that separates each data object. Each data object has its own headers, allowing for an object-specific content type and other information to be specified.

Let's emphasize that what we have is a slave client at one end of a pipe accepting an object-specific content-type from any server. This is not within the tradition of multipart/mixed. And this is a problem.

The specific behavior of "multipart/x-mixed-replace" is that each new data object replaces the previous data object. The browser gets rid of the first data object and instead displays the second data object.

A "multipart/x-mixed-replace" message doesn't have to end! That is, the server can just keep the connection open forever and send down as many new data objects as it wants. The process will then terminate if the user is no longer displaying that data stream in a browser window or if the browser severs the connection (e.g. the user presses the "Stop" button). We expect this will be the typical way people will use server push.

The previous document will be cleared and the browser will begin displaying the next document when the "Content-type" header is found, or at the end of the headers otherwise, for a new data block. The current data block (document) is considered finished when the next message boundary is found.

Together, the above two items mean that the server should push down the pipe: a set of headers (most likely including "Content-type"), the data itself, and a separator (message boundary). When the browser sees the separator, it knows to sit still and wait indefinitely for the next data block to arrive.

Now let's play with the prior example. Let's say that we utilized different types of objects. I'll use multipart/parallel and application/postscript.

...

Content-type: multipart/x-mixed-replace; boundary=ThisRandomString

--ThisRandomString Content-type: application/postscript

Data for the first object

--ThisRandomString Content-Type: multipart/parallel; boundary=ThisSecondRandomString

--ThisSecondRandomString Content-Type: application/postscript

Data for the second object

--ThisSecondRandomString Content-type: application/postscript

Deletefile Renamefile Filenameforall File

--ThisSecondRandomString--

--ThisRandomString--

I think that the foregoing explains itself without me having to draw any more maps, than is absolutely necessary. The first data object sent is application/postscript. The second object is multipart/parallel. And it's where we conflict with federal requirements:

b. Unauthorized manipulation of the computer and its associated peripheral devices."[8, sec. I B.3]

And I think that this is applicable across the entire product line. I wonder if this makes me eligible for a bounty for each product where there is this Security Bug?? That would be very chivalrous of Netscape to offer me that. Then maybe I could get a real computer rather than this crufty old Mac Plus (a yellow one) and my 2400 baud modem... and then, I might just be able to do some virtually real hunting. Alice de 'nonymous ... (doing a bad impression of Elmer Fudd with thoughts of Bugs Bounty in his lil mind.) ...just another one of those... P.S. And yes I brought this whole issue (tangentially) to the attention of netscape.com yesterday afternoon. I think I asked whether they were going to have a formal specification and register their x-mixed-replace with IANA. They haven't gotten to my email yet, (I think). Or maybe, I'm in the Bulk response group. <shrug> P.P.S. I give permission to have this propogate freely through the cyber-aethyr. All other rights are of course reserved. C. S. U. M. O. C. L. U. N. E.