Five theories why developers write garbage HTML

Justin James reports that garbage HTML appears to be alive and well. He offers his theories on why some developers still crank out junk and discusses whether he thinks the problem is hopeless.

—————————————————————————————————————

A little more than two years ago, I pleaded to my fellow developers to stop writing garbage HTML! I think that problem has gone from bad to worse.

A few weeks ago, I asked Programming and Development readers, “How good is your HTML?” and roughly 25% of you claim that it meets all of the standards and such. I know a lot of the readers of this blog fairly well, so I believe those numbers; but I also know that makes my readers a very small minority. Garbage HTML is, unfortunately, alive and well.

Here is some really sad news: less than 7% of the Alexa Top 500 validate! It’s just a problem with those pages, right? Wrong. According to the researchers, “This is a slightly higher percentage rate than the much larger overall MAMA population, but the quantity and difference are still too small to declare any trends.” In other words, that sorry 6.57% valid rate is actually better than the Internet on the whole.

For a moment, let’s assume that Web standards are not the “be all and end all” of Web development. Judging from the more than 50% of readers who said their HTML is “good enough for it to display the way I want it to on all or most major browsers,” I think it can be said that 100% standards compliance may be a goal, but it is not the most important one. For the majority of developers, the standards are a means to an ends, and that end is looking good. All that being what it is, I don’t think a Web page that is slightly off of spec is garbage HTML. It may not be perfect, but that doesn’t make it garbage.

Garbage HTML has a special something to it, a unique blend of being not just invalid, but disgustingly so by going beyond minor misunderstandings or typos and far into the realm of negligence — improperly nested tags, tags that are never properly ended, incorrect attribute usage, and so on. Why do developers crank out this junk? Here are my theories:

• Ignorance: A good number of developers don’t know better, whether because they did not seek to learn good HTML, or where they learned it from did a lousy job of teaching HTML. The folks who “learned” HTML by copy/pasting other people’s junk code fall into this bucket.
• Poor tools: Many developers count on a tool to produce their HTML, whether it’s some sort of HTML WYSIWYG system, or maybe a framework/library that is cranking out bad code. There are reasons why some of these tools can’t generate code. For example, until recently, those on-screen, Web-based HTML editors had a much easier time rendering the font tag than a CSS class or even an inline style. The end result? HTML widgets that were generating the font tag for HTML nearly 10 years after font had become deprecated. Another problem is that there is not a 1:1 mapping of stylistic effects and the way to make the effects happen. Without editors that are strictly contextual driven, there is no good way for the tool to know that [Ctrl]I should result in the em tag as opposed to a CSS style that makes something italic.
• HTML is too semantic: HTML is transitioned to being as purely semantic as possible without completely breaking backwards compatibility. In general, this is a good thing. But for a developer who is trying to finish their work and go home, it is a nightmare. Which tag does the developer use? What if the developer wants the effect that a tag produces, without the meaning of the tag? It’s enough to drive anyone insane. So what happens? Developers stop caring about what the HTML “means” and just do enough to make the page render the way the client wants it to look. In the shuffle, the HTML ends up being a mess.
• Developers who never updated their HTML skill sets: This is a huge problem. I know developers who this very week probably used the font tag or maybe a frameset. Maybe they learned HTML in 1997, or the book they bought on the bargain bin in 2002 was from 1997. Who knows? But their HTML is stuck in the HTML 3 years, and they haven’t updated it since.
• Server-side technologies: In my opinion, using print statements (or the equivalent) to produce large amounts of HTML is asking for trouble. The page can’t be “visualized” as HTML without first mentally executing software. That is a sure way to not be able to get the code right.

Is the situation hopeless?

I think some parts of this problem are not likely to be corrected. Most developers who care about doing things right are using tools that combine just enough visualization to make life a bit easier, without completely taking over the process. Some developers may be running their code through validators or keeping current on what is correct and what isn’t. But at the end of the day, there is no way to force a developer to start caring about these things unless you are their boss. After all, browsers will display even the worst HTML code, as long as it somewhat makes sense.

I’d be willing to bet that the percentage of developers writing garbage HTML has remained steady over the years. The 80/20 rule probably applies here (as it seems to do in so many other areas). In my experience, only about 20% of developers really understand how to accomplish something as well as why they should do it that way and what the consequences are. That’s the same 20% or so who are probably writing decent HTML.

I am sure that the Web would be better off if more developers put forth the effort to write better HTML.

J.Ja

Disclosure of Justin’s industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

E-mail needs safe rendering

At the moment, the only really safe way to view e-mail is plain text. What if someone actually went to the trouble of creating a safe rich content rendering mode for an e-mail client?

---

In A practical example of why HTML email is a bad idea, I provided a very simple example of the kind of security dangers that can be avoided by nothing more complex than viewing email only as plain text. Of course, it’s reasonable to expect that there will be occasions people will send you HTML e-mails, and you’ll need to view the contents — and it is reasonable to expect that you will want to be able to view these emails without having to visually sort through everything to find the parts that aren’t extraneous, unnecessary markup. It is the convenience of not having to try to sort through the tangle of bad HTML in many emails that drives many to ignore security advice about viewing emails as plain text.

Much as I wish it were otherwise, it doesn’t seem likely that everybody in the world will forsake their unnecessarily HTML-laden ways when it comes to composing emails, not only because many modern email clients default to HTML-formatted e-mails, but also because many people get deeply involved in choosing the right “stationery” background image, fancy fonts, and other pointless frippery when sending intensely interesting and highly informative e-mails like “yo, whats up? how r u?”. Luckily, a lot of those clients do “the right thing” when composing HTML emails, which is to offer a plain text version as well without the person composing the email even having to know about it.

Sometimes, however, we don’t get plain text versions along with the tangle of spaghetti HTML. This may be because, when certain things are done in HTML that cannot be reasonably well degraded to plain text, the email client just skips the plain text version; it may be because some Website developer doesn’t know any better when he designs the automated feedback form reply script; it may even be because someone stupidly turned off the plain text copy capability. It may also simply be the fact that someone is using a particularly low-quality email client that only offers HTML formatted functionality.

Regardless of how it happens, the fact remains that sometimes we just need to be able to sift through the contents of an HTML-formatted e-mail, and probably don’t want to have to do it without getting a headache. The choices are usually limited to:

1. give up on secure practices and just view the rendered HTML e-mail somehow — either within an HTML-capable email client or by viewing the email in an outside application that renders HTML
2. live with the inconvenience of parsing all that markup by eye
3. delete the offending email and request another copy without the unnecessary markup scattered through it

I used to run with number 2 all the time. After a while, I decided to write a simple script I call stripmark that would parse HTML out of the email so I could just view the plain text. Over time, it has acquired a few more capabilities, including translating linebreak tags into actual newline characters in the plain text output. This sort of thing is relatively easy to do, with tools like the Ruby programming language and a highly functional text-mode mail user agent such as Mutt. This, however, is far outside the range of what the average user is able to do, and isn’t exactly within the range of what most technically oriented people are willing to do — especially those whose tools are mostly limited to the MS Windows platform.

The script I use is gradually changing into something akin to the opposite of what text parsing libraries like Markdown do. Such libraries define a simplified markup language that is much easier to use to describe how text formatting should be specified via the keyboard, then parse text formatted in that manner, translating the document into an HTML or XHTML formatted document. In fact, I type these articles in plain text files using Vim, entering Markdown formatting signifiers by hand, then run a script that uses a Markdown library to transform the text formatting signifiers into Web markup before it gets published here at TechRepublic.

If it keeps evolving to that point, my stripmark script will eventually do the inverse: it will translate HTML or XHTML formatted documents into text with simple text formatting signifiers that make emphasis, linebreaks, and other simplified “rich text” characteristics obvious without making the text nigh-unreadable the way an actual Web markup language does.

