Message-ID: <200408132117.44480.fulldisc@ultratux.org>
From: fulldisc at ultratux.org (Maarten)
Subject: (no subject)

First off:  Nick, please lose that damn attitude of yours !


Further, by hammering on the endless we-have-done-it-for-many-years-so-who
are-you-to-tell-us-differently part you're actually making yourself part of 
the problem, not part of the solution.  
You're saying that internal procedures make it so difficult to adapt names 
after the fact.  When in fact the strength of a company, any company, IS to 
be able to adapt to changing circumstances.  
And if they're not able to, eventually they will go the way of the dinosaurs.

The only thing Todd (and I) are trying to say is that it is possible to rename 
after the fact.  I don't #!%$&* care how many old Cobol programs need 
adapting for that to "get" possible, but the fact remains that it IS.   
Don't start again about how your current procedures may prevent or complicate 
that.  Worse integration problems, by far more complex and bigger companies 
or conglomerates are being tackled every day.  Yeah. To name a few ?  
How about mergers, or international intelligence-exchange between law 
enforcement agencies.  Do you think that they let anyone stop them by 
complaining that database format X isn't readily compatible with format Y ?  
No. They fix it, they make it work together no matter what.
So don't start about how impossible it is for you to rename one simple entry.

To conclude, I'd like to put serious question marks by your statement that the 
first few hours are the all-important ones.  First off, by renaming after the 
fact (after the first few hours/days/weeks) no-one is changing ANYTHING about 
those first hours so you shouldn't have ANY complaint regarding that.

Secondly, a lot of the confusion only comes later. The guys that have their AV 
software up and running and current mostly do not suffer from the outbreaks.
The problem often comes (much) later, with the people who didn't update, 
'forgot to', or plain disregard any security or updates whatsoever.  And then 
you are only called in to fix things when stuff is really breaking down.  
Or are you saying you've never been asked to de-toxify your parents'-, 
friends'- or siblings'- computers that got infested despite everything ?
Everyone has.

Oh and P.S.:  Yes, I did read all of the threads pertaining to this.

Maarten



