Securing data
in [Help]
|
Prev: Linking an Excel file in Access with mixed data types in columns and #Num!
Next: Access 2010 with Sharepoint 2010
From: The Frog on 5 Nov 2009 04:26 If you are looking for data to be secured from people with malicious intent then you could always introduce a cryptographic function to encrypt the data so that it can only be 'read' from your application. Simple XOR shifting might even be enough to deter casual snoopers - although a programmer would probably get through that in under 60 seconds. The more capable the advesary or the greater the risk the stronger you need to protect your data. As Tom says, it really depends on what you are trying to do. The Frog
From: Finn Stampe Mikkelsen on 5 Nov 2009 04:56 > On Thu, 5 Nov 2009 02:59:59 +0100, "Finn Stampe Mikkelsen" > <stampe(a)city.dk> wrote: > > It depends on how strong you want that protection to be. In one case I > wrote an AutoExec macro in the back-end database, with a: > Msgbox "Yo! You shouldn't be here. This db is only for use with the > XYZ app" > DoCmd.Quit > and that helped a lot. But it's not foolproof, of course. > > Also, in many jurisdictions the data belongs to the owner/licensee of > the app, and you as the manufacturer of the app do not have the right > to make that data unavailable. > The copyright of the is mine, would i therefore not be the owner of supplied data with the app?? I can se how data created with the app could be the owner/licensee, but data supplied with the program (ergo not compiled/created by the owner) should not be covered by that... What i want to prevent, is actually that the data supplied by the copyright holder, is not used as basis for another program doing essential the same thing. I could password protect the data, but that has no value. 10 seconds and that password is broken.. So i need to do it another way and my advisary would be a programmer. it sounds like i need to do a data encryption algorythm to encrypt the data. ..NET provides great classes for that, but i wondered if there where an already inplace security i could have used instead.. /Finn
From: David W. Fenton on 5 Nov 2009 15:30 "Finn Stampe Mikkelsen" <stampe(a)city.dk> wrote in news:4af2a131$0$271$14726298(a)news.sunsite.dk: > The copyright of the is mine, would i therefore not be the owner > of supplied data with the app?? Depends on what you mean by "supplied data." We generally don't consider forms/reports/modules/macros to be "data". Basically, if it's in the back end, it belongs to the client. If it's in the front end, it belongs to the developer. Obviously there can be exceptions to that, but the principle is pretty clear -- the contents of the data tables belong to the client. Now, if you're using metatdata stored in tables to drive your app, then that would belong to you, but I'd question why that would be in the back end and not the front end (e.g., the switchboard table is always in the front end, given that changes to it are specific to the application part of the app). If you have data tables that you are supplying to the client and that drive your app, then I'd say those data tables belong in the front end. But if the client is adding data to those tables or altering the existing data, that transforms the situation into something much foggier. However, I'd say that scenario sounds like a design error. In the abstract, it's very difficult to come up with a principle that covers all cases, but the law in the US is very explicit that data belongs to the people who created it and copyright in the application to the programmer. And both of those default assumptions can be overridden by a contract that sets different terms. > I can se how data created with the app could be the > owner/licensee, but data supplied with the program (ergo not > compiled/created by the owner) should not be covered by that... You're confusing copyright and ownership. Data cannot be copyrighted, but it can be owned. The data your customers insert into the tables behind your app is their data. You have no legal or moral right to prevent them from using it in any way they see fit. That doesn't mean you have to support it, just that's it will get you in legal trouble if you try to lock them out of their own data. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Finn Stampe Mikkelsen on 5 Nov 2009 16:00 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> skrev i meddelelsen news:Xns9CBA9C9C8A72Df99a49ed1d0c49c5bbb2(a)74.209.136.97... > "Finn Stampe Mikkelsen" <stampe(a)city.dk> wrote in > news:4af2a131$0$271$14726298(a)news.sunsite.dk: > >> The copyright of the is mine, would i therefore not be the owner >> of supplied data with the app?? > > Depends on what you mean by "supplied data." We generally don't > consider forms/reports/modules/macros to be "data". > > > The data your customers insert into the tables behind your app is > their data. You have no legal or moral right to prevent them from > using it in any way they see fit. That doesn't mean you have to > support it, just that's it will get you in legal trouble if you try > to lock them out of their own data. > To specify the situation...: I have a database app, that presents pre-excisting data to a user. This data is supplied with the app and is not ment for the user to edit. Alongside this data, there is another database containing the user own additions to the data. What i wanted to encrypt was the data supplied with the app, to prevent someone from using this data to create there own app, with similar functionallity... Real life example.. Picture a digital phone directory, with the option to add comments in the seperate database to every directory entry. The data i want to encrypt is the actual directory supplied with the program. i could'nt really care less about the data created by the user.. Wether the data is in front-end or back end i have no idea of what you talk about. Those concepts, datawise, are unfamiliar to me... Besides that, this debate is off-topic in relation to the original posting, concerning built-in ways to secure data in an accdb file. It seems not to be a feature available... /Finn
From: David W. Fenton on 5 Nov 2009 20:33
"Finn Stampe Mikkelsen" <stampe(a)city.dk> wrote in news:4af33cef$0$277$14726298(a)news.sunsite.dk: > "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> skrev i > meddelelsen > news:Xns9CBA9C9C8A72Df99a49ed1d0c49c5bbb2(a)74.209.136.97... >> "Finn Stampe Mikkelsen" <stampe(a)city.dk> wrote in >> news:4af2a131$0$271$14726298(a)news.sunsite.dk: >> >>> The copyright of the is mine, would i therefore not be the owner >>> of supplied data with the app?? >> >> Depends on what you mean by "supplied data." We generally don't >> consider forms/reports/modules/macros to be "data". >> >> >> The data your customers insert into the tables behind your app is >> their data. You have no legal or moral right to prevent them from >> using it in any way they see fit. That doesn't mean you have to >> support it, just that's it will get you in legal trouble if you >> try to lock them out of their own data. >> > > To specify the situation...: > > I have a database app, that presents pre-excisting data to a user. > This data is supplied with the app and is not ment for the user to > edit. Alongside this data, there is another database containing > the user own additions to the data. Are these different data tables? What's the purpose of this data? Does it like to the users' data? > What i wanted to encrypt was the data supplied with the app, to > prevent someone from using this data to create there own app, with > similar functionallity... Oh, boo hoo. What makes you think your precious data is so fabulous that somebody would want to "steal" it? Or that somebody who knows what they are doing can't just look at your app and recreate the data and the functionality just by understanding what your app does? > Real life example.. Picture a digital phone directory, with the > option to add comments in the seperate database to every directory > entry. The data i want to encrypt is the actual directory supplied > with the program. i could'nt really care less about the data > created by the user.. Data cannot be copyrighted, so you don't have copyright on the data. That's why so many reference databases are locked behind pay firewalls, because once it's out, it's legal for anyone to use it. > Wether the data is in front-end or back end i have no idea of what > you talk about. Those concepts, datawise, are unfamiliar to me... Then you must be a novice Access programmer. No properly designed Access app puts the data tables and all the forms/reports/etc. into a single file. Instead, the user interface objects are in the front-end file and the data tables in a separate file, which the front end links to. This is bog standard structure for Access apps and always has been (or, at least, as long as Access has offered linked tables, which certainly predate Access 2.0). Aside from the practical reasons for splitting the app, it's logical, as the application part of your app is separated from the data on which it operates. In your case, the pre-supplied data might be better stored as part of the application, or in a separate back-end data file (assuming you're not enforcing RI between "your" data and your clients' data). > Besides that, this debate is off-topic in relation to the original > posting, concerning built-in ways to secure data in an accdb file. > It seems not to be a feature available... There is no encryption built into Access. But if you need encryption, I don't think you should be using an ACCDB to store your data. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |