prev

iDB Tutorial  (cont.)

What is iDB?

iDB Datamaster is your pocket data manager. It is designed for pocket computers, and has a very small footprint. iDB is for single user only. (**)

Technically speaking, iDB is a template-drive database engine. Utilizing that technology iDB manages your pocket data, and provides a number of applications for daily, mobile usage.

"Data Manager" may seem to be an intimidating term. However, iDB does not require users to have any knowledge of databases. You just need to select your choice of template; iDB will take care of the rest as humanly as possible.

Under iDB, you can create multiple databases, of the same or of different types.

What is it *not*?

iDB is NOT a custom template or form designer, or a custom database designer.

iDB tries to provide "integrated", "useful" applications. It tries to present ready-to-use solutions.

As such, the problem with custom templates and dynamically adding new fields and/or modifying existing ones becomes much bigger than just allowing users to create a form (template). Some desktop applications providing this functionality do just that: they provide a single database.

However, iDB wants to be much more integrated than that. In iDB, the goal is to render functional applications. If custom forms were allowed, iDB then has to change the underlying queries accordingly to fit into all applications' inner workings, and modify the search, insert, delete, move queries dynamically. Even just moving records from one database to another can turn into a challenge then. Say, between encrypted and non-encrypted databases., while ironing out sorting options. How to sort, in what order (say status, priority, progress, title), how to index.., all become dynamic issues to tackle.

Desktop applications providing form-design tools and database creation do just that: They just provide a singleton database, without any integration to the surrounding environment. Currently that is not what iDB is trying to be.

How to Start?

Once you install iDB from AppStore and click on iDB icon on your iPhone/iTouch device, it will pop up the following screen:
 

At this point you have no password set. And as long as there is no password set, iDB will keep complaining about it, and will bring up the warning you see in the image above.

Simply tap on the 'GO' key to log on. The next screen is the 'Console' view. Console looks like a ferris wheel with a number of application icons. You can simply rotate the wheel to reveal more applications:
 

   

At the bottom of the Console screen resides the toolbar. At this point probably the first thing to do is to set your password. Tap on 'Config' botton at the toolbar:
 

That will bring up the Configuration screen. Let's not set up 'Admin' password yet. So it is still 'nothing', or empty string. Tap on 'Set Security Question:
 

   

For 'Admin Password', enter nothing and just tap on 'Next'. Then set a security question, something very personal, and something you would never forget the anwser to it. In the future if you ever forget your password, you can recover from it by providing the answer to the security question.

Next, go back to the Configuration screen, and tap on 'Change Login Password':
 

   

Although it is not clear on the image above, we just entered 'nothing' on all 3 fields above. (Only then the big blue 'Done' key would show up). The first nothing to the 'Admin Password' is obvious, since it still is nothing at this point. By entering 'nothing' (by simply hitting 'Next' when on that field) for 'Login Password' and its confirmation, we just set the 'Login Password' to nothing.

When tapped on 'Done' key, we will get a confirmation alert about login password being set (second image above). An empty string, or nothing is a legitimate login password.

Next, tap on 'Change Admin Password' in Configuration screen. Enter nothing for current password. Then provide the new password and its confirmation:
 

If your login password is set to nothing, next time you start iDB, it will skip the login window completely, and start at the start screen. Start screen is initially set to 'Console'. Once you get familiar with iDB and set up your databases, you may want to set it to something else in Configuration:
 

How Secure is it?

iDB Datamaster is as secure as you keep it. If desired, it can even keep the data encrypted on your iPhone/iTouch device.

If you intend to use iDB for your accounts, financial info, credit cards, login/passwords, etc. you should then select a strong password, keep them encrypted, and mark those databases as 'admin-only'!.

iDB also incorporates a web-server for backup/recovery chores. You should change access parameters to the web-server (see 'Configuration') to keep it secure, and shut down the server whenever you are done using it.

A strong password is essential to keep iDB away from intruders. However, choosing a strong password may have undesired repurcussions. Since iDB hosts many applications, a strong password policy may not always be one that fits all. It may be bothersome for someone who wants to check a shopping-list item quickly: either enter a long password just to take a quick peek at an item, or compromise the strenght of your password, therefore compromise the security of your password accounts and credit cards.

Therefore iDB presents two separate passwords: A mere login password, and an administrative password where the latter absolutely must not be compromised.

iDB also provides the choice of encrypted databases. If your device is lost or stolen, and if the finder indeed has bad intentions, he/she will likely go to the disk of the device directly, rather than wasting time with applications' passwords; hence the need for data encryption on the disk.

Encrypted databases are listed with a padlock image in 'locked' position in 'Databases' screen:
 

   

If a database is encrypted (has a padlock), all its data except record titles and keywords are encoded. On any given record, regarless of database's encryption, titles and keywords are NOT encrypted. For internal consideration (easier table indexing) and for performance reasons record titles and keywords are kept plain, regardless of owning DB's encryption mode. Therefore, you should never put confidential information like social security numbers, credit card numbers, passwords, etc. in these non-secure fields. The remaining fields of DB records should render that need obsolete.

Although not encrypting titles and keywords may seem unpleasing at first, keeping them out of encryption provides the benefit of faster searches to componsate that deficiency.

"Admin-only" Screens

Since iDB has a weak versus strong password notion (login-password versus admin-password), some areas of iDB are not protected well enough under mere login-password. Login password can be as weak and as fast as user wants it to be. It can even be 'nothing' (empty string), in which case login window would be totally skipped.

Configuration ('Config' button in Console toolbar) would require strong password (admin password) for obvious reasons. If iDB is logged-on with login password, then tappion on 'Config' button would bring up admin password screen. Providing correct admin password would then take you to the target screen, configuration 'Settings' in this particular case:
 

      

Similar to 'Config', 'Search' would also require admin-privileges. This may seem odd at the beginning, but there is a good reason behind:

If 'Search' were granted to mere login users, then it had to keep admin-only databases out of search queries. However, that can be extremely confusing to the user. Once you are rendered a list of 'found' records as the outcome of a search query, it is impossible to know what records you are missing, and may end up taking the provided outcome as correct and complete. That can be extremely misleading. Therefore 'Search' queries must have the liberty to be able to search over everything. Hence the need for admin privileges for 'Search'.

Next is the 'Server' button on the toolbar which is used to start the iDB Server. (See 'Backup and Restore'). iDB Server also requires admin privileges.

You may also change the status of any database as 'admin-only' database. If you have a very weak login password, you must set your, say, 'Credits Cards' database as admin-only for obvious reasons.

'Admin-only' databases are distinguished by either a small 'admin' image (if your are admin user at the time), or a stop sign if you are a mere login user.

Note that the encryption mode of a database versus its 'admin-only' access-status have nothing to do with each other. Logic may hint that when you care enough about the security of a database and keep it encrypted on the disk, then it should be protected as an 'admin-only' database. However that is not necessarily true. You may choose to create all your databases encrypted, however allow mere login access to a, say, 'Groceries List' database.
 

prev

next