From: Hector Santos on
Peter Olcott wrote:


> Here is how you tell Windows not to ever swap this memory
> out.
> http://msdn.microsoft.com/en-us/library/aa366895(VS.85).aspx
>


Peter, people told you this many times. I know I did and also
indicated AWE to you and guess what so did Joe. So please act like
you discovered something new, when in in fact, this whole thing seems
just another duplicate episode.

Folks, I'm surprise Joe doesn't remembers, but check out this
incredible Peter O. vs the World thread back in December 2009!

http://groups.google.com/group/microsoft.public.vc.mfc/browse_frm/thread/661f9ebd4aadcd03

and a more flatter version to read:

http://www.eggheadcafe.com/software/aspnet/35500506/is-there-a-maximum-contig.aspx

I see people provided test code, even JOE did testing for him on
VirtualLock!

Same old stuff, same incompetence. Many of the same characters too!

WOW!

--
HLS
From: Peter Olcott on

"Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message
news:eeYnLekzKHA.2644(a)TK2MSFTNGP04.phx.gbl...
>
>
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
> news:GpGdnebGT-QCRDPWnZ2dnUVZ_h2dnZ2d(a)giganews.com...
>> Here is how you tell Windows not to ever swap this memory
>> out.
>>
>> http://msdn.microsoft.com/en-us/library/aa366895(VS.85).aspx
>
> Weren't you the one who insisted that your application
> wasn't using *virtual memory*? So why would you use this
> API for your program that doesn't use virtual memory?
> <grin>
>

I am the one that continues to insist that my application
experiences no page faults after all of its data is loaded.
Joe continues to insist that I can not count on this
behavior. I think that Joe may be wrong, but, this is a
backup plan.

> PS: I don't suppose you read the "remarks" section that
> explained about the maximum number of pages a process can
> lock?

SetProcessWorkingSetSize

>
>
> -Pete
>


From: Joseph M. Newcomer on
See below...
On Sat, 27 Mar 2010 23:22:54 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>message news:vtjtq5152v2tvhdut0oabr2ssn9bd3rfk3(a)4ax.com...
>> The models for the assessment are:
>>
>> A Webserver at a hosting site
>> A Webserver at your site
>
>No that's not it. The models for the assessment are:
>1) A Webserver at a hosting site
>2) A Webserver rented to the client at the client's site.
>
>Here is how you tell Windows not to ever swap this memory
>out.
> http://msdn.microsoft.com/en-us/library/aa366895(VS.85).aspx
****
This is news? This function has been known for 20 years, and it is also known that using
it can result in a system that is nonfunctional because nothing else can run (including
parts of the operating system, which are paged out), and also, what do you do if
VirtualLock fails, meaning it was not possible to do the locking?

And did you miss the part that said
---------------------------------
Locking pages into memory may degrade the performance of the system by reducing the
available RAM and forcing the system to swap out other critical pages to the paging file.
Each version of Windows has a limit on the maximum number of pages a process can lock.
This limit is intentionally small to avoid severe performance degradation. Applications
that need to lock larger numbers of pages must first call the SetProcessWorkingSetSize
function to increase their minimum and maximum working set sizes. The maximum number of
pages that a process can lock is equal to the number of pages in its minimum working set
minus a small overhead.
---------------------------------
By some mystical means known only to yourself, you have assumed that the only pages that
can ever be paged out are those of your application; you apparently missed the fact that
parts of the operating system itself are paged out, and that not every process or thread
that is running is your application, EVEN IF YOUR APPLICATION IS THE ONLY APPLICATION YOU
THINK IS RUNNING ON THE MACHINE! Apparently, you have never used Task Manager to inspect
ALL the processes running on your machine, or seen who owns them.

Note that admin privileges are required to set the profile to allow
SetProcessWorkingSetSize to execute and to set its limits, and you have to know what
profile option to enable. The API documentation doesn't tell you that.

I went back and read your original post, where you asked

>The one part that I do not have completely figured out is
>exactly how I can make it close to impossible for anyone to
>physically open the machine without detection.

