Example problem: You have a mission-critical Notes database that is distributed to your sales force, each with a local replica on their laptop. A salesman leaves, takes his laptop, and you want to deny him access to that mission-critical data.
Any “best practice” ways of accomplishing this? A Database Script comes to mind, but seems easy to bypass.
Subject: It really can’t be done. Even using your “database script” example.
The problem is that the data is on his machine. He unplugs from your network and takes his laptop away. How is your script going to know that he is not just traveling in his normal business mode? It would have to be connected to your server in order for you to be able to control this.
Subject: RE: It really can’t be done. Even using your “database script” example.
Bill, I should clarify. I intended on checking the replication history with my Database Script on open, and if the user hadn’t replicated in X number of days deny access somehow to the db.
The problem is still that someone could bypass it if they knew what they were doing.
Subject: RE: It really can’t be done. Even using your “database script” example.
Hmmmm… all the ways to bypass this…
change the clock on the laptop before opening the database.
opening in Designer, then using Preview in Notes, which bypasses the PostOpen event
writing the database to CD, so that deletions are impossible
marking the NSF as read-only in the OS
reading the documents through an agent or API program, and copying to another location
printing all the documents in hardcopy before the expiration date
replacing the design on the database
putting the NSF on a server and accessing via browser
Of these, I’d consider #3 to be the most likely. If I were a salesperson leaving the company, I’d copy that NSF to a CD before giving notice.
There are some good reasons for not taking the approach you’re thinking of. What’s going to happen when someone legimately hasn’t replicated in that time period? Materinity leave is a good case where someone might just be on vacation during that period. You’re possibly destroying valuable work and data that might be on that replica.
Subject: RE: It really can’t be done. Even using your “database script” example.
Great, now when I implement this users will know 8 ways to bypass it. 
Seriously though, I have thought about legitimate users accidentally getting shut out. If you haven’t replicated in two weeks then I just close the db, if you haven’t replicated in 3 months then I delete it and you’ll have to re-replicate. Realistically, it shouldn’t happen too often.
Like I said in previous posts, the idea is to make it somewhat difficult for the average user, not necassarily impossible.
Subject: RE: It really can’t be done. Even using your “database script” example.
I can’t emphasize enough that this kind of fig leaf protection tends to hide the fact that there’s a vulnerability, rather than provide any real protection. If you put this in place, then even putting aside the inconvenience for legitimate users, you will create the attitude among the managers of this project that the remote replicas are “safe” when they are obviously not. It’s bad information security strategy.
Obviously the client wants this, and presumably they’ll pay you to do it, and you will be able to put some kind of token difficulty on there. But it’s not like the defeats to it demand in-depth knowledge of Notes. My GRANDMOTHER writes CD-Rs now, and that’s the only thing it takes to make the whole scheme breakdown.
Subject: RE: It really can’t be done. Even using your “database script” example.
Quote:If I were a salesperson leaving the company, I’d copy that NSF to a CD before giving notice.
Nathan, that is not only extremely unethical, but also more than likely a crime. I hope you’ll never consider such a thing in your professional life.
Subject: RE: It really can’t be done. Even using your “database script” example.
Heh. True enough. I should have said “were I a salesperson contemplating stealing the information in the first place, the method I would probably default to would be to copy it to CD.”
It isn’t unusual, however, for a security analyst to describe an attack in the first person.
Subject: RE: It really can’t be done. Even using your “database script” example.
Sure. After all, security analysts are basically expert felons who have decided to use their powers for good. 
Subject: RE: It really can’t be done. Even using your “database script” example.
… or so the Germans would have us believe…
Subject: RE: It really can’t be done. Even using your “database script” example.
On the advice of counsel, I have no reply to that remark.
Subject: Preventing access to a local replica
There’s no way to do this.
That rep might know Notes Programming, and might have used some Lotus Script to extract all of the informatiion in your database into their own database (while they still worked for you) and that would bypass anything you might develop.
You might be able to make it hard for them, but you cannot stop them.
P.S. This falls into the problem of “Once you give someone access to data, you cannot effectivelly revoke that access”.
Subject: RE: Preventing access to a local replica
I agree. My objective is to at least make it very inconvenient.
Subject: RE: Preventing access to a local replica
Have you considered making their Notes ID certificates short term ?
For example, only have their Notes ID’s valid for one month, and auto-recertify them every month. Then, if they do leave, they can only use there ID for a short time.
It won’t stop a determined user, but will limit the exposure for the casual users.
Subject: RE: Preventing access to a local replica
I have not considered that. That may have a wider impact on the whole Domino infrastructure than the client is willing to except for one application. Its a possibility if I do a layered approach, so thanks.
Subject: RE: Preventing access to a local replica
Why would that help you? It would prevent those IDs from accessing your servers, but do nothing to prevent access to a localized replica. Even if the local replica were encrypted, all someone has to do is just their local clock, which is about 4 clicks on Windows 2000.
Subject: RE: Preventing access to a local replica
Say the database is encrypted. If the user doesn’t know we’re preventing access based on replication history then why would they think to adjust their local clock?
Subject: RE: Preventing access to a local replica
Say I’m Naughty Sales Representative. My supervisor gets wind of my other nefarious activities and gives me the boot. I examine the DB from time to time, everything is visible, then all of a sudden, I can’t get to it - everything’s gone. What could account for that? hmmmm…well, best to get out the backup I was smart enough to have made to a CD before everything went haywire, and copy it over top of the blanked out one. What’s this? Hmmmmm…can’t get to the restored one either. Why is that? Well, I’m unemployed so I probably have lots of time to figure it out. hmmmmm…now I’ve got it! It’s because it’s dated! Well, if I back up the clock and then do a restore, I’ve got it all back!
The bottom line is that with a backup CD in hand, the determined Naughty Sales Representative can more or less easily walk himself through getting the data back.
Let’s also remember that it’s also quite possible that Naughty Sales Representative has exported the data from the application(s) in question to Excel or Word (or whatever) through the Export option available through the menu bar when he/she is in a view. There’s certainly no way to keep that secure once the data has left the cozy confines of the .nsf.
The bottom line is that there is no foolproof way to secure data stored in a local .nsf.
Subject: RE: Preventing access to a local replica
First, the question here was about certificate expiration, not replication history. Graham’s suggestion was to have short expire times (which has it’s own benefits and costs.) My question was: why would short certificate expiration help protect a local copy? The only method would be by forcing that local version to be encrypted with that ID (which you can’t really do) and then expire the ID, which should prevent the Notes client from doing meaningful work with it.
However, this strategy is defeated by setting the clock back.
As far as your replication history approach goes, you’ve got the same problem, as Chuck points out. You could make the open script so clever as to silently kill the replica of the NSF, but given that the entire approach fails if the user ever writes the NSF to CD, you’ve got half-a-dozen Notes experts telling you: this is not information protection, and you shouldn’t allow yourself or your client to pretend that it is.
Subject: Preventing access to a local replica
This isn’t really a technical question, Robert - it’s a procedural one. As the others have pointed out, there are any number of ways a user could bypass whatever means you’re attempting to use to hide the Notes data from him or her. My question goes to the issue of the sales representatives putting presumably confidential, proprietary data on their own personal computers. Why would they be allowed to do this? It seems to me that they should be allowed only to use company-owned computers which would be recovered upon their termination. Anyone provided with confidential or proprietary data should also have been required to sign a strict confidentiality agreement prior to receiving it. Was this not done? It strikes me that you’re looking for a technical solution to what is, in actuality, a problem of procedures and internal controls.