At the moment, the script is just a dirty hack. Even if it was cleaned up, prettied up, and made worth distributing, though, its use would still be a dirty hack. What’s really needed is for mail user agents and email clients to incorporate such safety related functionality directly, either via official plugins in the case of Unix MUAs or as integrated functionality in the case of mainstream GUI email clients.

By default, a “safety mode” for any e-mail client should perform a number of tasks for the user. A few examples include:

1. Disallow embedded images, Flash objects, or anything else that isn’t actual text and markup in the rendered “rich text” email display without a warning and specific user intervention.
2. Disallow hiding URLs behind link text so that even the most casual, security-ignorant user will not be fooled into thinking a link that says “PayPal” but has a URL with a phishing.example.ru domain is a legitimate PayPal link.
3. Disallow execution of any dynamic content, especially including JavaScript, VBScript, and similar programming languages, without a warning and specific user intervention.

The list could go on at great length, but it would probably be easier to just list things that should be allowed — like italicizing text, bolding text, underlining text, manipulating colors, and physically altering the visible location of content on the screen in a manner that doesn’t hide any content (such as via tables or CSS positioning). It should also clearly indicate when any text uses characters that are not part of the standard ASCII character set, just for good measure, in case someone wants to copy and paste a URL from an email to a browser.

This, at least, would allow people like me, who are aware of the security dangers of normal HTML e-mail rendering, to view the occasional marked up email without having to go to inconvenient lengths to read it without making ourselves susceptible to the dangers of rendered HTML emails.

Unless and until such a MUA or e-mail client that I want to use lands in my lap, though, I’d appreciate it if you’d all default to sending plain text e-mails only. Considering the overwhelming tendency of spammers and phishers to use HTML e-mail, and that most legitimate email users at least offer plain text along with the HTML formatted versions of their messages (whether they know it or not), my spam filtering identifies all HTML-only emails as high-risk targets. If I don’t expect your email, and it’s HTML formatted, you should be resigned to the expectation that I may never read it.

I value my security more than unsolicited emails, and — contrary to my usual policy of avoiding false positives at any reasonable cost — I’m willing to accept a few false positives to protect myself.

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools. Read his full bio and profile.

10 most damaging classic software development mistakes

In Steve McConnell’s book Rapid Development: Taming Wild Software Schedules, he defines “classic mistakes” as mistakes that have been made so often, by so many people, that the consequences of making these mistakes should be predictable and the mistakes should be avoidable. McConnell is CEO and Chief Software Engineer at Construx Software.

To determine the frequency and severity of common software development mistakes, the authors of this Construx Software Builders white paper surveyed 500 software practitioners. Of the 42 classic software development mistakes identified, these 10 mistakes are reported to be the most damaging:

1. Unrealistic expectations
2. Overly optimistic schedules
3. Shortchanged quality assurance
4. Wishful thinking
5. Confusing estimates with targets
6. Excessive multi-tasking
7. Feature creep
8. Noisy, crowded offices
9. Abandoning planning under pressure
10. Insufficient risk management

Several of the other 32 classic mistakes identified are: switching development tools in the middle of a project, developer gold plating, and friction between developers and customers.

Read the paper about software development’s classic mistakes to get more details about the survey results. Then, let us know how this list of 10 most damaging mistakes matches up with your work experience.

The four things every leader should know about good communication

We all know that communication is the key to all good things. What isn’t so clear is just exactly how to communicate well. Here is some actionable advice for leaders who want to succeed by communicating well.

——————————————————————————————————————-

The ironic thing about most communication advice we get form the “experts” is that they rarely provide actionable examples of how to communicate well. We hear up one side and down the other how important communication is, and it absolutely is, but how about telling us how to do it effectively?

I came across a blog by a guy named Jason Seiden who actually offers actionable advice for developing good communication skills. First, he explains what communciaton really is:

“Many of us have heard about the how the content of a message is as little as 7% of a communication, and how body language and tone of voice together make up the remaining 90%. What many of us don’t consider is that a communication event rarely happens in a bubble where the only elements being considered are voice, physicality, and content. Normally, a communication event is pregnant with all those other interactions that preceded it. You know, the baggage. If you want to communicate better, you need to minimize emotional baggage so that each one of your communications comes through clean and clear.”

