RE: Winnt/Win2k Vuln ?

[Louis-Eric Simard <Louis-Eric () Simard com>]

At 09:51 PM 11/08/2001 -0700, David Schwartz wrote:

> Louis-Eric Simard wrote:
>
> > The major distinction here should one of action-domain constraints;
>
>         Exactly.
>
> > As we are limited by the fact that the shoddy name space is now
> > prevalent,
> > then context needs to be taken into account. As one types in a
> > URL without
> > specifying the underlying protocol (http:// or file://), there
> > should be no
> > ambiguity that the expected protocol is http, just as we do not naturally
> > expect file system requests to be carried over the web. The fix is in
> > filling-in missing protocol details, within logical usage
> > contexts, before
> > the request allocator gets a chance to goof it up.
>
>         For the record, I have submitted complaints/requests to the 
> coders of both
> IE and Netscape arguing that, for example, 'ftp.microsoft.com' should be
> interpreted as 'http://ftp.microsoft.com' and not 'ftp://ftp.microsoft.com'
> (and analogously, the brower should not try to figure out what the user
> meant (ESP?) but should have a consistent default). I was basically laughed
> at by both Microsoft and Netscape.
>
>         I don't think it's unreasonable to have different operating modes 
> where
> different defaults take place. For example, when acting as a 'file manager',
> file:// can be the default protocol. However, IMO, in ALL cases, the
> fully-qualified URL of the site/file you wind up at MUST be shown to the
> user. It is a serious error to abbreviate the displayed URL as IE does. I do
> not believe Netscape does this.
>
>         DS

Right. The other consequence of the muddled/"guessed" semantics is that 
misspelled, URL-less filenames (those, by lieu of their misspelling, not 
found on the drive), end up as keyword queries (in IE, to 
auto.search.msn.com; in Netscape, in a less ususal scenario [eg, mistyping 
in a way that causes the filename period to be missing]) transmitted in the 
clear, opening up some privacy/confidentiality/security problems.

Having distinct access tools for distinct information domains solves, on 
the surface, this problem (less so when you bring plug-ins, web-enriched 
directories, shared protocols, etc. into the picture), but limits the 
possibilities for conversant data access; going for multi-domain access 
using unified tools requires that some intelligence be injected into the 
process. Both cases would require more responsible engineering than what we 
have now.

Cheers,

 + Louis-Eric Simard
   The Freedom Factory, Inc.