W3C home > Mailing lists > Public > www-html@w3.org > March 2000

moving on. (was: Re: flying pigs considered harmful. )

From: Sean Champ <symmetry_web@email.msn.com>
Date: Fri, 3 Mar 2000 17:33:44 -0800
Message-ID: <005801bf8579$ae82adc0$734e1c3f@toolbox>
To: "Braden N. McDaniel" <braden@endoframe.com>
Cc: <www-html@w3.org>

if the w3c doesn't get a mailing-list going for it,
we can possibly move this (project | initiative) to SourceForge:


and this note is intended to state:

            I'll need to hear from any interested persons, to see if I
should take the time to file for starting up a new project there, at

(sourceforge = free mailing-lists, CVS, ftp-space, etc, for qualified
projects )

their systems are still in the developmental stages, but it may be worth a
shot, if at least to clear this out of the w3c list, and to provide a
catchbin for messages that might actually be helpful, towards this

please email me directly, if you'd be interested in it, or if you'd like
more information about SourceForge:


and if you'd be interested in being an Admin for this project, please say so


----- Original Message -----
From: "Braden N. McDaniel" <braden@endoframe.com>
To: "James P. Salsman" <bovik@best.com>
Cc: <www-html@w3.org>
Sent: Friday, March 03, 2000 2:09 PM
Subject: Re: flying pigs considered harmful

> On Fri, 3 Mar 2000, James P. Salsman wrote:
> > Line noise transmitted the message below unattributed; my apologies
> > to Braden McDaniel.
> >
> > >> [JPS:] The only
> > >> way to obtain device upload does not even involve the INPUT tag
> > >> (on Windows' MSIE, the OBJECT tag is used with an insecure
> > >> "ActiveX" binary; on Netscape Navigator under Windows, the EMBED
> > >> tag is used with a similarly insecure arrangement where the user
> > >> must "Grant All" system privileges to the EMBEDed binary code.)
> > >
> > > [BNM:] Yes, well, one could probably use OBJECT/EMBED to make pigs
> > > fly if one were so inclined and prepared to waive the relevant
> > > security precautions.
> >
> > The security concerns are actually more significant than the "it
> > won't run on my Mac/Unix workstation" -- at least for the majority
> > that don't have Mac or Unix workstations.  Promiscuous use of
> > insecure binary plug-in applications is another reason against
> If the client machine is secure to begin with, this is really no more true
> for applications invoked via OBJECT/EMBED than it is for any other
> application. The implementation flaws you're referring to are neither
> flaws in the specification of OBJECT nor flaws in the usage of
> > >> If the W3C would just take a stand, and tell the browser vendors
> > >> that in order to be compliant with the W3C Recommendations, if
> > >> device upload is implemented then it should be available in a
> > >> certain way, then they would probably conform to stay compliant.
> > >
> > > The W3C has defined conformance terms for HTML 4, CSS1, CSS2... And
> > > many browsers conform to date? I'm a little bit skeptical that having
> > > W3C stomp its feet would do a bit of good.
> >
> > It is completely reasonable for the W3C to act in the general
> > interest of web users.
> Maybe.
> > Supporting device upload would be in
> > their interest because of the reduced security concerns, the
> > more widespread accessibility on a diversity of platforms, and
> > the general utility of the services enabled for education,
> > commerce and industry.
> As has already been pointed out, the W3C already supports a mechanism
> which may be used for device upload. What this seems to come down to is
> just that they don't support *your* mechanism.
> > I believe the W3C will try to hold on
> > to its leadership role in consumer protection pertaining to
> > browser technology.
> It's entirely debatable as to whether the W3C even occupies that role. It
> is a vendor consortium. The vendors pay the bills. So who do you think the
> W3C answers to?
> And stop spamming the IETF list with this garbage. It's even less topical
> there than it is here.
> --
> Braden N. McDaniel
> braden@endoframe.com
> <URL:http://www.endoframe.com>
Received on Friday, 3 March 2000 20:34:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:53 UTC