Re: run a program in memory , not from hard
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:fifjt3h3r9bou27irl1ok1t9oc6npdn1dp@4ax.com...
What I was saying is that the notion of "personal" computer is changing,
and the software
needs to adapt to those changes. In 1979, it was felt "acceptable" to
reboot your
personal machine whenever a program started doing something you didn't
like. Because it
was your "personal" machine. Uptime wasn't even a parameter that entered
the discussion
for these people, and I found it incomprehensible that they could not
understand the
notion.
I'm saying the same analogy holds true today: if it is my "personal"
machine, I should
control what happens on it. If I don't like your hook being in place in
my Word document,
I should be able to say "this hook is not permitted in this executable"
and that should be
a supported concept. I should be able to say "only these programs are
permitted to access
my file system" and excluded from that set by default is every possible
download off the
Internet, no exceptions. Then, I might say "Downloads from the Microsoft
Update site are
permitted to touch this, this, and this directory". Point is, if it is
"personal"
computer, I should be able to control EXACTLY what is going on, at all
times. By allowing
me to set policies myself, I can establish the bounds of what I'm willing
to accept.
The argument that some program might be doing something useful by placing
a hook is
interesting, but only if you believe security is not an issue worth
discussing. A
system-wide hook has to give be a suitable return-for-risk. I actually
*like* the idea
that no program can set a hook without my permission; I should be able to
create a policy
that says which specific programs are permitted to set hooks, and on a
executable-by-executable basis permit or preclude the setting of hooks.
If I lose
funcitonality, it is *my* decision to lose it (it is, after all, my
"personal" machine and
I should make the choices)
Right now, I have to block all forms of scripting because, basically,
scripting is
untrustworthy; after having been taken out by a couple attacks, for a
total downtime of
over 10 days, no amount of functionality is going to compensate for
another network-wide
deworming experience. But if I can reliably control what is happening, on
a site-by-site,
in fact, a URL-by-URL permission level, I can feel confident that I can
tell what is going
on. My default would be to block every script of any sort from touching
my file system or
Registry, and start to relax the restrictions for specific needs. Only
then is my
"personal" computer mine again.
Security was not a parameter of the design of Windows, the same as uptime
was not a
parameter of the design of early "personal workstation" software. Today,
we can view that
1979 attitude as "quaint" and certainly inappropriate; so why is security
now felt to be
the same kind of issue? I don't want to have to wait 20 years for people
to say "You
know, he was right all along..." (Sad thing is, I've been saying this
already for 20
years...)
joe
Even though you're defining personal computing as "freedom to prohibit" and
I am defining it as "freedom to customize", we are pretty much in agreement.
I really have no fundamental issue with your promoting a policy of defining
the conditions under which a hook would be injected. I would make a few
observations:
1) Such a policy would fail in the consumer marketplace because people are
not capable of answering the question e.g. "mssysmgr.exe would like to
inject a WM_GETMESAGE hook into all of your programs; permit this or not?"
2) Even if they did know, they would hate the popups just like they hate
Vista UAC prompts; and
3) You really do have the policy already by choosing to run the
hook-setting program or not.
What I had an issue with was your saying, "no sane OS should have the
capability [of allowing hooks]". As long as we're clear that you're not
advocating removing hooks, and instead are advocating a policy by which they
can be restricted, we agree.
Thanks,
David