RE: Winnt/Win2k Vuln ?

["David Schwartz" <davids () webmaster com>]

> David Schwartz wrote:

> > > The browser should not be the file manager.  That is all there is to it.
> > > -b

> >     Sure, and the OS shouldn't be the memory manager. The
> > filesystem should be
> > purchased separately. And you should need a separate client for FTP. Your
> > network stack should come from a different vendor than your OS. And your
> > computer shouldn't include memory. I vote for maximum inefficiency and
> > duplication of code too.

> >     Why should viewing a remote resource be any different from
> > viewing a local
> > resource? Especially when you consider that local files can
> contain diverse
> > content types requiring complex presentation and navigation -- just like
> > remote files.

> >     DS

> You are missing the point.  You can view resources both locally and
> remote and I have no heartburn.  However, viewing and managing are two
> entirely different concepts.  A file MANAGER, by definition, MANAGES
> files.  A web BROWSER, also by definition, BROWSES the web.

        No, you are missing the point. How can you manage files if you can't see
their contents? How can you view files through the FTP protocol if you can't
navigate directories?

        It is illogical to have one tool for each protocol. When I want to view a
resource, why should I have to think about whether it's a local text file or
a JPG that has to be FTPd? I want one interface. What you are asking for is
a browser to be just an HTTP tool, and that's a mistake. FTP is a protocol
too. And there's no difference between a file I can FTP and a file on my
local hard drive. There's no difference between what I might want to do with
a file on my hard drive or a file on a web site that I manage.

> Managing includes operations such as move, copy, delete, execute, etc.
>  Viewing includes none of those operations.

        You are ignoring the significant areas of overlap, including directory
listing, retrieving files, and presenting them. HTTP even has support for
putting files on the web server directly, though this not commonly used.
Integration between HTTP and FTP makes more sense, and is often a very good
way to manage a web site.

> If you don't believe me, tell me this.  When was the last time you
> visited http://www.microsoft.com with your web BROWSER and MANAGED the
> web pages you found there by moving, renaming and deleting them?

        Try ftp://ftp.microsoft.com, where you might need to list files, navigate
directories, and who knows what else. If you maintain the site, you may well
need to move, rename, and delete them.

        Information is information, and where it is and what protocol you use to
get to it has nothing to do with how you view it, present it, or even manage
it. Tools work best when humans don't have to think about protocols. In
fact, the company I work for makes tools that allow you to do things like
FTP your mail, view a web site's hierarchy through an NNTP client, or use
your browser to traverse a directory hierarchy and manage it.

        The idea is that information is information, and protocols are ways to get
to information or get information to you. But what protocol you use to get
or view information has nothing to do with what the information is. And,
like it or not, a browser (extended through Java and JavaScript) seems to be
a great tool for doing pretty much anything.

        You can make an argument that this type of extension shouldn't take place
until the security issues can be properly dealt with. But you would have to
be crazy to argue that it shouldn't take place at all. (Unless you think
some new super-tool will obsolete the browser.)

        DS