Can I ask what "opening the machine" has to do with anything dealing with any form of
reality that could matter? Give me physical access to the machine, and I can do a LOT
without EVER opening the machine!

And do you think ISPs run vertical tower? They run "pizza box" servers (also called 1U
profile servers) which don't have easy ways to be opened, as if that has the slightest
meaning here. In why silly world does keeping me from opening the box prevent me from
stealing every piece of software on it? For that matter, if I know you are running IIS or
Apache, I can hope that you have not installed all the latest updates and use any one of
the known exploits to take over the machine, and steal every bit on it, without even
entering the place where the machine is running! Or I might try to engineer a new
exploit, if I thought the software was valuable enough! As soon as it is running on a Web
server, everything is vulnerable, and it is up to you to provide front-end security
(firewalls, etc.) to keep me out. Or, are you living in a reality where you think the way
people gain access to machines is to physically open them up?

Actually, you are behaving in your normal fashion, which is to invent a problem, think
about how it might affect you, and hypothesize some bizarre solution, when the problem and
the solution make no sense whatsoever. You act as if the only way to steal software is to
"physically open the machine without detection", when anyone who is in the business of
doing this knows the way is to "exercise privilege escalation and run arbitrary code
without detection", which is a far simpler problem (I hung out anonymously on cracker
groups when I was helping a client develop a new software security system, to see what
these people might be able to do to crack his system. The answer was that all software
security systems are trivially crackable in principle, but the one I was helping to
evaluate was merely difficult enough to protect the inexpensive software it was
incorporated into. If that software had been worth $10,000, the protection scheme would
not have been good enough). So I fail to unserstand (a) why you think opening the machine
is a topic worthy of concern and (b) why you think that your software is safe if you can
be sure the machine has not been physically opened. Both of these premises are silly, and
without basis.

And I can do a LOT with a machine if I have my hands on it, not the least of which is to
boot using special tools that let me get at the file system. And I know how to write code
to steal the object code of a running process; it is trivial. Anyone who has read the
Microsoft documentation on VirtualRead can do it! And at no point is there any
requirement to open the machine, or even have physical access to it!

Perhaps you should worry about REAL problems.
joe
****
joe
****