He then explains that there are four aspects for a leader to consider when communicating. They are:

Direction: Top down or bottom up? Fair? Bilateral for some but not others? The direction of your communications signals whether you are broadcasting or conversing.

Frequency: Important things get repeated more often than non-important items. If you’re not repeating yourself, you’re not signaling the importance of the message.

Content: The content of the message starts before the actual message. It starts with the context. Two people can deliver the exact same message to greatly different effects. Why? Because their messages are pregnant with different things. A good communicator understands how his/her message is being interpreted and massages the content according to the filter being applied to it. This isn’t manipulation — it’s more like adjusting the tint on a TV.

Channel: You can say, “I want this to be a dialogue” all you want, but if you’re disseminating the message through a recorded video on your company’s intranet, then no one will believe you. Similarly, you may tell someone that you have some quick feedback for them on a project, but if instead of a quick e-mail, you put your notes into a formal memo and copy the VP, rest assured they will interpret your “feedback” as a formal reprimand and will feel sandbagged. The channel needs to match the intention.

Watch this video to see him talk about these aspects further.

Learn how to effectively communicate with these tools

Communication skills are necessary not only for interpersonal relationships, but they can also aid your career in incredible ways. If you can effectively communicate the need for a new tech initiative, for example, the better the chances you’ll get the go-ahead. Here are some tools that can help you improve your communication skills.

——————————————————————————————————————-

In information technology, it’s not difficult to find employees who are intelligent, hard-working, and have great passion for their work. But more and more headhunters and hiring managers are finding that interpersonal and business communication skills seem to allude even highly educated tech workers. The ability to effectively communicate is highly sought after in every job market, but most especially in the tech field where there is often the need to explain technical concepts in ways that other company employees and executives can understand.

I’ve done some scouting around and found a couple of tools from Global Knowledge that can improve your communication skills exponentially.

A two-day course called Effective Technical Communication teaches you best practices for authoring effective documents and composing your communications with clarity, relevance, and precision. In this course, you’ll learn how to prepare documents that clearly and concisely convey technical information to both technical and non-technical audiences. You will learn the five Cs of writing — correctness, clarity, conciseness, coherence, and contro — and how to apply them to your own writing. You will also learn how to copyedit documents written by you and others. (The cost is $1,495 USD, and vendor registration is required.)

A white paper called Four Key Elements of Effective Business Communication offers a perspective on business communication that involves four key elements: purpose, style, listening, and follow-up.

Does money make you happy, or does being happy make you money?

It’s highly unlikely that any employee would object to making a good salary. But is it too simplistic to think that money buys happiness?

——————————————————————————————————————-

We’ve just published our 2009 IT Skills and Salary Report. Here’s an excerpt from the report:

“The base majority of IT professionals are satisfied at work with 4 out of 10 being either ‘very’ or ‘extremely’ satisfied with their jobs. Indeed, the results show a direct correlation between job satisfaction and the amount of money that one is paid. Since more money equals greater job satisfaction, one could infer that for some, money does buy happiness–at least at work.”

While I’m not denying money can put a smile on most people’s faces, I’m wondering if this may be a case of what came first — the chicken or the egg. Instead of considering that money buys happiness, how about thinking of it as more money comes to people who like their jobs. If you like your job, you’re more likely to put in that extra effort, which is recognized by your manager who, in turn, issues you raises. If you’re happy in your job, it may have something to do with the fact that your talent is recognized with positive attention from your managers and others in the company. And that positive attention results in more money.

On the other hand, if you’re unhappy with what you do, you’re less likely to respond readily to new intiatives, and your negative attitude might impact effective communication with your co-workers.

What do you guys think?

Toni Bowers is the Head Blogs Editor of TechRepublic. She has been in the publishing industry for 20 years, with concentration in IT-related topics. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.

10 tips for securing a Microsoft Access database

