|
|
|
| Top | Networking Windows | Programming Windows |
By Tom Henderson
By now, the world is all over the streets, the online areas and the Web: Windows 95's policies have numerous security holes. The good news is there are ways to plug them.
The problem with Win95 policies is that they aren't entirely bug-free, and this can present network security issues. Policies contain their share of locks, but locks only keep your friends out. Your enemies have pick tools. Software hacks on the Internet can make short work of cached password files, and they can crack system policies like an eggshell. The pick tools they need are just an Internet surf session away.
Network-enforced (mandatory) user policies take user or group membership to give specific amounts of control to Win95 system use. If you store user profiles locally, users can thwart them. If you store them on a network, users can still get around them through clever manipulation of system resources.
The easiest way to bypass user policies is simply to copy POLEDIT or REGEDIT from a Win95 CD-ROM, and change certain settings in the user's profile (I won't say which ones). You can make the CD-ROM or shared copies of POLEDIT and REGEDIT inaccessible, but a lot of users have the CD-ROMs at home. Users can also hack shared system policies by overwriting settings via a DOS 7.0 Win95 machine start. They can bypass administrative goals by replacing the policy files with those that don't enforce downloaded policies. A third method is to invoke the new version of TASKMAN.EXE (via a Ctrl+Esc sequence) during start-up.
All three of these methods pick locks, and users can easily find them-along with more involved schemes-on the Internet and various BBSes.
At the very least, you should employ a few mandatory policies to prevent users from shooting themselves and their administrators in the foot. Remember, policies are designed not only to control, but also to enable functionality and consistency.
The functionality comes from choosing options that wouldn't be obvious to most users. Make important options-such as default services, network client software selections and desktop selections-uniformly available. The consistency comes from grouping together machines that look and operate alike. Training costs go down, help-desk support personnel have an understood common denominator of environmental characteristics, and updates or changes distributed across network groups have a good chance of working without the costs of exception handling.
Consistency is nice, but some users genuinely need to customize their environments. You have to strike a balance between shared policies and the legitimate need for customization. Some preventive policy selections that few users can gripe about can reside in the background.
The first few preventive mandatory system policies revolve around NetWare installations of Win95. There's a feature in the 32-bit Microsoft Client for NetWare that allows the PC to be advertised on a network as a Novell file server, although it's turned off by default. If someone enables this feature, it will cause problems if the PC has the same name as a legitimate server.
Many companies name their NetWare servers after their companies. My company's server is named Unitel. Let's say a well-intentioned user on our network names a machine Unitel, and enables NetWare SAP (the service advertising protocol that announces the presence of NetWare servers on the network). When users log in, their machines will point to the pseudoserver instead of the real one. Disable this by right-clicking on Network Neighborhood and choosing Properties. Select the MS Client for NetWare, then click on Properties. Change the SAP protocol selection to No. After you close the windows, Win95 will restart and drop from the network as a server.
Another possible trouble spot is File and Printer Sharing. Some users legitimately need to get to others' files and printers. But unless you secure File and Printer Sharing (the Windows 95 Resource Kit details how to do this), security problems will arise.
The security difficulty stems from passwords. Although Microsoft updated its password algorithm (get the update from Microsoft's various sources now), the new version is a hacker's dream. Hacks are getting passwords and encryption passwords for most software products, as well as the log-on passwords to various places.
Your defense: Turn off password caching. Users will scream about having to type their passwords, but in most cases, you have no choice. Similarly, you can eliminate another hole by reducing file and print sharing, where possible, as a default mandatory system policy. (See WINDOWS Magazine Online Locations for one such method. )
Most network e-mail packages require you to use a static location for the address of either mail software or post office locations. If users make changes to Microsoft Exchange's mail data directory (unless you're using UNC filenames), they can dislocate themselves from their mail. One of our users at Unitel did just that, and after a week questioned why his mail had plummeted from 20 messages a day to zero. Our version of Exchange wants to see the path M:/MAILDATA. Only one of Unitel's seven servers and one of our 27 volumes has that mail directory. Because he fooled with drive mappings he wasn't able to see the Exchange post office and therefore, any of his mail. This fix is also available online.
As editorial director Fred Langa mentioned in his January feature story, "Lock Your Windows," and in his December Start column, setting policies can go a long way toward plugging security holes, but a skilled hack can get through anything. Check the online areas and Microsoft's Web site to learn more about security enhancements and known bugs. For the official line, turn to Microsoft's Knowledge Base at http://www. microsoft.com/kb/ and mirror sites, as well as WINDOWS Magazine's forums and Web site.
There's a trade-off with network-downloaded policies. Users with home PCs often have the time to become familiar with Registry, and therefore, policy manipulation, and they'll be tempted to apply these tricks at work. These types can thwart even the highest degree of mandatory policies, but most users won't mind the continuity these policies bring. This continuity keeps them in the automated loop, and if they have problems you can solve them quickly. As for the others, they'll be relegated to the exception handling category. In other words, "Fool with it and we'll get to you later." Of course, nothing is foolproof, because fools are so ingenious.
Contributing Editor Tom Henderson is vice president of engineering for Unitel, Indianapolis. Contact Tom in the "Networking Windows" topic of WINDOWS Magazine's areas on America Online and CompuServe, or care of the editor at the addresses on page 18.
| Top | Networking Windows | Programming Windows |
By Martin Heller
Click Here to see a
4KB bitmap image of artwork
which goes with this article, entitled:
Word Up
<Computer bleeps, simulated jungle disappears.>
As I'm sure you know, this reference is to Star Trek: The Next Generation. Science fiction, for sure, but is it that far off?
One of the icons on my computer's taskbar shows two vertical bars within a cartoon balloon. It means Microsoft Voice will listen to any command as long as I first say "computer." Alas, I don't have a holodeck, but I can do some of my work without touching mouse or keyboard.
Microsoft Voice certainly isn't the be-all and end-all of voice-control software. It recognizes only a small, controlled vocabulary, which means it's useless for dictation, and its text-to-speech engine sounds irritatingly mechanical. What makes it interesting is that its engine conforms to Microsoft's Speech API. What's even more interesting is that I can write applications using the Speech API and upgrade to a more capable speech engine without changing my code-at least not much. If you decide to work with the Speech SDK yourself, you'll need to license a compatible speech engine from any of the dozen vendors listed in the SDK's ENGINE.DOC.
The Speech API, available in the Speech SDK on the MSDN Level II CD, uses COM for its interface. COM, which I discussed last month, is built on the IUnknown interface, which has AddRef, Release and QueryInterface methods. Initialize the COM library with CoInitialize, and you can create an object using CoCreateInstance.
The Speech API has four basic divisions: two complexity levels of two voice directions. Voice commands and voice text are simple, but limited. Speech recognition and text-to-speech are more complex, but also more flexible. Voice commands rely on the speech-recognition APIs, which, in turn, rely on a speech-recognition engine, which is fed by an audio source. Voice text relies on the text-to-speech APIs, which rely on a text-to-speech engine, which feeds an audio destination. A typical audio source would be a sound card and a microphone or telephone input. A typical audio destination would be a sound card and speakers or a telephone output.
Speech makes interacting with your computer easier by eliminating the need to type, providing aural feedback, avoiding complex menus and allowing telephone access. There are trade-offs, however. Aside from the poor quality text-to-speech engines, speech recognition is not 100 percent accurate. You can improve recognition rates by using context clues and restricting the allowed vocabulary. You can get better-quality spoken output from recorded digital-audio (.WAV files) than you can from text-to-speech engines, but you may find recording all the possible voice responses in some applications difficult or impossible. If you try combining .WAV files with text-to-speech engine output, you'll find the real voices make the machine sound even worse by comparison.
Consider a spelling-drill program. You can't write such a program without some sort of audio output-flashing the word on the screen would be a giveaway. You could depend on prerecorded words, but then the teacher or parent would have difficulty adding vocabulary. You could even record the whole dictionary, like Microsoft did for Bookshelf, at a cost. Recording all the words in the dictionary took Microsoft almost a year of studio time, and the resulting .WAV files are so bulky, the finished product-even with compression-must ship on a CD.
On the other hand, if you use voice-to-text or text-to-speech, you could probably ship a spelling-drill program on one floppy disk. The program could have a main screen with a couple of big buttons, a display area for the student, a control menu for the teacher and a big vocabulary list in a file or database. It would choose words from the vocabulary, speak them and wait for the student to type in the spelling.
It would be better if the student didn't have to type. In the lower grades, where spelling drills are important, most students don't type well. What you'd really want is for the program to pronounce the word, the student to spell the word aloud and the program to give feedback on whether the word was spelled correctly.
Some issues arise at this point. Do you allow, or require, the student to repeat the word, as in a spelling bee? What do you do when the student mumbles or hems and haws? What happens when you pick up extraneous sounds? You don't want this application to be frustrating; you want it to be functional and enough fun that the students will use it and save their parents hours of boredom.
In fact, you need a lexicon and a grammar even for something as simple as spelling a word. For instance, you probably need to ac-cept "Receive. R-E-C, umm, E-I, er, V-E" as correct, but reject "R-E-C-I-E-V-E" as incorrect. You probably want to allow some spoken control words and phrases as well: "Stop," "Start over," "Please repeat the word," "I don't know" and so on.
How would you go about implementing such a thing? First, you need to understand the interfaces built into the Speech SDK and the speech engines' capabilities.
Let's start with the voice-command API, which revolves around three components-the system voice-command object, one or more voice-menu objects and a voice-menu enumerator. With voice commands, the user says something, and the speech-recognition engine tries to transcribe it. Then the engine compares the resulting text with the possible commands in all the currently active voice menus. If the utterance matches a command, the application that owns that voice menu is notified.
You can add voice-command support to your application using COM by calling CoCreateInstance with class CLSID_VCmd and interface IID_I- VoiceCmd. That returns a pointer to the IVoiceCmd interface for the voice-command object. IVoiceCmd::Register tells the voice-command object where to get its voice commands and where to send notifications of valid commands.
The source of a voice command is called a site. This site consists of an audio input device, such as a microphone or telephone, and a speech-recognition mode. An engine typically provides several modes for recognizing speech, each representing a different language or dialect.
Notifications come to your IVCmdNotifySink interface. This interface is part of a COM object your application creates. If you want anything to happen in response to a given voice command, implement code in IVCmdNotifySink::CommandRecognize for that command string.
Once you register, call IVoiceCmd: :MenuCreate to open a voice menu and create a voice-menu object to represent the menu. MenuCreate returns the voice-menu object's IVCmdMenu interface. You can modify the voice menu dynamically using its member functions.
If using COM is too difficult, or inappropriate for your application language, you can use OLE Automation to implement voice commands. It's a snap in Visual Basic and Microsoft Office applications. Most integrators can add voice commands to Word and Excel with a little training.
Do voice commands satisfy the input requirements of a spelling-drill program? Probably not. I've already shown you that you'll need to support some grammar, and you now know voice commands are basically just notifications of voice menu picks. You'll need to dig deeper and look at the speech-recognition API.
At the speech-recognition level, audio input arrives through the audio source, the speech-recognition engine processes the input, attempts to translate it into text with the help of one or more grammars, and passes the text to the application. Implementing speech-recognition capabilities in an application involves three main COM objects: an audio-source object, an engine object and a grammar object. You can also use the speech-recognition enumerator, the speech-recognition sharing object and the speech-recognition results object.
To set up for speech recognition, you can create an audio-source object (CLSID_MM- AudioSource, the WAVE_MAPPER device by default) and an engine object. Or, you can use an engine and an audio source that are shared with other applications through the speech-recognition sharing object by calling CoCreateInstance with class CLSID_SRShare and interface IID_IE- numSRShare. In either case, you'll Select the engine and mode you want, and load one or more grammars with ISRCentral::GrammarLoad.
That done, you can tell the recognition engine to listen using a loaded grammar with ISRGramCommon::Activate and to stop with ISRGramCommon::Deactivate. Grammars can be of the context-free, dictation or limited-domain form, depending on the engine's capabilities. Generally, the engine vendor supplies a grammar compiler. The Speech SDK also allows you to specify a grammar on the fly using binary grammar structures. That would be one way to implement voice input for our spelling-bee program.
Remember, you have three voice-output options: voice-to-text, text-to-speech and prerecorded .WAV files. The latter would sound the best, but would be the most expensive to prepare and ship. Would voice-to-text work for you?
Implement the voice-to-text API using a voice-to-text COM object. This object is also exposed for OLE automation. Create a voice-to-text object by calling CoCreateInstance with class CLSID_VTxt and interface IID_IVoiceText, and getting back the object's IVoiceText interface, which has member functions for registration, speaking and speech control. IVoiceText::Speak does the grunt work of putting a string into the voice-text playback queue. It also allows flags for the priority of the message in the queue and the type of message to be spoken (a statement, a question, a warning, numbers, an instruction to the user or material from a file).
That sounds like plenty of control for a spelling-bee application. If you wanted to go to the trouble of using the text-to-speech API, you could improve the pronunciation of many words-perhaps eliminating the tell-tale "Norwegian moose" effect-by adding tags to the text to control voice inflection, speed and pitch, or even by sending phonemes instead of text.
The complexity involved in using the raw text-to-speech APIs is similar to using raw speech recognition: You'll need to use enumerators and select your engine and mode, your audio destination and so on. Adding this level of control might be worthwhile for a commercial product if you can coerce the speech engine into delivering noticeably clearer pronunciation with tags or phonemes than it can with plain voice text, which depends on the quality of the engine's pronunciation lexicon.
If you needed the computer to speak whole sentences, it would be more important to move to this level. A pronunciation lexicon can help only with individual words. To achieve acceptable prosody, the application needs to adjust the emphasis, intonation, inflection, accent and timing of the words in the sentence. "Spell cat" is a simple enough sentence that marking it as an instruction for the user when sending it to the speech engine should suffice to make it understandable. On the other hand, consider, "You must become Caligari. You must become Caligari. You must become Caligari." You need to add emphasis to the italicized words and some phrasing to the sentences to capture the hypnotic quality desired. Fed to a speech engine as is, this text sounds ludicrous.
What can I say? (No, computer, put that silly speech menu away. I didn't mean it.) Computer speech technology is still in its infancy, and it takes a lot of work to use it to its full advantage. Your next step would be to start browsing through the Speech SDK yourself and to contact a few speech engine vendors.
Meanwhile, I've got other things to do.
"Computer, save."
"Computer, send document to WINDOWS Magazine."
"Computer, close window."
"Computer, start running Space Cadet Table."
<Music up, sound of steel ball clicking into place.>
When Martin Heller talks, computers listen. Sometimes people do, too. Visit Martin's Web page, http://www.winmag.com:80/people/mheller, send him e-mail at mheller@cmp.com.
|
|
|