The only person who can view file:/// content is you. (the owner of the computer) No one else can. (out there in the Internet world) So in that sense, it is completely safe. Even if people know that you have some GmScript where you have a text file in a known location and name that can have values in it (preferences, options, data, whatever) and know the exact location on your hard drive, they cannot read it.
There is a trick that is sometimes used to freak non-computer savvy people out. Make a link to file:///C:/ and tell people to click on it and then claim that you can see everything on their hard drive. People who don't know how these things work tend to freak out and think they've been hacked. It's good for a laugh. Because it's a read-only situation, and you can't automatically set up that file, the user would have to do it manually, it is only good for certain things. It would be doable for a computer-savvy person to use, but not a newbie or others like that who can barely turn their computer on, which is the greater majority of people. I haven't tried the iframe thing, but I can see where it might be a problem. I'd have to try it and mess with it to be sure, but I don't have the time or interest. Even a pop-up window might have similar problems. I tried to open a window in the script and it failed, so maybe that won't work in scripts. Again, I would have to mess with it. There are usually work-arounds. That's why there are the Gm_getValue and Gm_setValue functions to store and retrieve data for scripts. Madepally Kiran wrote: > Yeah, this is a tweak that would work. However, I guess the included > pages should include the "file://" based link. > (file:///C:/temp/textvars.txt) or "file://*" - giving access to all > the files on the disk. (I didn't expect it to work, considering the > security issues, but apparently, it does) > In this case, we would be asking the user to provide access to the > local files by showing him that the "file://" entry on the include > portion - there is no guarantee he would take it seriously :P. > > In any case, it would be a potential security risk. Even if it is > barely read-only, one could compromise any critical file and perhaps > post the message online. I think it would be recommended to allow the > "chrome://" protocol (even that is a security risk, but it may be > moderate since it is limited to the firefox extensions - or one could > limit it further to some namespace for the extension), rather than the > "file://", which would give access to the whole file system. > > Next, about appending an iframe - its will not be accessible (will be > considered as cross-domain); atleast, thats how it should work. It is > the security requirement when using HTML directly. > > Yeah, for now, you can open a seperate tab or a popup window and do > the task. It should work. But lets hope it doesn't work later :). May > be we need some sort of security enhancements to deal with this issue. > > -Kiran > > > On Tue, Aug 4, 2009 at 11:36 PM, BD <[email protected] > <mailto:[email protected]>> wrote: > > If you do something like: (this will cause a "flash" in the > browser if you save and reload the file, which would also have to > be checked for so it doesn't execute in an infinite loop, so you > will have to mess with it somehow to make it all work better -- > maybe create an inline frame to do it?) > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "greasemonkey-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/greasemonkey-users?hl=en -~----------~----~----~----~------~----~------~--~---
