[Greasemonkey] global storage script and security inquiry

[Bill Donnelly]

I (think I) understand the "violating user expectations" and
"assumptions of safety" security issues, (and related issues)
but I think there are magnitudes of difference between those
and someone being able to read any file on your hard drive or
grab your credit card # and send it to some site over there
without you knowing about it.

So, when you consider these "power functions" that Gm offers
over and above "standard Javascript", the only one I see that is
actually, obviously, "questionable" in its ability to cause bad
things to occur, is GM_xmlhttpRequest. It seems that it is quite
different in power and potential abuse than the others. (or any
other 'standard JS' code in a script) Altho I admit that I'm not
particularly well-versed in its use and ability.

* GM_log - log messages to the JavaScript Console
* GM_getValue - get script-specific configuration value
* GM_setValue - set script-specific configuration value
* GM_registerMenuCommand - add a menu item to the User Script Commands 
submenu
* GM_xmlhttpRequest - make an arbitrary HTTP request

I've tried to keep abreast of the security issues and understand
them as well as I can, with varying levels of appreciation and
understanding, so I'm not sure how much truth and reality there is
in my observation/suggestion. (/questions/ponderings)

Jeremy Dunck wrote:

 >On 9/2/05, Bill Donnelly <donnelly at snowcrest.net> wrote:
 >
 >>I was also wondering, is the *GM_xmlhttpRequest* access the only real
 >>security problem that Gm opens to the world?
 >>...then I request that there be a way to turn it off.
 >
 >I think a pref to disable APIs wouldn't be too onerous, as long as the
 >UI didn't suck.  I don't like the idea of a pref per API func-- even 0
 >APIs won't protect against an evil user script, and so far, a way to
 >get at any API func has been a way to get at them all.  So, turn them
 >all off if you want to be paranoid safe, or don't if you don't.
 >
 >>/*Other than that, Gm has the same "security issues" that regular /
 >>non-Gm Javascript has, doesn't it?*/
 >
 >Yes, we break the security model in novel ways.  Since GM introduces a
 >3rd party into what's assumed to be a 2-party security model, I'm wary
 >of assumptions of safety.  Do I know of any issues?  Uh, no, but that
 >doesn't mean much.