<DIV>I think if program design criterion would change, to coding secure applications then</DIV>
<DIV>the problem would be reduced dramatically</DIV>
<DIV> </DIV>
<DIV>-Henry<BR><BR><B><I>Petri Helenius <pete@he.iki.fi></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>Matthew Kaufman wrote:<BR><BR>>End-to-end requires that people writing the software at the end learn about<BR>>buffer overruns (and other data-driven access violations) or program using<BR>>tools that prevent such things. It is otherwise an excellent idea.<BR>><BR>> <BR>><BR>There is supposedly some magic going into this in the next "Service <BR>Pack" of a mentioned<BR>major exploding Pinto. Not sure if it�s just flipping the joke of <BR>firewall on by default or something<BR>more comprehensive/destructive like non-executable stack. Or a <BR>completely new invention like<BR>bug free code :-)<BR><BR>>Unfortunately, the day that someone decided their poorly-designed machine<BR>>and operating system would be safer sitting behind a "firewall" pretty much<BR>>marked the end of universal end-to-end connectivity, and I don't see it<BR>>coming back for a long
 long time. Probably not on this Internet. IPv6 or<BR>>not.<BR>> <BR>><BR>Last I checked most "firewall"s don�t make these machines safe, it might <BR>make them safer,<BR>so only two out of three malwares hit them. Does not really help too much.<BR><BR>>Combine that with ISP pricing models (helped by registry policy) that<BR>>encourage <=1 IP address per household, and the subsequent boom in NAT<BR>>boxes, and the fate is probably sealed. <BR>><BR>> <BR>><BR>Here I�ve observed opposite trend, most ISP�s are getting rid of NATting <BR>because it�s failure<BR>prone and expensive to implement and keep running.<BR><BR>Pete<BR><BR></BLOCKQUOTE>