How to block system copy commands at driver level
Bipin Mistry
How can I trace following System Copy commands and block them, so as
secured folder/drive do not react to these commands.
1. [Ctrl + C],
2. Right Click Menu -> Copy
3. File Menu -> Copy
4. Command prompt copy
As per me all above command will be calling a single rutine process at
driver level.
I am unable to identify which rutine dose it call & how can I identify
that the any of above 4 are triggered.
During my RnD till now I reached till IRP_MJ_READ & WRITE where by
related parameters and their properties do not describe about COPY in
specifically.
Some place I read about this can be posible with keeping watch on
Clipboard, dont know how much this will be useful, as there was no
extra informaiton was provided.
If any one can help me out for this situation then please do share
your knowledge with me.
Best regards,
Bipin
David Craig
I guess there is someone out there hiring companies to implement an
anti-copy driver. Maybe they are offering a large completion payment with
nothing until it is done. The answer is NO. Until you learn how Windows
works, you cannot prevent copying and you can't understand why it cannot be
done. I can think of only one solution for Windows and it is not practical.
The other choice is to write your own OS that has different rules.
Put the data to be protected in a directory. Encrypt that directory's files
with a symmetric key or multiple keys. Store those keys on a SmartCard
protected with the public key used to encrypt them before they are added.
Issue a CD/DVD/USB drive with the files on it, a SmartCard reader, & the
fully initialized SmartCard. Write an application that permits the files to
be viewed, but does not respond to any key strokes that might copy the data
in the viewer. That still won't protect against cameras or screen capture
programs, but it is about as good as it can be done. You need a separate
encryption key for each copy of the files to provide post compromise
security. If you try and use normal programs such as Notepad, Wordpad, or
Word the data must be placed in plaintext in the buffers where another
driver can obtain access easily. The Windows filesystems just don't work if
encryption is done closer to the application unless it is within the
application's context as part of its code or an injected DLL.
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:6a3688db-4c57-4671...@s33g2000pri.googlegroups.com...
Bipin Mistry
Up to the extent I agree with you that this task can not be done
unless we know how Windows works with these events at low level.
> Put the data to be protected in a directory. Encrypt that directory's files
> with a symmetric key or multiple keys. Store those keys on a SmartCard
> protected with the public key used to encrypt them before they are added.
> Issue a CD/DVD/USB drive with the files on it, a SmartCard reader, & the
> fully initialized SmartCard. Write an application that permits the files to
> be viewed, but does not respond to any key strokes that might copy the data
> in the viewer.
I also do agree as am currently working on bit similer system, now
requirements dose says that copy protection for basic copy commands
need to be ignored/blocked when such restricted data are concerned.
If you have / come accross to know about any thing that can help me
then please do post it, so as I can work arround & complete my task.
Bipin
On May 23, 4:21 pm, "David Craig" <driv...@nowhere.us> wrote:
> This question has been asked and answered many times in the last few months.
> I guess there is someone out there hiring companies to implement an
> anti-copy driver. Maybe they are offering a large completion payment with
> nothing until it is done. The answer is NO. Until you learn how Windows
> works, you cannot prevent copying and you can't understand why it cannot be
> done. I can think of only one solution for Windows and it is not practical.
> The other choice is to write your own OS that has different rules.
>
> Put the data to be protected in a directory. Encrypt that directory's files
> with a symmetric key or multiple keys. Store those keys on a SmartCard
> protected with the public key used to encrypt them before they are added.
> Issue a CD/DVD/USB drive with the files on it, a SmartCard reader, & the
> fully initialized SmartCard. Write an application that permits the files to
> be viewed, but does not respond to any key strokes that might copy the data
> in the viewer. That still won't protect against cameras or screen capture
> programs, but it is about as good as it can be done. You need a separate
> encryption key for each copy of the files to provide post compromise
> security. If you try and use normal programs such as Notepad, Wordpad, or
> Word the data must be placed in plaintext in the buffers where another
> driver can obtain access easily. The Windows filesystems just don't work if
> encryption is done closer to the application unless it is within the
> application's context as part of its code or an injected DLL.
>
> "Bipin Mistry" <bpnmis...@gmail.com> wrote in message
>
> news:6a3688db-4c57-4671...@s33g2000pri.googlegroups.com...
>
>
>
> > Hello,
>
> > How can I trace following System Copy commands and block them, so as
> > secured folder/drive do not react to these commands.
>
> > 1. [Ctrl + C],
> > 2. Right Click Menu -> Copy
> > 3. File Menu -> Copy
> > 4. Command prompt copy
>
> > As per me all above command will be calling a single rutine process at
> > driver level.
> > I am unable to identify which rutine dose it call & how can I identify
> > that the any of above 4 are triggered.
>
> > During my RnD till now I reached till IRP_MJ_READ & WRITE where by
> > related parameters and their properties do not describe about COPY in
> > specifically.
>
> > Some place I read about this can be posible with keeping watch on
> > Clipboard, dont know how much this will be useful, as there was no
> > extra informaiton was provided.
>
> > If any one can help me out for this situation then please do share
> > your knowledge with me.
>
> > Best regards,
> > Bipin- Hide quoted text -
>
> - Show quoted text -
Don Burn
see are reads and writes, there is no concept of copying at the kernel
level. So unless you want to make a file so it cannot be read (which makes
it rather useless) you cannot stop copying. Go to http://www.osronline.com/
and join the NTFSD newsgroup, and then start reading the archives, this has
been discussed way too many times.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:7b8f425d-e3c1-41c5...@l17g2000pri.googlegroups.com...
Alexander Grigoriev
read the file, you cannot copy it, then the file just like it does not exist
for you, you can't see its contents. No File, no copy. Have file, can read
it, can copy. So simple.
The best thing you can do is to disable write to removeable devices, or to
disable them altogether. Search MS Kludge^H^H^H^H^^HKnowlegebase for that.
And only enable launch of approved applications.
Customers who order such kind of things again and again just don't
understand it. They just ask to implement wrong solution for a problem.
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:6a3688db-4c57-4671...@s33g2000pri.googlegroups.com...
Eugene Mayevski
You wrote on Fri, 23 May 2008 00:49:11 -0700 (PDT):
BM> I also do agree as am currently working on bit similer system, now
BM> requirements dose says that copy protection for basic copy commands
BM> need to be ignored/blocked when such restricted data are concerned.
BM> If you have / come accross to know about any thing that can help me
BM> then please do post it, so as I can work arround & complete my task.
While you can't restrict copying, you can control, what processes are
allowed to open the file and so restrict copying.
Check this article: http://eldos.com/solfs/articles/5016.php
With best regards,
Eugene Mayevski
http://mayevski.blogspot.com/
Maxim S. Shatskih
creation.
The idea is futile.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:6a3688db-4c57-4671...@s33g2000pri.googlegroups.com...
Bipin Mistry
Thanks for the valuable suggesions & reference,
I know it itches when some thing can not be done when it is part of
project...
As per me, till the level of RnD I have done also concludes that at
driver level there is only File READ / WRITE commands.
Where COPY can not be identyfied,
But, as per me, As for User, Where File Create & File Copy are two
different commands, there should be atlist one difference between the
two so as OS also can identify that what is Create & what is Copy.
If it is not at driver level then I / We need to search out as to what
level this can be identified & handeled.
And can this be intigrated with the driver level code / applicaiton or
not.
If any one has any knowhow over this ground then suggessions please.
As of till then I am stil in search of the ways how this can be worked
out.
If not on driver level then Where... & How ?
will keep on posting my end progress at here...
Bipin
On May 24, 9:17 am, "Maxim S. Shatskih" <ma...@storagecraft.com>
wrote:
> At driver level, you cannot distinguish the copy from the new file
> creation.
>
> The idea is futile.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> ma...@storagecraft.comhttp://www.storagecraft.com
>
> "Bipin Mistry" <bpnmis...@gmail.com> wrote in message
>
> news:6a3688db-4c57-4671...@s33g2000pri.googlegroups.com...
>
>
>
> > Hello,
>
> > How can I trace following System Copy commands and block them, so as
> > secured folder/drive do not react to these commands.
>
> > 1. [Ctrl + C],
> > 2. Right Click Menu -> Copy
> > 3. File Menu -> Copy
> > 4. Command prompt copy
>
> > As per me all above command will be calling a single rutine process at
> > driver level.
> > I am unable to identify which rutine dose it call & how can I identify
> > that the any of above 4 are triggered.
>
> > During my RnD till now I reached till IRP_MJ_READ & WRITE where by
> > related parameters and their properties do not describe about COPY in
> > specifically.
>
> > Some place I read about this can be posible with keeping watch on
> > Clipboard, dont know how much this will be useful, as there was no
> > extra informaiton was provided.
>
> > If any one can help me out for this situation then please do share
> > your knowledge with me.
>
> > Best regards,
David Craig
chance as in trying to find a way to live until you are 300 years old.
Whoever hired you for this job wanted you to fail or they are too stupid to
understand how operating systems work.
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:15f1909a-7ffe-4cf3...@i18g2000prn.googlegroups.com...
Alexander Grigoriev
environment is a problem how to limit sensitive information leak. The answer
is: Limit user's options. You don't want the file to be sent? Disallow file
attachments altogether. You don't want the file to be saved to unapproved
storage? Make the storage inaccessible. If unapproved storage is accessible,
there are other ways to move sensitive information there, other than copy.
For example, attach to an email draft, save the attachment. Create a zip
file, copy it.
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:15f1909a-7ffe-4cf3...@i18g2000prn.googlegroups.com...
Alexander Grigoriev
cannot be reliable made to tell sensitive information from non-sensitive,
and selectively limit sensitive information movement. Because its
functionality is too rich, there's always a way around.
The answer could be to lock down a system severely, or create a separate
environment for sensitive information, in a virtual machine, for example. In
most severe cases, that would be a separate physical machine, in separate
room/premises.
"David Craig" <dri...@nowhere.us> wrote in message
news:eC40vdtv...@TK2MSFTNGP04.phx.gbl...
David Craig
copying becomes more difficult, if not impossible. There will always be
some trick from compression to encryption that will permit a user to take a
file and 'copy' it somewhere. Restricting the ability to create/mount
volumes can help keep files on the system especially if LAN & Internet
access is not allowed. That would also require no floppy drives, serial
ports, or parallel ports on that computer.
I include the 'shell' as supplied by Windows Explorer as part of the OS.
Seeing how unreliable and unusable the system becomes when you kill the
Explorer process, I don't think it is an unreasonable definition. I know in
Linux the shells are much less interwoven into the OS.
I still believe that keeping the files encrypted by an application that
won't permit any form of 'copying' and using SmartCards to control
decryption is a solution, but it would be a pain to work in such an
environment.
"Alexander Grigoriev" <al...@earthlink.net> wrote in message
news:ucGeGM0v...@TK2MSFTNGP05.phx.gbl...
Maxim S. Shatskih
>two so as OS also can identify that what is Create & what is Copy.
Not so. This exists only in Explorer, but there are lots of other apps to do
copies, command line, Total Commander, zip+unzip, attach to email+save
attachment, and so on.
Restricting copies with allowed reads requires tag-based security _thru the OS
and all its sofware_, which is not implemented in Windows.
Maxim S. Shatskih
> Explorer process, I don't think it is an unreasonable definition.
Not so, the shell is restarted automatically. The only issue is that the second
instance of all Run programs is started.
Alexander Grigoriev
kill it with task manager without much problems.
Instead of explorer, it's possible to use an alternate shell with severely
limited functionality, or some custom application. Some UI functions may not
be accessible then.
If someone wants to lock an environment down, for sensitive file access, you
don't want to run universal shell; only a specific application.
"David Craig" <dri...@nowhere.us> wrote in message
news:unZxTt1v...@TK2MSFTNGP02.phx.gbl...
Bipin Mistry
Thanks for all your time & valuable suggesions....
Want to provide some more infirmation on the gola that my team seeks
to achive.
1. Client has application which can mount a file & convert it to a
sepprate drive (X: Y: Z:....)
2. This file is an arkived by Client end technology.
3. we have been asked to do user based accessibility enhancement of
the current application.
4. Where by details of User & Arkived file location of the user is
located in the DB along with the user rights.
5. Where by one part of our task of enhancement includes, "User can
not coly any file from the arcived file to his/her local folder. i.e.
C: D:"
for example
A.ARC is an arkived file
PC has C: & D:
A.ARC is mounted as Z:
then details of Z: can not be copied to local drive C: D: with below
specified options.
1. [Ctrl + C],
2. Right Click Menu -> Copy
3. File Menu -> Copy
4. Command prompt copy
5. Deag & Drop
There are many other enhancement along with copy restriction...
based on the analyses & enhacement to the Client Application currently
we are restricted to Driver Level.
If we can not make any work arround for "Copy" in driver level, then
we have to provide them solution as to what way we can do it.
Aulthough the time like is fixed and we do not have much of a time to
keep on making RnD over various driver & upper layer of OS.
Seeking responce &/ suggesion for the issue.
As till now we can conclude that "Copy is certanly not posible at
Driver Level", we need to figure out some other work arround.
Bipin.
On May 27, 7:22 am, "Alexander Grigoriev" <al...@earthlink.net> wrote:
> "Explorer shell" is required for most applications, though you actually can
> kill it with task manager without much problems.
>
> Instead of explorer, it's possible to use an alternate shell with severely
> limited functionality, or some custom application. Some UI functions may not
> be accessible then.
>
> If someone wants to lock an environment down, for sensitive file access, you
> don't want to run universal shell; only a specific application.
>
> "David Craig" <driv...@nowhere.us> wrote in message
> >> "David Craig" <driv...@nowhere.us> wrote in message
> >>news:eC40vdtv...@TK2MSFTNGP04.phx.gbl...
> >>> Anything you design, I can defeat easily. You would have just as much
> >>> chance as in trying to find a way to live until you are 300 years old.
> >>> Whoever hired you for this job wanted you to fail or they are too stupid
> >>> to understand how operating systems work.
>
> >>>> - Show quoted text -- Hide quoted text -
Alexander Grigoriev
The best you can do is make the drive only accessible to an application that
runs under special security token, and prohibit local write for that token.
You'll have also prohibit write to any network share. Thus, the files will
only be readable for a process that runs with that token, but at the same
time, the token will prohibit writes to all other drives.
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:03ce4493-496b-416a...@i18g2000prn.googlegroups.com...
Pavel A.
too early).
--PA
"Alexander Grigoriev" <al...@earthlink.net> wrote in message
news:#wvMhJ0v...@TK2MSFTNGP05.phx.gbl...
Bipin Mistry
That was a good suggesion but was just thinking,
if we block local write then will windows & other applications like
Office outlook explorer .... will work fine..?
As they are also doing read/write to local programme files & windows
system diractories. Just courious whether it will be fine to block
local write access...?
Yes it does seems to be "preliminary optimized", but what i belive
that there was always 1 person from many of us to discover something
new...
where by my team has got oppurchunity so are also trying to achive
some thing new. Though we don't fear of failure, atlist we will learn
something out of this RnD.
Bipin
On 5月28日, 午前6:51, "Pavel A." <pave...@NOwritemeNO.com> wrote:
> Looks like design of this "soluition" was preliminary optimized (outsourced
> too early).
>
> --PA
>
> "Alexander Grigoriev" <al...@earthlink.net> wrote in message
>
> news:#wvMhJ0v...@TK2MSFTNGP05.phx.gbl...
>
>
>
> > This overall is wrong solution of a problem. The holy grail of secured
> > environment is a problem how to limit sensitive information leak. The
> > answer is: Limit user's options. You don't want the file to be sent?
> > Disallow file attachments altogether. You don't want the file to be saved
> > to unapproved storage? Make the storage inaccessible. If unapproved
> > storage is accessible, there are other ways to move sensitive information
> > there, other than copy. For example, attach to an email draft, save the
> > attachment. Create a zip file, copy it.
>
> >> - Show quoted text -- 引用テキストを表示しない -
>
> - 引用テキストを表示 -
Bipin Mistry
I have come accross a thread in this forum, "fat_boy" stated as
> Well, you could have a service that monitors the state of the
> clipboard. On a copy, it sends this data ot your filter. Your filter
> then compares this data to any being written after a paste.
<http://groups.google.com/group/
microsoft.public.development.device.drivers/browse_thread/thread/
2d6ab6ee0d01ee73/daa58e2a893cbfcd>
Any idea on this as to how can this be worked out.
Just wanted to give it a try, can this be intigrated with Driver or
not...?
Bipin
> > - 引用テキストを表示 -- 引用テキストを表示しない -
>
> - 引用テキストを表示 -
Alexander Grigoriev
"trusted" and "untrusted" programs in sandboxes. You'll want the process
that is able to read from the sensitive data storage be unable to write into
any other places. And the other way around: all other processes that are
able to write to random storage, be unable to read from sensitive storage.
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:879a2f1b-2098-4121...@z16g2000prn.googlegroups.com...
Tim Roberts
>Where COPY can not be identyfied,
>
>But, as per me, As for User, Where File Create & File Copy are two
>different commands, there should be atlist one difference between the
>two so as OS also can identify that what is Create & what is Copy.
Not at the driver level. Just stop and think for a moment: how is the
"copy" program implemented? It's a loop:
hSrc = CreateFile( ... );
hDst = CreateFile( ... );
while( 1 ) {
ReadFile( hSrc, Buffer ... );
if( end of file )
break;
WriteFile( hDst, Buffer ... );
}
By the time it gets to a driver, they are just read and write calls.
>As of till then I am stil in search of the ways how this can be worked
>out.
>If not on driver level then Where... & How ?
Nowhere and never. It can't be done.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Bipin Mistry
As you stated below
> Not at the driver level. Just stop and think for a moment: how is the
> "copy" program implemented? It's a loop:
>
> hSrc = CreateFile( ... );
> hDst = CreateFile( ... );
> while( 1 ) {
> ReadFile( hSrc, Buffer ... );
> if( end of file )
> break;
> WriteFile( hDst, Buffer ... );
> }
>
Now I also understand that there is only read/write at driver level
that is what been called in loop.
but to call this loop there should be some system event which also
contains hSrc & hDst information.
we can trace that and can figure out that current process required to
copy data from restricted (z:) to local zone (c:) or so...
As per me thinking logically
Way 1
1. we need to figure out a way to identify << hSrc >> & << hDst
>>
2. check for << hSrc >> with restricted (z:) then do not perform
this task & reset the system & environment variable
Way 2
1. Hook the clipboard where Copy / Paste commands gets triggered
2. Check for Copy source with restricted (z:) then ignore the copy
sequence.
Way 3 (by Alexander Grigoriev)
1. When restricted drive (z:) is mounted user can not access any
other drive or network share folder in write mode.
Although these all are just thinking process, haven’t come across who
have implemented.
If any one have any updates or improvement or tips & tricks to do any
of above then please do get back on this thread.
Bipin
David Craig
away? Someone who does something like this is paid to do the work and it no
longer belongs to him. It would be protected by the confidentiality clauses
in their employment agreement or consulting contract. Study Windows, write
programs that can do various forms of 'copying' not forgetting encryption,
compression, and container objects as output. When you have the various
possibilities defined then design a solution that works for all of them.
Using a flowchart is old school, but may be appropriate for your skill
level.
The most prolific posters in this newsgroup are consultants and will be
happy to design something for you if you agree to their contract price. I
would recommend someone with a lot of experience in file systems.
"Bipin Mistry" <bpnm...@gmail.com> wrote in message
news:1b79409b-4933-4de6...@q24g2000prf.googlegroups.com...
Ray Trent
completely undefined. Which of the following things do you need to prevent:
1) Just well-known GUI-level copy commands such as cut-and-paste &
drag-and-drop.
2) #1 + opening a command prompt and typing "copy z:foo.txt a:"
3) #2 + preventing a specific list of existing archiving/copying
applications from copying the data.
4) #3 + preventing someone opening the file in notepad, selecting all
the data, and pasting into another program, and saving the data from there.
5) #4 + preventing the user from writing any program that would allow
the copying of data from z: to any other location.
The problem you have is that #4 and #5 are impossible, as long as you
allow arbitrary read-access to the data by any program that you don't
control 100%. But if you control the program 100% then you don't need
what you're asking for here, because the app can just refuse to copy it.
And then there's 6) #5 + preventing the user from debugging your
application, extracting the data from memory, and copying it to another
location for duplication.
You can't stop #6 *even if* you control the only program that can read
the data, as long as it's possible for the user to see the data at some
point, unless you required external hardware support (such as a monitor
that decodes encrypted data in order to display it, and an app that
never stores decrypted data in memory).
And then there's 7) #6 + preventing the user from taking a digital
photograph of their screen and running the data through OCR to save it
on another machine.
If you can fix #7, well, patent it quick because the big media companies
will make you rich beyond your wildest dreams.
So... which of these do you need to prevent? I don't see any hope for
anything above #3, actually... but who knows.
Seriously, though, just encrypt your data. Then it doesn't matter if
someone copies it.
Bipin Mistry wrote:
> Hello Tim
>
> As you stated below
>> Not at the driver level. Just stop and think for a moment: how is the
>> "copy" program implemented? It's a loop:
>>
>> hSrc = CreateFile( ... );
>> hDst = CreateFile( ... );
>> while( 1 ) {
>> ReadFile( hSrc, Buffer ... );
>> if( end of file )
>> break;
>> WriteFile( hDst, Buffer ... );
>> }
>>
> Now I also understand that there is only read/write at driver level
> that is what been called in loop.
> but to call this loop there should be some system event which also
> contains hSrc& hDst information.
> we can trace that and can figure out that current process required to
> copy data from restricted (z:) to local zone (c:) or so...
>
> As per me thinking logically
> Way 1
> 1. we need to figure out a way to identify<< hSrc>> & << hDst
> 2. check for<< hSrc>> with restricted (z:) then do not perform
> this task& reset the system& environment variable
>
> Way 2
> 1. Hook the clipboard where Copy / Paste commands gets triggered
> 2. Check for Copy source with restricted (z:) then ignore the copy
> sequence.
>
> Way 3 (by Alexander Grigoriev)
> 1. When restricted drive (z:) is mounted user can not access any
> other drive or network share folder in write mode.
>
> Although these all are just thinking process, haven’t come across who
> have implemented.
> If any one have any updates or improvement or tips& tricks to do any
> of above then please do get back on this thread.
>
> Bipin
--
Ray
Bipin Mistry
I do agree that there is no limits to copy file(hacking the data),
thats the reason our task is limited to restrict standerd copy/paste
methods which are as follows:
1. [Ctrl + C],
2. Right Click Menu -> Copy
3. File Menu -> Copy
4. Command prompt copy
5. Drag & Drop
Bipin
> Ray- 引用テキストを表示しない -
>
> - 引用テキストを表示 -
Eugene Mayevski
You wrote on Thu, 29 May 2008 18:13:22 -0700 (PDT):
BM> I do agree that there is no limits to copy file(hacking the data),
BM> thats the reason our task is limited to restrict standerd copy/paste
BM> methods which are as follows:
That is snake oil. Or even worse, fooling a customer.
Take Total Commander or FAR manager and your "protection" is gone. As
mentioned, only a virtual storage with strict control over access to the
data can provide some level of protection.
Ray Trent
about GUI level windows internals, but there are a number of tricks you
could try, including global windows message hooks, Shell Extensions,
clipboard monitoring, hooking of the CopyFile/Ex function (using, e.g.,
Detours), etc.
Still... are you talking about just Windows Explorer? Because hundreds
of apps implement copy and paste functionality for files, and they don't
all do it through the clipboard. In particular, File Menu->Copy types of
functionality are probably implemented by a lot of apps using a simple
Open Source&Dest/Read Source/Write Dest loop, and you're not going to be
able to deal with that.
Also, I don't know enough about it to say for certain, but I really
don't know how the cmd prompt copies files, or whether there's a good
way to squeeze in there.
In any event, I agree with another poster that called this "snake oil".
It's really not improving your security the same way that, say,
encrypting the data would.
Bipin Mistry wrote:
> Hello Ray,
>
> I do agree that there is no limits to copy file(hacking the data),
> thats the reason our task is limited to restrict standerd copy/paste
> methods which are as follows:
>
> 1. [Ctrl + C],
> 2. Right Click Menu -> Copy
> 3. File Menu -> Copy
> 4. Command prompt copy
> 5. Drag& Drop
--
Ray
Pavel A.
news:#8jyz3hw...@TK2MSFTNGP05.phx.gbl...
> ....
> That is snake oil. Or even worse, fooling a customer.
Eugene, you need to take a multi cultural training...
In some parts of the world, snake oil is a delicious treat (and also bugs,
worms etc.) :)
IMHO, your earlier advise on controlling only file opens would be good
enough:
Suppose the secret documents are PDFs, then you allow opening them only with
Acrobat reader,
and disable printing and clipboard copy in document permissions ?
regards,
--PA
Eugene Mayevski
You wrote on Sat, 31 May 2008 17:29:20 +0300:
??>> That is snake oil. Or even worse, fooling a customer.
PA> Eugene, you need to take a multi cultural training...
PA> In some parts of the world, snake oil is a delicious treat (and also
PA> bugs, worms etc.) :)
Do snakes have oil? Does fish have fur?
PA> IMHO, your earlier advise on controlling only file opens would be good
PA> enough:
Not exactly so. I was talking about different approach - the only way to try
to protect the data is to control every step, from data delivery to it's
storage to it's use. It will never provide 100% protection, but it will
provide the best protection comparing to other approaches (such as prevent
copy operations that the OP thought about).
PA> Suppose the secret documents are PDFs, then you allow opening them only
PA> with Acrobat reader,
PA> and disable printing and clipboard copy in document permissions ?
For PDFs implementing DRM is a very special thing (which is offtopic here).
I'd say that if we don't care about OCR'ing screen captures, implementing
reasonably reliable DRM with Adobe Reader and web server is possible. As
developers of PDF security components we had several requests from customers
about this, and we investigated this topic deeply. If interested, contact me
by e-mail.