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

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


http://www.sourceforge.net


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.






(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
initiative.


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

symmetry_web@email.msn.com
cud@crosswinds.net


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



--Sean






----- 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
> > OBJECT and EMBED.
>
> 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
> OBJECT/EMBED.
>
> > >> 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
how
> > > many browsers conform to date? I'm a little bit skeptical that having
the
> > > 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