Michael, you aren't taking the security side of things seriously enough.
No more or no less than any other piece of code I'd argue. In my vision of this implementation, the resource string is visible and can be modified as well by the end user as they so need.
The major difference here is, when a user clicks on a file, they are repsonsible for clicking on that file and the consequences. When a user opens what appears to be a harmless checkers PDN document and it then reformats their hard drive (extreme case but possible with this kind of extension), then whose fault is it?
In the day and age where you get sued for selling coffee that is too hot, I know I wouldn't want to implement this kind of stuff in my pdn viewer without a layer of protection fot the user - IMO it is folly not to have some kind of security here.
Having thought some more about it, this is the kind of thing I think is acceptable.
1) When a user opens a PDN document, the PDN viewer first scans the entire document. If any resource tags are found, the viewer pops up a query to the user interactively saying something like:
- Code: Select all
"The PDN document you are trying to open contains external references that could potentially harm your computer. If you are sure the PDN comes from a trusted source, click continue, otherwise cancel."
(Perhaps a "details..." button can show all the resource references?)
This gets round any liability issues from the point of view of the PDN viewer author.
Also to make things more user-friendly there should be a security level on the PDN viewer. High - Ignore external resources, open the PDN without them. Medium - Always query the user as shown above. Low - Always trust all PDN docs. The user can set the security level to what they want, to avoid always having to answer security questions - if that is what they really want!
Does Nemesis implement any trust authentication scheme
No - because none is necessary. At the moment Nemesis cannot run malicious code or be abused by hackers.
1. It's not alot of work:
void MyResource (char *Resource)
That is not a lot of work, but I was thinking of the extra work to put on a security layer too. However the suggestion above isn't a massive amount of effort.
On one hand you vigurously dissuade me from this approach and yet, on the other, you use the same technology. Murray please clarify your position.
All I am saying is, great idea but beware the pitfalls! Just trying to help you out buddy, feel free to disagree!
And on the resource stuff: as long as it's definition is OS-independent I do not really care, my parsers ignore everything they don't understand
Hi Hans, I think other platforms can cope with Michael's suggestion as they will all have some way of associating an application with a file? I haven't tried to write a PDN parser on Mac Linux or Unix yet so I'm not really qualified - need more input from an expert in that area.
Have you never regretted tying Nemesis so close to IE? It is the most commonly used browser still but it certainly is inferiour to Opera and Firefox these days
Yes the other browsers are more efficient in their use of hardware resources and are better designed with regard to security. IE was a good choice at the time and still is, because it's good enough for the job, and handles well what I want it to do. I guess it's a case of using the tools that you are familiar with too, and I really didn't want to go through the learning curve of Java or C++ to handle the graphical side of things. Those who use Nemesis are probably not aware they are using internet explorer anyway! It looks just like any other program.[/b][/code]