A few best practices can go a long way toward protecting your Access data from careless or overly curious users. Here are some simple ways to add a few layers of security to a database.

---

Data is an asset. Therefore, data is money. Even if the data isn’t directly involved in the exchange of goods or services, it still has value. That’s why it’s so important to protect it. The operating system employs the best security, but it’s not always practical, especially on a stand-alone system. In the Access world, the next best thing is the user-level model (which Access 2007 doesn’t even support). User-level security is complicated and deploying it takes time and special knowledge.

When the best security measures aren’t possible (or necessary), you can implement less robust security measures to protect your data and design. Just keep in mind that the following tips prevent accidents by honest users and the mildly curious with enough knowledge to be dangerous. These tips don’t offer reliable security, in and of themselves. But by combining a number of them, you can get a level of security that’s better than no security at all.

Note: This article is also available as a PDF download.

1: Check and reset settings using the AutoExec macro

Use the AutoExec macro to check and reset security options that processes might have changed during the last work session. AutoExec is a special macro that executes when the database opens. To create an AutoExec macro, simply name a new macro AutoExec. For instance, the macro in Figure A runs a user-defined function named Startup(), which does the real work of checking and setting security properties before the user can go to work. The macro just executes it.

Figure A

Use the AutoExec macro to initiate important security settings.

2: Hide the Database window

Startup options, shown in Figure B, let you determine specific behaviors when the database opens. Two of these features lend a hand toward securing your database a bit:

• Display Database Window: Deselect this option, and the next time someone opens the database, Access will hide the Database window. Users won’t have immediate access to any objects.
• Use Access Special Keys: Deselect this option to inhibit the use of F11 to unhide the Database Window.

Figure B

Set startup options to hide the Database window.

Both settings work together. If you don’t deselect the Use Access Special Keys option, users can press F11 to unhide the Database window.

To access the Startup options, choose Startup from the Tools menu. In Access 2007, click the Office button and then click the Access Options button. Select Current Database in the left pane and you’ll find these options in the Application Options section. Access 2007 doesn’t have a Database window, but you can hide the Navigation Pane in a similar manor. That option is in the Navigation section just below the Application Options section.

Deselecting the Display Database Window option will also disable the Startup command. Users can bypass all these options by holding down the [Shift] key while opening the database. That trick’s handy for you, but leaves the database vulnerable to anyone else who knows about it. A user can also import objects into a blank database to bypass startup settings.

3: Bypass the bypass

You can use the interface to hide the Database window, but the [Shift] key bypass renders the database vulnerable to anyone who knows about it. That’s why there’s a bypass to the bypass… seriously. To close the bypass crack, set the AllowBypassKey property to False when the database closes. Automate this process by calling the following code from a close task — just which task is up to you:

Public Sub SetStartupOptions(propname As String, _

 propdb As Variant, prop As Variant)

  'Set passed startup property.

  Dim dbs As Object

  Dim prp As Object

  Set dbs = CurrentDb

  On Error Resume Next

  dbs.Properties(propname) = prop

  If Err.Number = 3270 Then

    Set prp = dbs.CreateProperty(propname, _

     propdb, prop)

    dbs.Properties.Append prp

  End If

  Set dbs = Nothing

  Set prp = Nothing

End Sub

When you call the procedure, be sure to pass the appropriate startup option text, as follows:

Call SetStartupOptions("AllowBypassKey", dbBoolean, False)

After setting this property during the close process, the database will ignore the [Shift] key bypass if one of your users is wily enough to try it.

Use this to set any of the startup properties. For instance, this call hides the Database window:

Call SetStartupOptions("StartupShowDBWindow", dbBoolean, False)

You can set options when you close or open the database with one exception. The AllowBypassKey property must be set when you close the database. Be sure to set a reference to the Data Access Objects library (DAO). Otherwise, this procedure will generate a reference error. (There’s bound to be an ADO alternative, but DAO is efficient in this area.)

