Is the following a true statement?

[color:green]Anyone with FileMaker Advanced can use Add File Reference to tap into the data file of a distributed runtime -- even though it had been "bound" as a runtime component and Administration Access has been removed.

My testing says it is. Does anyone have a different experience?

Is there a countermeasure? (i.e., a way to prevent it?)

Thanks for any advice.

Why bother with that? Anyone with FileMaker Pro can open the file with the same Account as is used with the runtime.

Steven

Thanks for responding, but I don't understand what you mean. I'm trying to protect a runtime to the maximum extent afforded by FileMaker. I just haven't been able (after reading maybe 100 posts on the subject) to determine exactly what that "maximum extent" is.

I don't understand what you mean

Simply this: the data files that are associated with the runtime that you built can be opened with FileMaker Pro just as easily as they can be opened with the runtime engine.

What are the threats you're trying to protect against?

Steven

For my distributed, single-user application, I would like maximum protection against someone viewing my scripts, my custom calculations and my data structures (table and field definitions). By the way, I do use the 2-file separation model (GUI and data).

For my distributed, single-user application, I would like maximum protection against someone viewing my scripts, my custom calculations and my data structures (table and field definitions). By the way, I do use the 2-file separation model (GUI and data).

You could remove the [Full Access] Account with the Developer Tool utility. This will help to meet this goal. It will not completely guarantee it.

Steven

Yes, I'm definitely doing that for my released product. But this leads to a variation of my original question:

Since it appears to be true that Add File Reference can be used to tap into a "protected" application, are there additional measures that can taken to prevent that?

To be 100% honest, I think you're going to waste more time on trying to protect your solution then you will in general.

How many licenses do you think you'll lose to intellegent developers sitting around with their trigger fingers on their mouse sitting around until someone releases a faulty fm application so they can crack it and re-distribute it freely to the world!! LOL, but seriously, most of the people who use my products can barely even open word so... I don't know it depends how much time and money you want to waste for the few licenses you will lose.

If you're actually concerned about security (which i don't think you are given that you are talking about a file which is already open) well that may be a different matter.

given that you are talking about a file which is already open

Genx, thanks for the added perspective. I'm not sure what you mean by "already open", because I considered that binding and removing admin access was closing (locking down) the files.

Again, what I'm striving for is "protection against someone viewing my scripts, my custom calculations and my data structures".

I don't mean already open as in insecure.

I mean as in your user logs in, then they open up another FM file and add a relationship -- this can only be done if they have already logged into the main file... but the main danger here is not so much them seeing the internal workings of the scripts and / or your data structure, but rather their ability to execute these scripts remotely from the other file and see the data.

For scripts, data structures and custom calcs -- This is all controllable via FM's security settings. Simply put -- if you want no one to see your inner workings, remove all possible accounts that have access to all this information. Read the help to see what controls what if you're confused.

I'd go into more detail, but i've no time!! argh lol. Should at least help you get started.

PS, I'll also admit I'm a bit of a "n00b" (is that what the kids say these days ) when it comes to making my security sets as efficient as possible. I think I'll do some reading about this in a few weeks and spend a couple of days in seclusion with some files : hehe.

I understand. I have reading to do, also. I'll try to come up with a summarizing statement along the lines of "if I implement all of the following measures, then where is the application still vulnerable". I'm still trying to identify and understand all of the involved considerations.

Thanks again.

Well, come back to this post when you've done that reading and we'll go through a few possible scenarios and see what happens.

Boy, someone has sure done an about face...or is it getting older and confronting reality???

If someone wants in, they can get in. I've always worried about users sharing a single copy, more than I have about someone ripping off the whole system (certainly a possibility). Let's see what FM has in store for Version 9.

Steve

Edited June 17, 200718 yr by Guest

Didn't say anything about using dodgey software to get in -- Just that you can probably do more to protect from FM style break ins.

Yes, let's see what FM 9 has in store (though i'm not sure much will have changed - but you never know)

EDIT: OHHHH you're not talking abbout me righttttt.

Edited June 17, 200718 yr by Guest

Since it appears to be true that Add File Reference can be used to tap into a "protected" application, are there additional measures that can taken to prevent that?

Essentially not. If the file is open with a particular set of privileges, then it is open with that set of privileges. You must distinguish data table privileges from UI privileges.

Steven

Yep Genx...just kidding. It shows how we've both matured...me too fast...you about right.

Steve

You must distinguish data table privileges from UI privileges.

I need to mention that my application uses the Guest account to avoid asking the user to sign in -- and that it's provided as a bound runtime with the [Full Access] Account removed.

So, is the best approach simply to define a custom privilege set for the Guest account and set FieldAccess=none for every table? Also, since I'm using the 2-file separation model, it appears that the Guest account needs to be defined that way in both files. Is that correct?

The best way I know to summarize what I'm trying to achieve is a locked-down, single-user runtime with only entry and edit capability, plus field-level exports-- and that hides the data structures and script definitions, of course. This would seem to be a very common requirement for many distributed solutions, but I've found no specific mention of this case in the help files. Any guidance will be greatly appreciated.

Export privilege is UI based; it can be rigorously enforced only in the file where the data actually reside or in a file that the solution developer designs. It cannot be enforced in any other external file.

Steven

I'm trying to achieve is a locked-down, single-user runtime with only entry and edit capability, plus field-level exports-- and that hides the data structures and script definitions

Are you saying this is possible? -- or not possible. How do you suggest that I proceed?