tag:blogger.com,1999:blog-8999648290761146346.post7209746793928785037..comments2022-11-09T04:02:07.813-07:00Comments on Reid’s Interwebsblogg: Mozilla Developers Hate Saved HTML ManualsReidhttp://www.blogger.com/profile/01705216128276218311noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8999648290761146346.post-14085124697471206802010-04-15T07:13:24.619-06:002010-04-15T07:13:24.619-06:00A workable solution for me is to deploy the AS3_Re...A workable solution for me is to deploy the AS3_Reference file structure to a web server on my localhost.Pete O'Bryanhttps://www.blogger.com/profile/02553946995789109884noreply@blogger.comtag:blogger.com,1999:blog-8999648290761146346.post-27184957677334140342008-12-03T10:26:00.000-07:002008-12-03T10:26:00.000-07:00I'm not sure which bug reports you are referring t...I'm not sure which bug reports you are referring to so I can't comment on whether or not the Mozilla developers are hostile. That said, about the basic issues:<BR/><BR/>a) This seems like a special case with the Adobe documentation. I'm not sure what the default security policy is for other browsers like Internet Explorer. It would be nice if you could specify something like "allow JS files to be executed inside C:/mySandbox". I'm guessing it's possible to create an extension that does exactly that, but I wouldn't know where to start myself. Have you checked the NoScripts addon? It's apparently very robust and supports whitelisting of trusted websites (including, I'm assuming, local websites).<BR/><BR/>b) I agree that the error message should be more descriptive and user facing. Firefox 3 could probably do a better job of explaining what it's doing and why.David Tenserhttps://www.blogger.com/profile/05574199440316966145noreply@blogger.comtag:blogger.com,1999:blog-8999648290761146346.post-67124320100257091512008-12-03T09:37:00.000-07:002008-12-03T09:37:00.000-07:00David,As I mentioned, I believe the security probl...David,<BR/><BR/>As I mentioned, I believe the security problem is real, though I appreciate your explanation -- nothing I saw in the Mozilla docs for the config variables, in a Google search, or in the Bugzilla had anything remotely as coherent; thanks, now I understand the problem.<BR/><BR/>However, as I mentioned, by beef is not with the attempt to fix this security problem -- it's that Mozilla completely ignored this use case, and (judging from the bug reports I looked at) developers are hostile to any sort of nuance on the matter.<BR/><BR/>The basic issues are:<BR/><BR/>(a) the sandbox is badly defined for file:/// URLs. The Flex docs consist of thousands of files. It's ridiculous to put them all in the same directory, it's silly to duplicate the JavaScript files into each necessary subdirectory, and there's an installed base of HTML docs that can't be changed for whatever reason.<BR/><BR/>(b) the problem is completely opaque. Give me an error message that I can Google. Don't hide the information because I'm too dumb to deal with it properly.<BR/><BR/>Why do I need to specify this global on/off switch (which in fact is less expressive than the preference item it replaced)? Why can't I define the size of the file:/// sandbox rather than relying on Firefox to choose it (badly)?Reidhttps://www.blogger.com/profile/01705216128276218311noreply@blogger.comtag:blogger.com,1999:blog-8999648290761146346.post-40764591008996194002008-12-03T02:23:00.000-07:002008-12-03T02:23:00.000-07:00There's an important reason why Firefox 3 doesn't ...There's an important reason why Firefox 3 doesn't allow these scripts to run by default: security. Downloaded scripts are run in a restricted “sandbox” environment that isolates them from the rest of the operating system, including folders outside the scope of the web page. Scripts are permitted access only to data in the current document or closely related documents. No other access is granted to the local file system, the memory space of other running programs. Containment of this kind is designed to prevent malfunctioning or malicious scripts from wreaking havoc in the user’s environment. <BR/><BR/>By setting that preference to false like you did, you essentially give JavaScript full control to not just all your files on your hard drive (including any personal documents you might have stuffed with passwords, secrets, and what not), but also to do full directory listings, meaning it can "see" the directory structure and names of all files and folders on your hard disk. I am sure that there are plenty of evil examples out there that can show why allowing this is generally a bad idea. <BR/><BR/>There is no reason for the browser (or the user) to trust the code such as that found on Web pages, so JavaScript is executed in Firefox 3 as if it <I>were</I> hostile.<BR/><BR/>Mozilla is just doing what it can to protect you, and that's the reason why they aren't eager to tell the world how to disable this security. They provided the pref for valid use cases like yours, though. That said, please be aware that you've also enabled access for any other local script you might have or download in the future.David Tenserhttps://www.blogger.com/profile/05574199440316966145noreply@blogger.com