It makes sense that anyone who knows about the [Shift] key bypass (#2) might also know how to enabling the [Shift] bypass by resetting the AllowBypassKey property to True. If this is the case, you’ll have to apply workgroup security to restrict access to this property to the administrator. Someone can try to reset the property, but the effort will fail unless that person is working through the administrator login.

4: Split the database

A split database is easier to protect than a single database that contains the data and the interface objects. By split, I mean having a database that stores tables and relationships in one database, known as the backend, and the interface objects in a second database, known as the front end. The two databases communicate through linked tables. Here’s why all that’s important: Users in the front end can’t alter the design of tables in the backend. (There are many reasons to split a database, but this discussion is about just security.)

To split a database, choose Database Utilities from the Tools menu. Then, select Database Splitter. The wizard will walk you through the process. In Access 2007, click Access Database in the Move Data group on the Database Tools tab.

5: Avoid Compact On Close

Anybody who uses Access knows that compacting regularly can mean the difference between a successful application and a bomb. Compacting makes a copy of the file, overhauls its objects, deletes temporary data, and rearranges the fragmented pieces on your disk. In short, compacting keeps a database in good working order.

Starting with Access 2000, Access offers the Compact On Close option, which compacts the database automatically when the last person closes it. Unfortunately, the process sometimes forgets to clean up after itself. If you find temporary files, with names like db1.mdb, db2.mdb, and so on, in the same folder as your database, they’re most likely a byproduct of the compact feature.

Those leftover files can be a problem. Anyone who has access to the folder has access to the temporary files, and that’s a breach in security. There are two ways to protect your database:

• Check regularly and delete any temporary files (but this isn’t really a practical or even effective solution).
• Don’t use the Compact On Close feature. This is the best way to protect a database from this particular vulnerability. Compact the database manually. You can even train someone to do it.

6: Hide objects — a subtle form of protection

It’s a good idea to hide objects — tables, queries, forms, and so on — from users. Doing so won’t protect these objects in the traditional sense, because if the user can find them, the user can alter them. However, if the user doesn’t know the objects exist, chances are the object will be safe enough from users who have no wish to break the database or steal data. Hiding objects simply keeps them safe from the mistakes an honest user might make, without malice or intent. To hide an object in the Database window (or Navigation pane), right-click it and choose Properties. Then, check the Hidden Attribute option.

Now, let me stress one more time (to save you the time of complaining) that someone who understands Access can unhide these objects just as easily as you can hide them. To view all hidden objects, you simply choose Options from the Tools menu, click the View tab, and then select the Hidden Objects option in the Show section. (If you select an object’s Hidden attribute, but the Database window still lists it, the Hidden Objects option is probably selected.) In Access 2007, right-click the Navigation pane’s menu bar, select Navigation Options, select Show Hidden Objects, and click OK.

As you can see, hiding an object doesn’t secure it; it just stores it out of sight (and out of mind). If you use this technique, remember that hidden modules are still visible in the Visual Basic Editor (VBE). In addition, consider hiding only the most important objects. A snoopy user who finds an empty Database window is apt to go looking. You can’t import hidden objects, which can be problematic if the import process is legitimate.

You can programmatically hide an object using VBA code, as follows

CurrentDb.TableDefs(tablename).Attributes = dbHiddenObject

In older versions (through 2000), assigning the hidden attribute to a table via code is problematic because Access flags the table as temporary. Then, during the next compact, Access deletes it, along with your data! Avoid this option if you’re working with an older version.

7: Use error handling to protect code

When code generates an error, VBA displays an error message similar to the one shown in Figure C. If a user gets that form and clicks Debug, he or she will be staring right into the heart of your application — the module that contains the error-generating code in the VBE. At this point, the user has full access to your code. Most likely, the user won’t know what to do and will call you for help. On the other hand, in a panic (or with a little mischief) the user could wipe out all of your code.

Figure C

Users can access your code by clicking Debug.

During the development stage, the ability to access code quickly is a timesaving feature. In a production database, it’s a disaster waiting to happen. As a matter of good practice, all procedures should have some level of error handling to inhibit the generic message and its Debug button.

8: Password-protect the database

A password is like a pin number — without it, you can’t access the database. Once you’ve password-protected a database, any user who wants access must know the password. There are third-party products that can crack a password-protected database, so this protection isn’t foolproof, but it’s an adequate tool nonetheless. To password-protect a database, do the following:

1. Open the database in Exclusive mode by choosing Open Exclusive in the Open dialog box, as shown in Figure D.
2. Choose Security from the Tools menu and then select Set Database Password.
3. Enter the password twice.
4. Click OK.

Figure D

Open the database exclusively to password-protect it.

The owner of the database can remove the password as follows:

1. Open the database in Exclusive mode.
2. Choose Security from the Tools menu and select Unset Database Password.
3. Enter the password.
4. Click OK.

You can also password-protect your VBA modules (code) as follows:

1. Choose project Properties from the Tools menu (in the VBE).
2. Click the Protection tab.
3. Check the Lock Project For Viewing option.
4. Fill in the two password fields (using the same password, of course).
5. Click OK.

Password protection is better than no password at all, but it won’t stop someone with the right tools and a little time.

9: Convert to mde or accde format

Access offers a security feature in the guise of a file format: mde and accde (in Access 2007). This format is an execute-only version of the database. That means users don’t have access to the code via the VBE, nor can they make design changes to objects. This format protects the validity of your design (mostly) but it doesn’t protect the data. (Be sure to keep a copy of the original mdb/accdb file for upgrades and other modifications.)

This format has it issues, as you might suspect:

• Use this format for the front end of a split database. Don’t use it to secure the backend or a stand-alone database. If you do, you’ll have to transfer all the data into a new database every time you upgrade the front end.
• This format doesn’t protect tables, queries, macros, relationships, database properties, or startup options.

To convert a front-end database to the mde or accde format, do the following:

1. In Access XP and earlier, choose Database Utilities from the Tools menu and then select Make MDE File. In Access 2007, click Make ACCDE in the Database Tools group on the Database Tools tab. (You can’t convert Access 2000 format or earlier.)
2. In the resulting dialog box, specify a folder and name for the new database and click Save.

10: Password-protect the system

You can’t expect users to never leave their system. And while the system’s unattended, your database is vulnerable — especially if users tend to leave the database open during breaks, lunch, and so on. You can set rules, but users forget.

One way to protect against intrusion is to password-protect the system’s screensaver feature. Windows’ screensaver kicks in when the system sits idle. If you password-protect the feature, the user must enter a login password to regain access to the system. Under Windows XP, you can password-protect the system’s screensaver, as follows:

1. Click Start and choose Control Panel.
2. Double-click Display.
3. Click the Screen Saver tab.
4. Select a screensaver (if necessary).
5. Set a Wait time — that’s up to you.
6. Check the On Resume, Password Protect option.
7. Click OK.

After the screensaver kicks in (step 5), a user must enter a login password to regain access to the system. If the database is networked, the administrator can set up this protection for everyone who uses the database, saving you the trouble of visiting individual computers.

Susan Sales Harkins is an IT consultant, specializing in desktop solutions. Previously, she was editor in chief for The Cobb Group, the world's largest publisher of technical journals.

10 ways to manage your risk with Web applications

Web apps continue to grow in popularity, but companies have legitimate concerns about security and reliability. Here are some ways to address potential risks and make sure you choose the right vendor.

---

Web-based software and services have proven to be a trend with staying power. Combine flexibility, relatively low maintenance and fees, and rich functionality and it’s easy to add up the benefits. Software as a service (SaaS), in particular, is playing out pretty well in today’s economy, according to IDC, which predicts the sector will see a 36 to 40 percent growth in 2009.

Yet many organizations, especially at the enterprise level, worry about offloading corporate data to a third-party vendor. Will security risks increase? What happens when reliability begins to suffer? How can they access critical data/systems during an outage? These are valid questions, but many experts actually think that your data is safest with a credible third-party whose business in effect is (or should be) managing the security and reliability of data across many customers. After all, if a vendor screws up, it will lose revenue, customers, and market share in a heartbeat.

Still, due diligence is imperative for any SaaS implementation. Here are 10 risk management factors to consider when offering Web-based software to your employees.

Note: This article is also available as a PDF download.

1: Identify a low-penalty area of the business to serve as your first SaaS project

The first time you enter an arrangement with a vendor to host software and data for you, avoid outsourcing a highly visible area of your business. If HR is not strategic to profits, that might be one place to start. Save the high-stakes CRM project for later, when you have learned a few best practices.

2: Assess your risk

Before you can come up with metrics and other requirements for vendors, you need to determine exactly which business and IT priorities of the data/system you want to outsource and what will be the fallout of any sort of breach or data loss. How do your internal requirements for encryption, network security, privacy, disaster recovery, auditing, and monitoring align with the services provided by the vendors under consideration?

3: Choose vendors carefully

No duh, you say. Yet in this case, it may mean selecting vendors with a long track record of providing Web-based software and services. You may have to pay more for established vendors, but doing so will likely lower your risk. “We use only brand name, well-vetted services,” says Josh Chernin, GM with Web Industries, a midsize manufacturing services provider. “We let someone else do the thinking (and risk) ahead of us. Currently, we are using Salesforce and Sharepoint.”

4: Do a deep dive on your SaaS vendor’s security infrastructure and approach

It’s not out of the question to request a third-party audit of the company’s security systems and policies. What security certifications does it hold? Is the company compliant with any relevant industry regulations, such as PCI DSS for credit card transactions? Gary Chen, an analyst with IDC, recommends the following checklist to start:

• How and where data encryption is used (for instance, on backups as well?)
• The quality of the network defenses in the data center
• How authentication and secure connections are handled
• The use of data loss protection (DLP) technology
• The question of multi-tenancy, since you’ll be sharing computing resources with other customers

5: Ask how your vendor handles disaster recovery

What protections will you have from your vendor in case of an outage due to system failure or natural disaster? Will you have offline access to the data? You can, for instance, ask your vendor if there’s a way to periodically store data into an on-premise system just for that purpose.

6: Get it in writing

Involve business and IT colleagues, client references of the vendor, your legal department, and whomever else might be helpful to ensure that you have an airtight contract. The document should cover not only financial terms but included services, performance metrics, and reliability and security provisions. How much uptime do you need and what does the vendor agree to do if they miss it? This could come in the form of fees, credits, or other creative paybacks.

7: Get chummy with your vendors

It goes without saying that you want a collegial not an adversarial relationship with your SaaS vendor. After all, they’re there to help your business grow and be more flexible, so think of them as a strategic business partner. Meet frequently to go over the metrics and to discuss how to improve experiences for your employees and external customers that may interface with the system. Now that you have freed up time of internal IT staff members who used to work on implementations and maintenance, dedicate at least one individual to managing this critical relationship.

8: Look out for new monitoring tools

Many businesses, as they grow in size, install system monitoring tools that keep an ever-present eye on networks, PCs, and applications for any abnormalities such as viruses, inappropriate access, or performance lags. Increasingly, such tools will include scanners that can also test Web applications for vulnerabilities. “This will be a huge area of growth in IT,” says Anton Chuvakin, a security blogger and director of PCI Compliance Solutions at Qualys.

9: Consider the help of a security consultant

Unless security is an area of expertise in your group, an outside consultant can help make sure that you are asking all the right questions and not overlooking any important technical details. For instance, Fred Kreitzberg, an information security consultant in Seattle, suggests asking questions such as whether your vendor can support your e-discovery requirements and how authentication is handled.

10: Devise a PR and response strategy

Regardless of how vigilant you are in selecting and managing vendors, there is always the chance that a security breach or data loss will happen anyway. Rest assured: The media and angry customers will be coming to you, not your vendors. Put together a plan stating which employers will be on your response team and what actions should occur in what order. Make sure you have a capable media relations expert on hand to help work responsibly and cordially with media inquiries. Avoid the tendency to withhold information: Customers and other stakeholders will want answers — and fast.