Re: Active X problems was Re: It's COBOL, Jim, but not as we know it...
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 14 Dec 2008 14:32:38 +1300
Clark F Morris wrote:
On Wed, 10 Dec 2008 10:25:21 +1300, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Bill Gunshannon wrote:
In article <6q68rpFauuruU1@xxxxxxxxxxxxxxxxxx>,
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:
Malice, like Beauty, is often in the eye of the beholder.
No, malice is malice. The problem with all these scripting
languages and applets is you have no way of knowing if it is
malicious or not until you run it at which point, it is too late.
That is simply not true. Web based ActiveX components that install
to your client announce themselves. Download the demo and see for
yourself.
Which is why many
people (and a lot of organizations) don't allow it.
Organizations make blanket decisions that are usually the lowest
common denominator to protect themselves. You can't really blame
them.
Bill, my point was that often people see malice where there is none.
(It is a form of paranoia.) It is exacerbated by a lack of
understanding.
Java beans, ActiveX, JavaScript all have no more rights on your
system than you allow them. They cannot overwrite your hard drive
like a virus can, for example, unless you specifically grant write
access rights to them. Given that an ActiveX announces itself and
you know what it is for and where it is coming from, the risk is
negligible. (Unless you are a person who sees malice everywhere, in
which case the risk is enormous... you know they are out to get you.
: - )) Would you not download a virus scan ActiveX because it is an
ActiveX? No, you make an informed decision. You know what you are
getting and the source of it. It serves a very useful purpose.
There is a lot of paranoia. Because the actual technology is a
MicroSoft one, many people mistrust it for that reason alone.
I don't think people who ban scripts and ActiveXs are wrong; they
have a right to do whatever they like with regard to their systems,
but I do think they are missing out on a lot.
I have prompt for Active X permission on one of my XP logons and the
problem is the idiots who designed the permission check in Internet
Explorer don't have an option to allow all scripts from a given
source.
You can achieve this by placing the site in the Trusted zone, and setting
the level to Low. Check out the "Security" tab on the internet options for
your IE browser.
They don't even have an option to allow all scripts from a
given source for the session so I have gotten multiple prompts when
doing Windows Update. Also on the home edition, I haven't seen any
way to configure the permissions for Active X.
Again, it is in the security tab of Internet options. It isn't dependent on
what version of XP you have, it is dependent on the Browser.
To REALLY configure the detailed security for a COM/ActiveX component you
need to go to the "Administrative Tools" option in Control Panel and open
the Component Services tool. The act of installing a component does NOT run
it... you are able to configure it before it runs. Click down to the "DCOM
config" tab, locate the component in the list, then right click on its entry
and open its properties. This is a tabbed display and the security tab
allows you to decide what userid, authentication, computer on the network,
or anything else you need in order to be secure. To go to these drastic
lengths is more than the average user needs, as the defaults are usually
fine, but you CAN configure a component to run exactly HOW (permissions) and
WHERE (a computer or URL you have run permissions on), and under what
authentication (user or group ID) you want it to. You can make it as loose
or as tight as you like, and you can even prevent certain users from
accessing it. As a component developer I use this tool all the time and test
stuff with differing levels of security and authentication, but it is not
needed for the average user.
It is ironic to me to see a number of people declaiming ActiveX/COM
technology as "dangerous" when it is actually completely configurable,
stable, and safe. These same people are using this same technology every day
and enjoying the benefits of it, if they run under Windows, whether they
realise it or not.
Most users don't have an Object Browser (that they know about... there is an
excellent one included with VB and VBA, which anyone who has installed MS
Office will have...and an even better one included with Visual Studio...)
and wouldn't know what to do with it if they did.
It is a pity, because if you were to open one up and tell it to browse for
COM
controls, you would be surprised at the several thousand it reports
installed on your system. (They do everything from playing music and videos,
converting text to speeech, providing GUI interface controls, sending email,
connecting you to Help, running both Internet and Windows Explorers, to
system oriented tasks like resource management and monitoring and logging
system events...Windows would be unrecognisable (and useless) without them).
That is part of the "danger" of course. When you download an Activex
component it becomes just like an extension of the Operating system (which
is largely composed of such components) and that is why you should be
careful about what you download and what permissions you give it.
For a developer, this is a goldmine of re-usable,ready written functionality
that is available on every Windows system.
You can include it in your applications and/or web pages. BUT, it does tie
them to Windows unless you take special steps that have more to do with
remotely running the components (COM+), than using them locally.
Even without the 40,000 classes available in .NET there are several thousand
classes already available through the COM interface, that are simply part of
the Windows environment. If you target Windows machines you can use these
components without royalties or run fees because they are already registered
on the target system. (it is very similar in principle to using the Windows
API ). ActiveX/COM componentry is an inherent part of Windows and the
Windows environment, and looks like remaining so for the foreseeable future.
Pete.
--
"I used to write COBOL...now I can do anything."
.
- Follow-Ups:
- References:
- It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- Re: It's COBOL, Jim, but not as we know it...
- From: HeyBub
- Re: It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- Re: It's COBOL, Jim, but not as we know it...
- From: Robert
- Re: It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- Re: It's COBOL, Jim, but not as we know it...
- From: Richard
- Re: It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- It's COBOL, Jim, but not as we know it...
- Prev by Date: Re: OT - Testing chevrons - no COBOL content
- Next by Date: Re: OpenCOBOL 1.1 pre-release surpasses 9000 NIST standard tests
- Previous by thread: Re: It's COBOL, Jim, but not as we know it...
- Next by thread: Re: Active X problems was Re: It's COBOL, Jim, but not as we know it...
- Index(es):
Relevant Pages
|