OpenDoc 1.1 for Windows and OS/2 now available
Nathan Davis
OpenDoc version 1.1 for Windows and OS/2 is now available from
ClubOpenDoc. It can be downloaded from
"http://www.software.ibm.com/clubopendoc/tools.html".
Nathan Davis -- IBM OpenDoc Technical Support
Boualem Sekhri
What advantages does Opendoc (in its current form) provides compared
with
ActiveX/DCOM?
Regards,
----
Boualem Sekhri bou...@nortel.ca
Software Architect (416) 597-7669
Nortel (416) 597-7110 (FAX)
Robert Morgan
Boualem Sekhri wrote:
>
>
> What advantages does Opendoc (in its current form) provides compared
> with
> ActiveX/DCOM?
>
> Regards,
>
> ----
> Boualem Sekhri bou...@nortel.ca
> Software Architect (416) 597-7669
> Nortel (416) 597-7110 (FAX)
For starters, it can't write "nasties" to your disk like ActiveX/OLE
components can, like transferring all of your lucre to an offshore
account or nuking your box or network.
And AuthentiCode doesn't prevent that either. The "response" is for
Microsoft to say: "Oh yeah? Well what about Java?" FWIW, that's
like the bank robber yelling at the cop chasing him to go after the
purse snatcher instead.
Also, OpenDoc is a _truly_ open standard and architecture; unlike
OLE/ActiveX. And, even Inter@ctive Week http//:zdnet.com/intweek is
starting to say that, as well as intimating about the "Open Revolt"
brewing over the ActiveX "openness".
Best.
rkm.
David Rehring
In article <32B059...@worldnet.att.net>, Robert Morgan
<rkm-...@worldnet.att.net> wrote:
>>Boualem Sekhri wrote:
... stuff deleted
>>
>>For starters, it can't write "nasties" to your disk like ActiveX/OLE
>>components can, like transferring all of your lucre to an offshore
>>account or nuking your box or network.
>>
>>
>>Best.
>>
>>rkm.
Robert,
Exactly why can't OpenDoc editor's write 'nasties' to your local disk. The
way I understand it, the editor can call any toolbox func. it wants (once
it's activated), so why can't it thrash everything?
Later,
--
David Rehring
Senior Software Engineer
GDT Softworks, Inc.
And all around insane guy!
David Rehring
In article <32B0F2...@worldnet.att.net>, Robert Morgan
<rkm-...@worldnet.att.net> wrote:
>>David Rehring wrote:
>>>
>>
...my stuff about why can't OD stuff do the nasty on your drive
>>
>>David:
>>
>>An Editor is what is on your drive. The OD Document/viewer is what
>>you download from the Internet. The OD doc doesn't write to disk,
>>and the viewer only lets you view the content. Editors are what
>>allow you to alter the document.
>>
>>Last I heard, having "nasties" in an OD Doc/viewer isn't possible;
>>but someone will probably provide another view. Check out The
>>OpenDoc Revolution (Mike Pinkerton Plug!) as well as Apple's OpenDoc
>>site and IBM's Club OpenDoc. All discuss security issues in one
>>form or another. Also, Inter@ctive Week
>>http//:www.zdnet.com/intweek has been revealing this "feature" of
>>ActiveX/OLE. Can The Wall Street Journal (WSJ) and Investors
>>Business Daily (IBD) be far behind?
>>
>>I've been discussing this "feature" for a while, and even got some
>>"admissions" from "Microsoftian Insiders".
>>
>>Best.
>>
>>Robert K. Morgan
Robert,
I don't see anything to prevent an OD Doc/viewer from munging your drive,
or even the current document. Even if the file was opened read only by the
OD Shell, I think the viewer may (I don't know this one way or the other)
be able to get an FSSpec to the real document, and open it with r/w
permission and munge it directly. There is nothing to prevent anyone from
writing a 'virus' OD viewer that can be automagically downloaded (perhaps
from that PartSeller web site, whatever it's name is), and happily displays
some data in a window while it munges your HD. Once the part's code is
called to set itself up, it can do whatever it wants, and you can't stop
it, short of force-quitting the shell. The only truly 'safe' thing is to
not download LiveObject's off the net, short of some kind of encryption
that at least permits you to verify a LiveObject's origin and that it is
unmodified.
And no, this isn't an attack on OD, just an observation/question.
David McCusker
Boualem Sekhri (bou...@nortel.ca) wrote:
: What advantages does Opendoc (in its current form) provide compared
: with ActiveX/DCOM?
Instead of telling you, which would take a while, I'll describe an
algorithm that might allow you to figure it out for yourself. (As a side
effect, it will also allow others who attend this presentation to figure
out how to effectively criticize absurd claims or logical premises.)
First you must note that ActiveX and OpenDoc are not identical technologies
from the same vendor. Now all you need to do is compare them, paying special
attention to intended usage contexts, along with the projected marketing
strategies and tactics of vendors/adopters/users as they respond to other
technologies over time, as they either conflict or collaborate.
Now that's actually rather complicated because you will only have access
to limited information and your (or someone else's) guesses about how
things will change. But it's important to note that anyone who pretends
that the full complexity can be ignored (say by paying attention only to
a few technical details as they are perceived today) is full of crap.
Anyone who intends to be honest will at least implicitly acknowledge that
they are considering only a portion of the whole picture in assigning a
relative value to OpenDoc and ActiveX. But the advantages of ActiveX
and OpenDoc cannot be examined in some hermetically sealed objective
stage without considering the larger context of how other things relate.
So far I've only discussed meta issues and haven't said much about tech
details. I'll do so now by mentioning those aspects of ActiveX and
OpenDoc that I think are particularly relevant to the comparison, without
insulting your intelligence by lecturing you about what they are in detail.
OpenDoc and ActiveX are only similar technologies, rather than being
equivalent. They are similar because they are component technologies, but
they differ in what aspects of computing are being componentized. OpenDoc
componentizes content (somewhat emphasizing the larger end of the scale),
while ActiveX componentizes executable behavior (emphasizing the small and
UI end of the scale). This is the tech as opposed to marketing comparison.
Because OpenDoc and ActiveX do not target the same range of semantics that
developers try to control, they are compatible if developers wish to use
both. For example, OpenDoc editors can use ActiveX controls in the UI.
However, developers might just as easily use JavaBeans, when available,
to accomplish roughly the same thing, so Java might just shut out ActiveX.
Now in a marketing comparison, we reach an arena of fluff where people say
what they feel like without being compelled to say anything substantive.
(However several intelligent folk have a lot to offer here on occasion.)
So then it's mostly "MS rules!" or "MS sucks!" (with the latter being
correct), with folks lobbying the significance of mind share (because
often idiots can't think of two things at once, and therefore only one
kind of component software seems to exist at once). Part of the relative
value of OpenDoc and ActiveX lies in how the respective sides use them
either as bridges to other technologies, or as clubs to beat them down.
ANNOUNCEMENT: after this week (2nd of Dec96) I'm going mostly offline for
a few months to apply nose to grindstone in the OpenDoc storage system.
If you want OpenDoc support in public forums, send mail about this and
I'll forward it (for a few days anyway) to parties deciding such things.
Please send no mail requiring personal response because I have no time.
David McCusker, OpenDoc Storage & Bento, mccu...@apple.com
Values have meaning only against the context of a set of relationships.
Robert Morgan
David Rehring wrote:
>
> Robert,
>
> Exactly why can't OpenDoc editor's write 'nasties' to your local disk. The
> way I understand it, the editor can call any toolbox func. it wants (once
> it's activated), so why can't it thrash everything?
>
> Later,
>
> --
> David Rehring
> Senior Software Engineer
> GDT Softworks, Inc.
> And all around insane guy!
David:
Robert Morgan
David Rehring wrote:
>
>
> Robert,
>
> I don't see anything to prevent an OD Doc/viewer from munging your drive,
> or even the current document. Even if the file was opened read only by the
> OD Shell, I think the viewer may (I don't know this one way or the other)
> be able to get an FSSpec to the real document, and open it with r/w
> permission and munge it directly. There is nothing to prevent anyone from
> writing a 'virus' OD viewer that can be automagically downloaded (perhaps
> from that PartSeller web site, whatever it's name is), and happily displays
> some data in a window while it munges your HD. Once the part's code is
> called to set itself up, it can do whatever it wants, and you can't stop
> it, short of force-quitting the shell. The only truly 'safe' thing is to
> not download LiveObject's off the net, short of some kind of encryption
> unmodified.
>
>
>
> --
> David Rehring
> Senior Software Engineer
> GDT Softworks, Inc.
> And all around insane guy
David:
I didn't take it as an attack on OD, but a question. While someone
might be able to figure out a way to do it, OD took your concerns
into account form the "git go". Remember, no one has yet been able
to hack into a Mac Server as long as it is set up properly; so Apple
took the same care as it approached OD.
I'll check on some things and give you a more detailed answer unless
someone else chimes in before I get back to you.
FWIW, I don't think anyone here minds honest questions and concerns.
At least I don't mind.
Best.
rkm
Boualem Sekhri
Thanks Robert, David R, other contributors.
I apologize if I have caused any churns, What I am looking for is a
comparison of features. i.e.
Similarities:
---------------
- Component Software Achitecture
- cross platform
(Mac, Windows 95 and NT, as well as OS/2 and AIX/Windows, Mac, unix
in the works)
- Shift from Application Centric to Document Centric/Task centric
defines contaiers and parts
- parts can represent any type of data all active within single doc
- IDL/MIDL(ODL) to define interfaces
from an architecture pt of view (very similar)
- orb technology as FOUNDATION (SOM-CORBA/DCOM-COM)
provide transparent access to local/remote components
- parts coordinate their actions via scripts, events, method invocation
OSA(open Sctpting ach.)/OLE Automation &scripting services
- uniform data transfer
exchange info via links, clipboards, drag and drop
- bento/coumpound files(OLE structured storage and Persistence services
- compound doc management
- <delete & fill in other similarities>
Difference: would apprecite feedback
-------------------------------------
-from an architectural perspective
<delete & fill in differences>
-from a user's perspective:
<delete & fill in differences>
-from a development perspective:
<delete & fill inm differences>
-from a marketing perspective:
<delete & fill in differences>
regards,
Robert P. Krajewski
In article <32B059...@worldnet.att.net>, Robert Morgan
<rkm-...@worldnet.att.net> wrote:
>For starters, it can't write "nasties" to your disk like ActiveX/OLE
>components can, like transferring all of your lucre to an offshore
>account or nuking your box or network.
From what I've read about OpenDoc, it doesn't address this at all. There
are no bounds on what a part, at least one that's written in a non-Java
language, can do -- aside from what the operating system imposes on the
process or thread that it's running in. This is exactly the same constraint
as ActiveX/OLE.
Dale Pontius
In article <rpk-ya023480001...@news.std.com>,
Except that OpenDoc editors were items that YOU installed on YOUR
machine, they didn't get there through some form of 'autodownload
magic'. Code I have installed on MY machine, I at least have some
level of trust in.
At some point OpenDoc components may be autodownloaded, but at
that point I would hope they're either JavaBeans, subject to that
form of authentication. Or that when OpenDoc has those capabilities
it will include some form of verification BY DEFAULT.
Dale Pontius
(NOT speaking for IBM)
Robert P. Krajewski
In article <59mal0$f...@mdnews.btv.ibm.com>, pon...@btv.ibm.com (Dale
Pontius) wrote:
>In article <rpk-ya023480001...@news.std.com>,
> r...@world.std.com (Robert P. Krajewski) writes:
>> In article <32B059...@worldnet.att.net>, Robert Morgan
>> <rkm-...@worldnet.att.net> wrote:
>>
>>>For starters, it can't write "nasties" to your disk like ActiveX/OLE
>>>components can, like transferring all of your lucre to an offshore
>>>account or nuking your box or network.
>>
>> From what I've read about OpenDoc, it doesn't address this at all. There
>> are no bounds on what a part, at least one that's written in a non-Java
>> language, can do -- aside from what the operating system imposes on the
>> process or thread that it's running in. This is exactly the same constraint
>> as ActiveX/OLE.
>
>Except that OpenDoc editors were items that YOU installed on YOUR
>machine, they didn't get there through some form of 'autodownload
>magic'. Code I have installed on MY machine, I at least have some
>level of trust in.
By default, in Internet Explorer, *all* Active X components that can be
downloaded must be signed, and IE itself will alert you that a component
(with a given name) from vendor so-and-so can be downloaded on your
machine. Really, the only different between that and software that you
install yourself is the amount time you spend deciding whether to do it
(i.e., instant download vs. deciding whether you want to go out there, use
FTP, restart your browser, etc.).
Tell me, how to you know your Telnet and e-mail applications aren't doing
nasty things *now* ? They could be sending passwords back to malicious
agents. The answer of course, is trust: you assume that the authors of NCSA
Telnet and Eudora aren't out to fleece users. Example: Eudora could bcc
*every* piece of mail you send out with no noticeable impact on the network
traffic during the SMTP session used to send the message to its intended
recipients. The fact is, Active X downloading does not introduce new
security issues; it just makes existing issues more urgent because of the
ease with which ActiveXs can be installed.
Again, it is easy to write an OpenDoc part that is capable of "transferring
all of your lucre to an offshore account or nuking your box or network";
unless the OS has security, trust is the only mechanism for safeguarding
your data and privacy. For example, I can write an Active X or OpenDoc part
(or application -- it doesn't matter) for MacOS or Windows 95 that can
scribble over your hard disk, but I can't write one that does that under
Windows NT (or Unix, and probably OS/2) because user processes can't write
to the hard disk directly. The OS matters more than the component
architecture, so MacOS and Windows 95 are wide-open to attacks from code
that makes it way onto the system through *any* mechanism.
Really, the only code you can trust is code you develop yourself, assuming,
of course, you trust yourself. And even then you've go to trust the authors
of the facilities you use, including libraries, other cooperating
applications, and the OS.
It is true that code signing is not really a total security solution, but,
it is better than nothing. First, you know that the software is really from
where is says it's from. Second, you know that is was not tinkered with by
a hacker, or corrupted in transit (this is because a digital signature is
essentially a checksum that has been encrypted with the author's private
RSA key). These are properties of software that you can't always rely on in
an untrustworthy environment.
>At some point OpenDoc components may be autodownloaded, but at
>that point I would hope they're either JavaBeans, subject to that
>form of authentication. Or that when OpenDoc has those capabilities
>it will include some form of verification BY DEFAULT.
Again, Active Xs that are downloaded by MSIE are always verified. Even if a
user could turn it off from his desktop, an administrator could prevent
that from happening.
As an inside, one security/stability problem that both current OpenDoc
parts and Active X's, OCXs, and in-process OLE servers share is that when
they get OS exceptions, the container will most likely be unable to recover
from the error. One bad part crashes the whole application. All of these
things live in the same process space, and when the container calls into
the part/server/control, it's still the same thread and the same call
stack. And, when they are written in native code, that can read anything in
the process' address space. (And for most OSs, dividing up a single
process' address space by security attributes isn't easy. This is one place
where Java wins.)
A general and OpenDoc-centric way of solving the problem could work like
this: parts (in native code) could voluntarily give up certain OS
privileges, like reading or writing to the file system. The OS would then
run the part in a downgraded security context (different thread in the same
process space, most likely), such that if such operations were attempted, a
fault would occur. OpenDoc operations that really were implemented in terms
of operations seemed "dangerous" like doing file IO would be sandboxed,
almost as if the SOM interfaces for those operations were like call gates
into "privileged" parts of the OpenDoc protocol/implementation.
This would not be good for parts that needed to do things like open
exisitng non-OpenDoc files for import, say, but it would be less limiting
than Java because Java applets can only call a certain set of class
operations, not neccessarily all operations that the native OS has already
deemed safe.
Robert Morgan
Robert P. Krajewski wrote:
>
"Must be signed" is the issue you're using as a defense of ActiveX?
Even Microsoft, in their non-response to this issue has admitted
that AuthentiCode will not prevent someone from attaching, via back
door, a "Nasty" to an ActiveX Control. MS stated that they _hoped_
they could tweak AuthentiCode to provide this but....
And, IE's *default* isn't a protection from that back-door
attachment of a "Nasty". If it was a protection, then Inter@ctive
Week wouldn't be making an issue out of it and MS wouldn't be so
reluctant to talk about it, would they? And, *signed* is a joke to
hackers and crackers.
*Whenever* any company is reluctant to discuss the security
pratfalls of its products except to say that they are working on a
solution without telling the public of the dangers, then I suspect
that they are crossing their fingers that nothing happens *before* a
bomb explodes; like American Express seeing a couple billion get
wired to God knows where.
"Signed" is a non-defense. And I'm not bashing MS or ActiveX, only
pointing out its deficiencies on the security front. It's all
because MS *designed* OLE to work on a desktop and its security
featurs were designed for that. It was then recycled and made into
ActiveX without a retooling of the security to the Internet. FWIW,
I posted a reference on what the MS Campus Recruiters were telling
potential recruits but declined to post it publicly lest I be
accused of "bashing"; but it was their words, not mine.
>Tell me, how to you know your Telnet and e-mail applications aren't doing
>nasty things *now* ? They could be sending passwords back to malicious
>agents. The answer of course, is trust: you assume that the authors of NCSA
>Telnet and Eudora aren't out to fleece users. Example: Eudora could bcc
>*every* piece of mail you send out with no noticeable impact on the network
>traffic during the SMTP session used to send the message to its intended
>recipients.
You cite "trust" and people "trust" MS for ActiveX security.
However, being able to attach a "nasty" to a *signed* ActiveX
Control is not MS being untrustworthy but it is instead leaving open
a back-door for "malicious agents" to do their work.
As for the other applications you cite, there are ways for malicious
agents to tweak the apps to do as you state, but I was not calling
Microsoft's "trustworthiness" into question.
As for OpenDoc viewers/editors, OD was "Built from the ground up"
regarding its intended use for distributed computing and not cobbled
together from a technology meant for desktop systems having
applications "talk" amongst each other. *Can* someone "crack" OD
security and do what you state? Anything is possible. To date, it
hasn't occurred. However, the "built-in security" (when was the
last time a Mac server had its security cracked? Last I checked the
"bounty" went unclaimed) makes it harder and the ActiveX issue has
already been documented.
>The fact is, Active X downloading does not introduce new
>security issues; it just makes existing issues more urgent because of the
>ease with which ActiveXs can be installed.
I'll concede that point and refer to my previous answer.
OLE/ActiveX needs to resolve its current security issues before it
can be presented as a safe & secure technology. In its current
incarnation it is neither and that's why a lot of IS mgrs. are
avoiding its use. Remember, Inter@ctive Week and PC Week are hardly
known as card carrying members of "MS as The Evil Empire" crowd.
* But*, I'll also state that ActiveX *does* create new security
issues, especially with the "Nasty" problem existing. What makes IS
mgrs. have "kitten fits" is that somehow security will be breached
because of something beyond their control. ActiveX Controls present
such a case.
>Again, it is easy to write an OpenDoc part that is capable of "transferring
>all of your lucre to an offshore account or nuking your box or network";
>unless the OS has security, trust is the only mechanism for safeguarding
>your data and privacy. For example, I can write an Active X or OpenDoc part
>(or application -- it doesn't matter) for MacOS or Windows 95 that can
>scribble over your hard disk, but I can't write one that does that under
>Windows NT (or Unix, and probably OS/2) because user processes can't write
>to the hard disk directly.
That is *not* the case with WinNT and ActiveX because this is
exactly the case of the ActiveX "Nasty" problem. Microsoft's *only*
response was to say (paraphrased): "Oh yeah? Look at Java..."
Responding to such an issue by saying someone else's mother wears
combat boots is not the best response. Granted, MS also stated that
they were working on a solution, but arrogance always precedes a
fall; which is what I told someone affiliated with MS was dangerous
in this case as it could harm the credibility of the entire MS
Internet Strategy. See? I was *trying* to offer them
*constructive* advice and suggestions and not "bashing".
And face it, the Win.XX OS is extremely vulnerable to security
issues, as the Russinovich example cites and which Mr. Johnson
elaborated on. Again, I'm not *bashing* but pointing out serious
issues.
As for writing an OD viewer with a "Nasty" attached, which is what
is downloaded to enable viewing of the document (the editor is not
needed for viewing), I'm sure Apple, et al, will be highly
appreciative of your example to see what changes might need to be
made to plug the hole. Heck, Club OpenDoc might even reward you,
who knows? To date, it hasn't happened with OD viewers, but it has
happened with ActiveX. Saying "I can" is different than saying "I
have". One is to be done, the other already has been done.
> The OS matters more than the component
>architecture, so MacOS and Windows 95 are wide-open to attacks from code
>that makes it way onto the system through *any* mechanism.
Components *are* "more important" than the OS in the *future* of
component and distributed computing; even though the OS security is
more important for now.
How many "nasties" have been found in OD viewers? How many other
"nasties" have infected Mac servers? How many Mac servers have had
their Internet security violated? Granted, MacOS *is* vulnerable
but it has a pretty good track record as far as security goes. And,
I guess I've been pretty fortunate as neither my network or boxes
have been breached or infected for a *very long* continuous period;
even though it's been subject to probes from remote access. "Just
luck" I guess.
>Really, the only code you can trust is code you develop yourself, assuming,
>of course, you trust yourself. And even then you've go to trust the authors
>of the facilities you use, including libraries, other cooperating
>applications, and the OS.
I have never made *trust* an issue in this "problem". You keep
going back to "trust" when I never cited it as an issue. However,
when I hear reports that a campus recruiter from the Test Division
of Microsoft saying that (paraphrased) "they write crappy code" (The
"Nasty" problem source? And MS should be careful to control what
their people say at those seminars as they never know who might be
listening) then maybe *trust* should become an issue in this
"problem". But, I didn't bring "trust" up. I'm still not bringing
it up.
>It is true that code signing is not really a total security solution, but,
>it is better than nothing. First, you know that the software is really from
where is says it's from.
Again, I've addressed this issue previously. AuthentiCode doesn't
prevent a "Nasty" being back-doored to an ActiveX Control, even one
from MS itself, and that is the crux of the "Nasty" problem. Even
MS admitted that AuthentiCode doesn't stop this. And if a "nasty"
is attached in a back-door manner, it won't matter much one way or
another except to exonerate the company/entity that originally made
the Control (if it survives whatever the Nasty does).
>Second, you know that is was not tinkered with by
>a hacker, or corrupted in transit (this is because a digital signature is
>essentially a checksum that has been encrypted with the author's private
>RSA key). These are properties of software that you can't always rely on in
>an untrustworthy environment.
This is *not* what MS said when asked about the ActiveX Control
"Nasty" Problem. Ergo, whom are we to believe? I'd like to believe
you, but MS was speaking on the record as a publicly traded company
and can't "dissemble" their statements. And no, I'm not accusing
you of "dissembling", because "dissembling" is what the SEC calls
it; I'm only stating that MS contradicted what you related. MS
*admitted* that AuthentiCode is not a solution in this case but they
are working on it to make it a solution. Until they do, *signed*
doesn't mean a bucket if warm spit as far as the Nasty problem is
concerned.
>At some point OpenDoc components may be autodownloaded, but at
>that point I would hope they're either JavaBeans, subject to that
>form of authentication. Or that when OpenDoc has those capabilities
>it will include some form of verification BY DEFAULT.
By the time there is widespread adoption of OD parts, JavaBeans,
etc. will be part of the release. Check out the Dev World site
about the "changes" Apple is incorporating into its next release.
Methinks they are already making moves to ensure that the "Nasty"
problem isn't an issue.
>Again, Active Xs that are downloaded by MSIE are always verified. Even if a
>user could turn it off from his desktop, an administrator could prevent
>that from happening.
And again, that is not what MS said when asked about the Nasty
problem.
>As an inside, one security/stability problem that both current OpenDoc
>parts and Active X's, OCXs, and in-process OLE servers share is that when
>they get OS exceptions, the container will most likely be unable to recover
>from the error. One bad part crashes the whole application. All of these
[snip]
>This would not be good for parts that needed to do things like open
>exisitng non-OpenDoc files for import, say, but it would be less limiting
>than Java because Java applets can only call a certain set of class
>operations, not neccessarily all operations that the native OS has already
>deemed safe.
All points taken into consideration and input appreciated.
Sorry if the response was so long, but I wanted to address each
point/issue in depth. I'm not part of "MS = Evil Empire" crowd, but
this entire "Nasty" problem began for me last summer when an IB
(Investment Banker for those Wall Street Challenged) related that
all WinWorld developers he was talking with were excited about was
OpenDoc and he wondered why. Then when the "Open Revolt" started
brewing over ActiveX/OLE, the "Nasty" issue came to light.
Best.
Robert K. Morgan