On Friday 13 August 2004 15:08, Nick FitzGerald wrote:
> Todd Burroughs wrote:
>
> Before trying to explain a few items to Todd, it is clear that he is
> either smoking something very bad or he jumped into the middle of
> thread on a topic he knows nothing about and decided the rest of the
> world wanted his ignorant, pea-brained opinions anyway.  If Todd reads
> all the rest of the thread that came before this and still cannot see
> why his post makes him appear to be a complete moron, I'll gladly try
> to explain it again...
>
> > > I can easily understand how someone unversed in the _market forces_
> > > pertaining to antivirus software could hold that position, and as a
> > > theoretical solution to the problem of lack of cross-vendor naming
> > > coordination it has often been suggested even by though who know it
> > > would never work in the real world.
> > >
> > > Neat and tidy as such a solution seems, it will not, however, work.  As
> > > I explained in other of my posts in this and the related "AV Naming
> > > Convention" thread, in general by far the largest "cost" of naming
> > > disagreement is borne by the users in the early hours of large-scale
> > > outbreaks.  Thus, a "solution" that specifically _requires_ all vendors
> > > to use a different name until a name is agreed (no matter what this
> > > process it will take some _additional_ time) is, by design, an _anti-
> > > solution_ as such a "solution", by design, ensures perfect naming
> > > inconsistency at the time the highest cost of naming inconsistency is
> > > borne.
> >
> > Vendors should not "have to" use a different name until the "real"
> > one is detrermined, they should use whatever they want to.
>
> Dip-stick -- that is, as I just pointed out immediately above,
> precisely what happens now and is (part of) the cause of the problem
> that is being discussed.  Please read the rest of the thread then re-
> read the message you think you are responding to so you actually know
> what is being talked about and who holds what positions.
>
> > You know what, I don't work in the "anti-virus" field, but what you are
> > saying is BS.  ...
>
> Of course you do.
>
> And someone with well over a decade's close association with these
> issues, at the bleeding edge of malware naming decisions for most of
> his waking hours wouldn't know what he is talking about.
>
> Just like I am not a medical doctor so I must be better qualified to
> sort out the medical profession...
>
> > ...  There is no good reason that I can think of that the AV
> > companies cannot rename these things after the fact.  ...
>
> Well, fortunately for the world, you don't get to shape the solutions
> here...
>
> > ... When an outbreak
> > happens, they provide a fix and name it whatever they want.  ...
>
> This _IS_ what happens now.
>
> _THAT_ is part of the problem.
>
> A _LARGE_ part...
>
> > ...  After the
> > fact, they could rename things and their updates reflect the "proper"
> > name.  ...
>
> Indeed, some can and sometimes some of them do.  Of course, often 3, 6,
> 12, 24, 48 or even 72 hours after the event (and after processing
> perhaps several dozen more submissions from their users) very few folk
> actually care any more.   Yeah, yeah, there are exceptions, but the
> reality is that the often massive re-architecting of internal processes
> in some AV companies is simply not seen as worth the effort (and
> therefore the cost).  Thus, it _will not_ happen unless the ROI factor
> of making such changes as will allow nimble naming and rampant re-
> naming change dramatically.  Exceptionally few customers have ever
> actually changed product loyalties because of the naming mess, so there
> really is no compelling business case for fixing some of the
> chronically stupid processes that prevent staff in some AV companies
> from changing names at will.
>
> Now, I did not say I like this situation and I was not defending it --
> if you'd the whole thread you would, in fact, realize I am one of the
> strongest critics of the current situation and am certainly the best
> informed about the topic amongst those posting.
>
> However, no matter how elegant a proposed solution is, it has to face
> the cold hard facts of the commercial realities, and technical
> realities, that will constrain its possible adoption.  Thus, as much as
> you may not like the reasons I gave for why that proposal will not
> work, those reasons are some of the  constraints that have prevented
> such ideas from already being implemented.  As an outsider you cannot
> know this, but from watching and participating in the day-to-day
> workings of the AV industry for all these years now, I can tell you
> there hasn't yet been a vaguely original sentence in all the ideas
> thrown into these F-D threads on malware naming and there are
> established practices and reasons for why none of those ideas have been
> adopted and/or never will be.  (This does not mean that some of the
> ideas might be at least half worth considering, as often the reasons
> for their non-acceptance are very poor, though this is NOT the case
> with this idea -- its downright stupid and will never fly if the
> objective is to make things better.)
>
> > ...  They can keep a reference to their name in the description, what's
> > a few more characters in the signature files for every piece of malware
> > going to matter? another 100k in a download at most?  I agree that there
> > is probably a lot of marketing pressure that may make this difficult,
> > but there is no technical reason for it.
>
> You're quite wrong.
>
> You're making all kinds of assumptions about internal data layouts and
> formats and you are ignoring all manner of non-detection collateral
> whose production and maintenance is a huge sub-industry unto itself,
> and in some cases is architected in very stupid ways that revolve
> centrally around _the_ name for each piece of malware detected by the
> product.  Yes, such things should have been designed by someone with
> ten minutes formal database or work-flow training but sometimes they
> weren't and the cost of re-architecting and transitioning a massive
> store of existing material to anything different will have to be signed
> off very high up the management chain -- the kind of "high" that will
> respond to "we'll lose all our US government contracts if we don't do
> this" reasoning as a purely business case, but would never do it for
> some "soft" reason like "on average our users will prefer us 7.94%
> more".
>
> > The AV companies cannot be that lame that they cannot handle a simple
> > name change.  I mean we use databases and other things and using these
> > "computers" that should make this easy.  If thay are that lame, maybe
> > they shouldn't be in busines.
>
> You cannot be that lame that you cannot understand how complex,
> unnecessarily constraining systems often develop when their designers
> didn't know where the goal-posts would be moved during the next 15
> years, can you?  If you are that lame, maybe you are unemployable?
>
> > It's up to people like us that read lists like this to make them fix
> > this silly problem, or we can ignore it.  It doesn't affect me much,
> > it just seems silly that they cannot name things consistently.
>
> You're wlcome to try to convince them, but unless you control s/w
> purchasing decisions for many, many tens (or even perhaps hundreds) of
> thousands of users, you will not convince _one_ of them, let alone all
> of them (and, if you think about it, it would require similar market
> force -- whatever that may be -- to be brought to bear against several
> of the large developers all at once to actually provide enough
> incentive to get them to support some kind of centralized naming
> authority mechanism).
>
> > > Secondly, one of the greatest impediments to ongoing (as opposed to
> > > initial, outbreak-phase) naming inconsistency is that many vendors do
> > > not have internal processes robust enough to easily handle renaming
> >
> > This is a lame excuse at best, maybe these companies need to redesign
> > themselves, this should not be a big problem.
>
> I never said it was anything else but that.
>
> You have missed my point and are trying to argue against me on
> something we largely agree on here.  Yes, that is a lame excuse, but it
> is one of those monstrously lame things that cannot be fixed without a
> huge intervention.
>
> > > (And please, before replying to this message, please, please, please,
> > > please, please read _all_ the rest of thread -- as the only person
> > > making a significant contribution who has more than half a clue about
> > > how all this stuff works, what may be technically feasible, and what a
> > > great deal of customer and industry history suggests may be acceptable,
> > > answering the same misconceptions over and over is getting tiresome...)
> >
> > We'll be sure to bow down to you...
>
> Good -- while you're bowing down, like my boots clean as I seem to
> trodden in some muck in one of the mailing lists...
>
> Then you can go and read the earlier parts of the thread so you will
> see what a nut-job you made yourself look...

-- 
Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER

Powered by blists - more mailing lists