|
Vern, Here are my feelings: - An installation program should never adopt authority. If major authority is required, then the documentation should instruct the user to sign on as QSECOFR. - Objects within the application should be owned by an application-specific profile. - Any changes to system-level values should be well-documented and prominently featured in the documentation. Justification for these changes should be included in the documentation and provided prior to the actual sale of the product. I think your goal of maintaining a trustful relationship with your customers is best met by clear documentation and communication. You're smart enough to know the questions a security-conscious techie is going to ask. Answer them all in advance and in writing. You can also assume that when you initiate a relationship, you are not trusted. The relationship goes beyond technical concerns and would also include sales techniques, licensing requirements, and pricing. If any of these facets rub your customers the wrong way, then they may also question the technical side of your applications. Regards, Andy Nolen-Parkhouse > What would you need from a vendor in this situation? Is a section in > the > documentation sufficient? We certainly don't have anything to hide and > do > not want to cause any concerns to anyone. What helps a trustful (made > up > word) relationship with a vendor? > > Anyone can reply to this - I'm interested in various points of view. > > Regards > > Vern
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.