"Eric Paynter" <[EMAIL PROTECTED]> to me: > > You need look no further back than the > > kerfuffle a couple of months ago over the removal of IE's patently > > incorrect support for "user:pwd@" userid data in http URIs for an > > example, but there are many other, earlier examples. > > I'm a little confused by what you mean here. ...
Then read the RFCs more carefully... > ... The "user:pwd@" prefix is a > part of the URI standard documented in the RFC. ... Yes, it is part of the _general_ URI scheme. However, if that is _ALL_ you recall from that RFC you are out of your depth to be discussing this. More importantly than defining the general URI form (with _or without_ the "userid" feature), the URI RFC _explicitly defers_ to protocol-specific URI definitions in other, unspecified RFCs _for any specific protocol URI_. Thus, before you can say anything meaningful about HTTP URIs you have to find if the HTTP protocol URI was explicitly defined in any other RFC(s). Before Christmas 2003 I was of the same opinion you are, because I had not found an "HTTP URI" RFC, but as someone pointed out in these lists late last year, the HTML RFCs define the HTTP URI (rather than having just that in an RFC of its own) and the most recent HTML RFC deliberately defines HTTP URIs sans the general URI RFC's "userid" concept. So, RFC-compliant browsers do _NOT_ support the general URI's userid feature in HTTP URIs. > ... As far as I can tell, the > patently incorrect part is that they removed it and thus made the browser > (even more) lacking in standards support. ... Please read all the relevant RFCs and correct your misunderstanding then... > ... It's a simple example of how MS > solves problems: > > 1. Fix the feature that is vulnerable > 2. Disable the feature that is vulnerable > > Lately, they just disable the feature. At this rate, pretty soon, Windows > won't do much. Well, in the case of removing IE's support of the general URI RFC's "userid" feature, 2. clearly collapses into 1. as the fault was that IE supported an explicitly defined non-feature. MS did precisely the right thing and anyone that belly-ached that some useful feature they had depended on had been removed should simply be biffed with the cluebat, as they clearly were using non-conformant web pages. As for the more general claim that MS is removing functions from Windows... First, there are an awful lot (or is that "lot of awful"?) features they'd have to remove before Windows started to be non- functional. Second, a lot of Windows' security problems are directly traced to the fact that it tries to be all things to all folk -- such wide open generality is widely known in CS circles to come at the price of performance due to the necessary complexity such an approach entails. In general, complexity is natural enemy of security because "the devil is in the details" and when you have unbounded, featuritis- driven complexity you get unmanageable layers of complexity hiding ever more such layers. Stripping some of those layers out can only be the beginning of something good for the security of Windows' users... Regards, Nick FitzGerald _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
