Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : MSFT Internet Explorer vs. NSCP Navigator -- Ignore unavailable to you. Want to Upgrade?

To: nommedeguerre who wrote (23197)	4/1/1999 3:18:00 PM
From: XiaoYao	Read Replies (1) \| Respond to of 24154

I agree most of your opinion. I think first, disable macro should be set as default and don't even ask users questions that they don't understand. If users want to use macro and understand it, they could enable it from options. Second, I also think attachment should be run as the lowest privilege, such as Guest on NT. It would prevent it from access all system resources. But on Win9x, it is not the option. But people would argue that would make programming really inconvenient, for example, an automation code would need to be updated each time when password changed. There is a trade-off between tight security and easy of use/convenient. For OS tight security is higher priority and for Apps easy of use win.

To: nommedeguerre who wrote (23197)	4/3/1999 10:35:00 AM
From: rudedog	Read Replies (1) \| Respond to of 24154

Norm - It looks to me like this whole range of security exposure is just laziness on MSFT's part. There is not sufficient granularity to the security options, which is a result of "quick and dirty" architectural choices throughout the office suite. There are at least 6 critical layers of security. The least risky would be the capability to alter the form or capability of the application itself - the appearance of menus, fonts, or other selectable features (NOT the ability to alter the basic capability of the application itself, including its security levels). The second would be the ability to share information or macro capabilities with other applications. The third would be the ability to access data outside of the application space (i.e. documents generally available to the user). The fourth would be the ability to execute user-level programs outside of the application space. A fifth and more critical layer is the ability to access data or resources which the user has security to access, but which are otherwise not generally available. Finally, and most critical, would be the ability to alter registry and other key system level components. Unfortunately, Win9X does not support most of these security levels, so a product suite which is intended to run in that environment is limited to the "lowest common denominator" of available security. Next, the ability to differentiate between various classes of objects which are available to a user is limited and requires a lot of programming which uses APIs which seem to change a lot between operating system and office suite versions, making such capabilities slow and potentially buggy. Finally, the way in which Office implements basic functions like file sharing and creation of temporary files counts on a pretty low and undifferentiated security model. So although I agree that there is some obligation on the user to understand and implement reasonable security, there is simply not enough capability in the base software to do that in a way which is both capable and convenient.