>
>Because you didn't get the spec right, your advice could
>not apply to the key part that is missing:
>
>Making a machine at the client site such that it is close to
>impossible for the client to get direct access to the
>executable files. The big missing piece here is how to make
>the physical security of the computer's physical encasement
>as impenetrable as possible. Even most of this is figured
>out, the key is simply detecting penetration in a very
>reliable way. This last sentence is the biggest missing
>piece. The only way that I figured out to make this work is
>much more clumsy than I would like.
>
>So if you have any ideas on how to make physical access to
>the computer internals infeasibly undetectable for anyone
>lacking a $100,000 budget, I would like to know. I will
>also carefully study your other advice below:
>
>>
>> The parameters are:
>>
>> Firewalls implemented using conventional operating systems
>> (such as Unix/linux)
>> Firewalls implemented using network operating systems
>> (e.g. Cisco)
>> Firewalls implemented in proprietary dedicated hardware
>> (e.g., SonicWall, LinkSys)
>> Firewalls run on the hosting operating system (Black Ice,
>> Microsoft Firewall)
>>
>> what the firewalls detect and protect you from
>>
>> Harware protection against common exploits (e.g.,
>> no-execute stack segments)
>> Software protection against common exploits
>>
>> Note that a configuration with a oouple layers of
>> front-end firewalls is going to be more
>> secure than a configuration without these, no matter where
>> it is located. If it is at
>> your site, YOU are responsible for reading the event logs
>> from all these firewalls, every
>> day, to see what attcks are being mounted against you. If
>> you host at an ISP, the ISP is
>> doing this for you. And they armortize the cost of this
>> over all their customers, meaning
>> whatever they are charging you, it is a whopping lot less
>> than it would cost you to do it
>> yourself.
>>
>> Physical security at the hosting site is not your problem.
>> They supposedly give you
>> guarantees about their physical security. I've had a tour
>> of my ISP's hosting site.
>> There's a lot of physical security, including several
>> levels of code-locked doors between
>> the street and my server. And to physically attack my
>> server, you not only have to pass
>> through all the doors, you need to figure out which of the
>> several hundred machines on
>> that site is my server, and whatever you plan to do to it
>> will take more time than the
>> response time of the police to a report of a security
>> breach. Or have you rededfined
>> "physical security" to mean something other than what the
>> rest of us recognize? (Note that
>> you are talking to someone who was responsible for the
>> physical security of our computer
>> room at our company; I specified and supervised the
>> installation of the system, as well as
>> the HVAC, power conditioning, and fire supression systems,
>> and I was the one who
>> specified, ordered, and supervised the installation of a
>> secure development facility in
>> our site that had to pass rigid third-party security
>> standards [specifically, those of IBM
>> who was giving us a top-secret development contract for an
>> unannounced product], so I know
>> something about physical security)
>> joe
>
>Yes for my web server I will simply be using conventional
>means. I will trust my provider for the physical security.
>
>>
>> On Fri, 26 Mar 2010 15:38:38 -0500, "Peter Olcott"
>> <NoSpam(a)OCR4Screen.com> wrote:
>>
>>>
>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>>>message news:hr2qq5tb9p5rlkk8vdetjlkusv3fk9n7cd(a)4ax.com...
>>>> See below...
>>>> On Fri, 26 Mar 2010 13:31:36 -0500, "Peter Olcott"
>>>> <NoSpam(a)OCR4Screen.com> wrote:
>>>>
>>>>>
>>>>>"Tom Serface" <tom(a)camaswood.com> wrote in message
>>>>>news:OxTzNBRzKHA.264(a)TK2MSFTNGP05.phx.gbl...
>>>>>> We just use IIS for our intranet web applications. We
>>>>>> can
>>>>>> install it on our servers as they are manufactured and
>>>>>> it's really easy to set up.
>>>>>>
>>>>>> There are restrictions to doing web applications of
>>>>>> course, but you can do a lot of coding server-side if
>>>>>> you
>>>>>> know the server will have access and permission to
>>>>>> update
>>>>>> areas on the intranet.
>>>>>>
>>>>>> Tom
>>>>>
>>>>>My trick is to make this web server installed a the
>>>>>client
>>>>>site have as close to as possible impenetrable security
>>>>>because I am adding trade secret to my intellectual
>>>>>property
>>>>>protection. I think that I have this essentially figured
>>>>>out.
>>>>>
>>>>>The one part that I do not have completely figured out
>>>>>is
>>>>>exactly how I can make it close to impossible for anyone
>>>>>to
>>>>>physically open the machine without detection. I have
>>>>>figured out ways to make this mostly (but not
>>>>>completely)
>>>>>moot. I have also figured out ways to make case access
>>>>>security extremely difficult to circumvent.
>>>> ***
>>>> The Standard Model of physical security goes like this:
>>>>
>>>> It is buried twelve feet deep in a 3-foot-thick concrete
>>>> vault in the middle of an active
>>>> artillery range in the middle of a secure military base.
>>>>
>>>> For dead-certain security, there are no wires leading
>>>> into
>>>> it, and it is turned off, and
>>>> there is no nearby power supply.
>>>>
>>>> Another model surrounds it by vicious pit bulls, but
>>>> unless you have done background
>>>> checks on the pit bulls, you cannot really be sure this
>>>> is
>>>> safe. One of them might be in
>>>> the pay of your competitor. A pound of prime rib can
>>>> buy
>>>> a lot of loyalty in a pit bull.
>>>>
>>>> The simplest model is that you, personally, guard the
>>>> machine, armed with some illegal
>>>> automatic weapon. That's 24/7, so don't plan on
>>>> sleeping,
>>>> eating, or dealing with bodily
>>>> functions.
>>>>
>>>> All other methods are not considered trustworthy in the
>>>> absolute sense.
>>>>
>>>> [A friend once had a tour of the NSA. In one room,
>>>> inside
>>>> a Faraday cage, there was a
>>>> battery power supply running a PDP-11 with a hard drive
>>>> attached. And a Marine guard,
>>>> armed with a .45 pistol. His orders: should anyone
>>>> attempt to enter the room by force, he
>>>> was to draw his weapon, and shoot the disk. Now THAT'S
>>>> physical security!]
>>>>
>>>> Physical access is not your problem; this is the problem
>>>> of your ISP, and their physical
>>>> security system. This is what you are paying for. Not
>>>> just a CPU, a bit of wire, and a
>>>> UPS system!
>>>> joe
>>>
>>>Two different things are being assessed:
>>>(1) Webserver on the internet
>>>(2) A webserver rented to the client at the client's
>>>location.
>>>
>>>I spoke to Phil Zimmerman about his stuff once, this seems
>>>like it could form one essential element of a sufficient
>>>basis.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in
>>>>>> message
>>>>>> news:toydnSprNqitejHWnZ2dnUVZ_sidnZ2d(a)giganews.com...
>>>>>>>
>>>>>>> "Tom Serface" <tom(a)camaswood.com> wrote in message
>>>>>>> news:uiYs3GQzKHA.5040(a)TK2MSFTNGP02.phx.gbl...
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>> I don't think the proximity is the only gating
>>>>>>>> factor.
>>>>>>>> Bandwidth for connected servers, the path of the
>>>>>>>> data,
>>>>>>>> etc. all matter. If your users are directly
>>>>>>>> connecting
>>>>>>>> to your server it may make a difference. It must
>>>>>>>> make
>>>>>>>> some sort of difference because every professional
>>>>>>>> download site I know of has multiple "mirror" sites
>>>>>>>> so
>>>>>>>> that you can select one closest to you. If nothing
>>>>>>>> else, distributing it may make some people use other
>>>>>>>> servers and spread the cycles needed to read and
>>>>>>>> send
>>>>>>>> the data off a little less arduous.
>>>>>>>>
>>>>>>>> Tom
>>>>>>>
>>>>>>> Yes, and it also just occured to me that in special
>>>>>>> cases
>>>>>>> I may even be able to provide an intranet webserver.
>>>>>>>
>>>>>
>>>> Joseph M. Newcomer [MVP]
>>>> email: newcomer(a)flounder.com
>>>> Web: http://www.flounder.com
>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on
Pete Delgado wrote:

> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message

>> Here is how you tell Windows not to ever swap this memory out.
>> http://msdn.microsoft.com/en-us/library/aa366895(VS.85).aspx
>
> Weren't you the one who insisted that your application wasn't using *virtual
> memory*? So why would you use this API for your program that doesn't use
> virtual memory? <grin>


He has a backup plan just in case he needs to run OE for technical
support. :)

> PS: I don't suppose you read the "remarks" section that explained about the
> maximum number of pages a process can lock?

And spoil the new "Ah ha" discovery!? The Devil is NOT in the Details!
- it gets in his way. Reading the 2nd half of a single book or any
material is not his bag. <g>

--
HLS
From: Hector Santos on
Joe,

For peter o, the devil is NOT in the details.

--
HLS

Joseph M. Newcomer wrote:

> See below...
> On Sat, 27 Mar 2010 23:22:54 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:
>
>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>> message news:vtjtq5152v2tvhdut0oabr2ssn9bd3rfk3(a)4ax.com...
>>> The models for the assessment are:
>>>
>>> A Webserver at a hosting site
>>> A Webserver at your site
>> No that's not it. The models for the assessment are:
>> 1) A Webserver at a hosting site
>> 2) A Webserver rented to the client at the client's site.
>>
>> Here is how you tell Windows not to ever swap this memory
>> out.
>> http://msdn.microsoft.com/en-us/library/aa366895(VS.85).aspx
> ****
> This is news? This function has been known for 20 years, and it is also known that using
> it can result in a system that is nonfunctional because nothing else can run (including
> parts of the operating system, which are paged out), and also, what do you do if
> VirtualLock fails, meaning it was not possible to do the locking?
>
> And did you miss the part that said
> ---------------------------------
> Locking pages into memory may degrade the performance of the system by reducing the
> available RAM and forcing the system to swap out other critical pages to the paging file.
> Each version of Windows has a limit on the maximum number of pages a process can lock.
> This limit is intentionally small to avoid severe performance degradation. Applications
> that need to lock larger numbers of pages must first call the SetProcessWorkingSetSize
> function to increase their minimum and maximum working set sizes. The maximum number of
> pages that a process can lock is equal to the number of pages in its minimum working set
> minus a small overhead.
> ---------------------------------
> By some mystical means known only to yourself, you have assumed that the only pages that
> can ever be paged out are those of your application; you apparently missed the fact that
> parts of the operating system itself are paged out, and that not every process or thread
> that is running is your application, EVEN IF YOUR APPLICATION IS THE ONLY APPLICATION YOU
> THINK IS RUNNING ON THE MACHINE! Apparently, you have never used Task Manager to inspect
> ALL the processes running on your machine, or seen who owns them.
>
> Note that admin privileges are required to set the profile to allow
> SetProcessWorkingSetSize to execute and to set its limits, and you have to know what
> profile option to enable. The API documentation doesn't tell you that.
>
> I went back and read your original post, where you asked
>
>> The one part that I do not have completely figured out is
>> exactly how I can make it close to impossible for anyone to
>> physically open the machine without detection.
>
> Can I ask what "opening the machine" has to do with anything dealing with any form of
> reality that could matter? Give me physical access to the machine, and I can do a LOT
> without EVER opening the machine!
>
> And do you think ISPs run vertical tower? They run "pizza box" servers (also called 1U
> profile servers) which don't have easy ways to be opened, as if that has the slightest
> meaning here. In why silly world does keeping me from opening the box prevent me from
> stealing every piece of software on it? For that matter, if I know you are running IIS or
> Apache, I can hope that you have not installed all the latest updates and use any one of
> the known exploits to take over the machine, and steal every bit on it, without even
> entering the place where the machine is running! Or I might try to engineer a new
> exploit, if I thought the software was valuable enough! As soon as it is running on a Web
> server, everything is vulnerable, and it is up to you to provide front-end security
> (firewalls, etc.) to keep me out. Or, are you living in a reality where you think the way
> people gain access to machines is to physically open them up?
>
> Actually, you are behaving in your normal fashion, which is to invent a problem, think
> about how it might affect you, and hypothesize some bizarre solution, when the problem and
> the solution make no sense whatsoever. You act as if the only way to steal software is to
> "physically open the machine without detection", when anyone who is in the business of
> doing this knows the way is to "exercise privilege escalation and run arbitrary code
> without detection", which is a far simpler problem (I hung out anonymously on cracker
> groups when I was helping a client develop a new software security system, to see what
> these people might be able to do to crack his system. The answer was that all software
> security systems are trivially crackable in principle, but the one I was helping to
> evaluate was merely difficult enough to protect the inexpensive software it was
> incorporated into. If that software had been worth $10,000, the protection scheme would
> not have been good enough). So I fail to unserstand (a) why you think opening the machine
> is a topic worthy of concern and (b) why you think that your software is safe if you can
> be sure the machine has not been physically opened. Both of these premises are silly, and
> without basis.
>
> And I can do a LOT with a machine if I have my hands on it, not the least of which is to
> boot using special tools that let me get at the file system. And I know how to write code
> to steal the object code of a running process; it is trivial. Anyone who has read the
> Microsoft documentation on VirtualRead can do it! And at no point is there any
> requirement to open the machine, or even have physical access to it!
>
> Perhaps you should worry about REAL problems.
> joe
> ****
> joe
> ****
>
>> Because you didn't get the spec right, your advice could
>> not apply to the key part that is missing:
>>
>> Making a machine at the client site such that it is close to
>> impossible for the client to get direct access to the
>> executable files. The big missing piece here is how to make
>> the physical security of the computer's physical encasement
>> as impenetrable as possible. Even most of this is figured
>> out, the key is simply detecting penetration in a very
>> reliable way. This last sentence is the biggest missing
>> piece. The only way that I figured out to make this work is
>> much more clumsy than I would like.
>>
>> So if you have any ideas on how to make physical access to
>> the computer internals infeasibly undetectable for anyone
>> lacking a $100,000 budget, I would like to know. I will
>> also carefully study your other advice below:
>>
>>> The parameters are:
>>>
>>> Firewalls implemented using conventional operating systems
>>> (such as Unix/linux)
>>> Firewalls implemented using network operating systems
>>> (e.g. Cisco)
>>> Firewalls implemented in proprietary dedicated hardware
>>> (e.g., SonicWall, LinkSys)
>>> Firewalls run on the hosting operating system (Black Ice,
>>> Microsoft Firewall)
>>>
>>> what the firewalls detect and protect you from
>>>
>>> Harware protection against common exploits (e.g.,
>>> no-execute stack segments)
>>> Software protection against common exploits
>>>
>>> Note that a configuration with a oouple layers of
>>> front-end firewalls is going to be more
>>> secure than a configuration without these, no matter where
>>> it is located. If it is at
>>> your site, YOU are responsible for reading the event logs
>>> from all these firewalls, every
>>> day, to see what attcks are being mounted against you. If
>>> you host at an ISP, the ISP is
>>> doing this for you. And they armortize the cost of this
>>> over all their customers, meaning
>>> whatever they are charging you, it is a whopping lot less
>>> than it would cost you to do it
>>> yourself.
>>>
>>> Physical security at the hosting site is not your problem.
>>> They supposedly give you
>>> guarantees about their physical security. I've had a tour
>>> of my ISP's hosting site.
>>> There's a lot of physical security, including several
>>> levels of code-locked doors between
>>> the street and my server. And to physically attack my
>>> server, you not only have to pass
>>> through all the doors, you need to figure out which of the
>>> several hundred machines on
>>> that site is my server, and whatever you plan to do to it
>>> will take more time than the
>>> response time of the police to a report of a security
>>> breach. Or have you rededfined
>>> "physical security" to mean something other than what the
>>> rest of us recognize? (Note that
>>> you are talking to someone who was responsible for the
>>> physical security of our computer
>>> room at our company; I specified and supervised the
>>> installation of the system, as well as
>>> the HVAC, power conditioning, and fire supression systems,
>>> and I was the one who
>>> specified, ordered, and supervised the installation of a
>>> secure development facility in
>>> our site that had to pass rigid third-party security
>>> standards [specifically, those of IBM
>>> who was giving us a top-secret development contract for an
>>> unannounced product], so I know
>>> something about physical security)
>>> joe
>> Yes for my web server I will simply be using conventional
>> means. I will trust my provider for the physical security.
>>
>>> On Fri, 26 Mar 2010 15:38:38 -0500, "Peter Olcott"
>>> <NoSpam(a)OCR4Screen.com> wrote:
>>>
>>>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>>>> message news:hr2qq5tb9p5rlkk8vdetjlkusv3fk9n7cd(a)4ax.com...
>>>>> See below...
>>>>> On Fri, 26 Mar 2010 13:31:36 -0500, "Peter Olcott"
>>>>> <NoSpam(a)OCR4Screen.com> wrote:
>>>>>
>>>>>> "Tom Serface" <tom(a)camaswood.com> wrote in message
>>>>>> news:OxTzNBRzKHA.264(a)TK2MSFTNGP05.phx.gbl...
>>>>>>> We just use IIS for our intranet web applications. We
>>>>>>> can
>>>>>>> install it on our servers as they are manufactured and
>>>>>>> it's really easy to set up.
>>>>>>>
>>>>>>> There are restrictions to doing web applications of
>>>>>>> course, but you can do a lot of coding server-side if
>>>>>>> you
>>>>>>> know the server will have access and permission to
>>>>>>> update
>>>>>>> areas on the intranet.
>>>>>>>
>>>>>>> Tom
>>>>>> My trick is to make this web server installed a the
>>>>>> client
>>>>>> site have as close to as possible impenetrable security
>>>>>> because I am adding trade secret to my intellectual
>>>>>> property
>>>>>> protection. I think that I have this essentially figured
>>>>>> out.
>>>>>>
>>>>>> The one part that I do not have completely figured out
>>>>>> is
>>>>>> exactly how I can make it close to impossible for anyone
>>>>>> to
>>>>>> physically open the machine without detection. I have
>>>>>> figured out ways to make this mostly (but not
>>>>>> completely)
>>>>>> moot. I have also figured out ways to make case access
>>>>>> security extremely difficult to circumvent.
>>>>> ***
>>>>> The Standard Model of physical security goes like this:
>>>>>
>>>>> It is buried twelve feet deep in a 3-foot-thick concrete
>>>>> vault in the middle of an active
>>>>> artillery range in the middle of a secure military base.
>>>>>
>>>>> For dead-certain security, there are no wires leading
>>>>> into
>>>>> it, and it is turned off, and
>>>>> there is no nearby power supply.
>>>>>
>>>>> Another model surrounds it by vicious pit bulls, but
>>>>> unless you have done background
>>>>> checks on the pit bulls, you cannot really be sure this
>>>>> is
>>>>> safe. One of them might be in
>>>>> the pay of your competitor. A pound of prime rib can
>>>>> buy
>>>>> a lot of loyalty in a pit bull.
>>>>>
>>>>> The simplest model is that you, personally, guard the
>>>>> machine, armed with some illegal
>>>>> automatic weapon. That's 24/7, so don't plan on
>>>>> sleeping,
>>>>> eating, or dealing with bodily
>>>>> functions.
>>>>>
>>>>> All other methods are not considered trustworthy in the
>>>>> absolute sense.
>>>>>
>>>>> [A friend once had a tour of the NSA. In one room,
>>>>> inside
>>>>> a Faraday cage, there was a
>>>>> battery power supply running a PDP-11 with a hard drive
>>>>> attached. And a Marine guard,
>>>>> armed with a .45 pistol. His orders: should anyone
>>>>> attempt to enter the room by force, he
>>>>> was to draw his weapon, and shoot the disk. Now THAT'S
>>>>> physical security!]
>>>>>
>>>>> Physical access is not your problem; this is the problem
>>>>> of your ISP, and their physical
>>>>> security system. This is what you are paying for. Not
>>>>> just a CPU, a bit of wire, and a
>>>>> UPS system!
>>>>> joe
>>>> Two different things are being assessed:
>>>> (1) Webserver on the internet
>>>> (2) A webserver rented to the client at the client's
>>>> location.
>>>>
>>>> I spoke to Phil Zimmerman about his stuff once, this seems
>>>> like it could form one essential element of a sufficient
>>>> basis.
>>>>
>>>>>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in
>>>>>>> message
>>>>>>> news:toydnSprNqitejHWnZ2dnUVZ_sidnZ2d(a)giganews.com...
>>>>>>>> "Tom Serface" <tom(a)camaswood.com> wrote in message
>>>>>>>> news:uiYs3GQzKHA.5040(a)TK2MSFTNGP02.phx.gbl...
>>>>>>>>> Hi Peter,
>>>>>>>>>
>>>>>>>>> I don't think the proximity is the only gating
>>>>>>>>> factor.
>>>>>>>>> Bandwidth for connected servers, the path of the
>>>>>>>>> data,
>>>>>>>>> etc. all matter. If your users are directly
>>>>>>>>> connecting
>>>>>>>>> to your server it may make a difference. It must
>>>>>>>>> make
>>>>>>>>> some sort of difference because every professional
>>>>>>>>> download site I know of has multiple "mirror" sites
>>>>>>>>> so
>>>>>>>>> that you can select one closest to you. If nothing
>>>>>>>>> else, distributing it may make some people use other
>>>>>>>>> servers and spread the cycles needed to read and
>>>>>>>>> send
>>>>>>>>> the data off a little less arduous.
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>> Yes, and it also just occured to me that in special
>>>>>>>> cases
>>>>>>>> I may even be able to provide an intranet webserver.
>>>>>>>>
>>>>> Joseph M. Newcomer [MVP]
>>>>> email: newcomer(a)flounder.com
>>>>> Web: http://www.flounder.com
>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer(a)flounder.com
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm



--
HLS