Do I need to use "@grant unsafeWindow" if I want to use unsafeWindow API?
8,586 views
Skip to first unread message
tomchen
Aug 25, 2012, 5:30:36 AM8/25/12
to greasemon...@googlegroups.com
Do I need to use "@grant unsafeWindow" if I want to use the unsafeWindow API?
Here http://wiki.greasespot.net/@grant it reads:
If a script specifies any values (or they have been auto detected), then it will be provided with only those API methods that it declares.
The valid values are the names of those
So, non GM_ prefixed API method, unsafeWindow, can be used or not?
Here http://wiki.greasespot.net/@grant it reads:
If a script specifies any values (or they have been auto detected), then it will be provided with only those API methods that it declares.
The valid values are the names of those
GM_ prefixed values that you wish your script to be granted access to.So, non GM_ prefixed API method, unsafeWindow, can be used or not?
tomchen
Aug 25, 2012, 5:50:07 AM8/25/12
to greasemon...@googlegroups.com
BTW, another question: if no @grant is specified, and no API method is used, the script will run without sandbox, making it able to access variables in the page, which means, a lot of userscript will no longer run in the security sandbox, does it become less safe to do so?
Anthony Lieuallen
Aug 25, 2012, 9:23:27 AM8/25/12
to greasemon...@googlegroups.com
On Sat, Aug 25, 2012 at 5:50 AM, tomchen <tomch...@gmail.com> wrote:
Do I need to use "@grant unsafeWindow" if I want to use the unsafeWindow API?
No. If you "@grant none" the window is the unsafe window. For backwards compatibility, the variable named "unsafeWindow" is provided, as a direct alias to the "window" object. If you @grant anything else, you run in the legacy mode which has a different window and unsafeWindow.
BTW, another question: if no @grant is specified, and no API method is used, the script will run without sandbox, making it able to access variables in the page, which means, a lot of userscript will no longer run in the security sandbox, does it become less safe to do so?
Safe in what way?
tomchen
Aug 25, 2012, 6:46:24 PM8/25/12
to greasemon...@googlegroups.com
Thank you.
"less safe" I mean, those script without @grant and GM_xx, may use window.xx without any intention of modifying the variables in the page, because they know it runs in sandbox, if they want to modify the variables in the page, they will use unsafeWindow.xx rather than window.xx. But now, window suddenly becomes able to access unsafeWindow, may it cause problems and conflicts?
It'd be better if, when no @grant is specified, and no API method is detected, the script will run in sandbox.
"less safe" I mean, those script without @grant and GM_xx, may use window.xx without any intention of modifying the variables in the page, because they know it runs in sandbox, if they want to modify the variables in the page, they will use unsafeWindow.xx rather than window.xx. But now, window suddenly becomes able to access unsafeWindow, may it cause problems and conflicts?
It'd be better if, when no @grant is specified, and no API method is detected, the script will run in sandbox.
Anthony Lieuallen
Aug 25, 2012, 7:22:44 PM8/25/12
to greasemon...@googlegroups.com
The "unsafe" in "unsafeWindow" is that it exposes the privileged GM_* functions to the content page: and that page could in theory do something unsavory with them.
If you "@grant none" then there are no privileged GM_* functions (that's the whole point!), so that vector of unsafe-ness does not exist, so you don't need to worry about it. There's nothing to put in a sandbox.
You also use the ambiguous phrase "without @grant and GM_xx". I take that to mean: a legacy script that does not specify any @grant line, yet _does_ call GM_* functions. In such a case, Greasemonkey detects and acts as if there was a @grant line (with all the same legacy sandboxing).
If your script gets privileged access, it lives in the sandbox that makes that safe. If it doesn't, then it doesn't.
If you "@grant none" then there are no privileged GM_* functions (that's the whole point!), so that vector of unsafe-ness does not exist, so you don't need to worry about it. There's nothing to put in a sandbox.
You also use the ambiguous phrase "without @grant and GM_xx". I take that to mean: a legacy script that does not specify any @grant line, yet _does_ call GM_* functions. In such a case, Greasemonkey detects and acts as if there was a @grant line (with all the same legacy sandboxing).
If your script gets privileged access, it lives in the sandbox that makes that safe. If it doesn't, then it doesn't.
Message has been deleted
tomchen
Aug 25, 2012, 10:17:36 PM8/25/12
to greasemon...@googlegroups.com
I thought that "unsafe" means that the script can do something unsavory by using unsafeWindow to access variables in the page, getting information from these variables, sending them somewhere...
OK, Forget about the safety things.
Sorry, "without @grant and GM_xx" actually should be "without @grant or GM_xx", where I meant a script that does not specify any @grant line, yet does NOT call GM_* functions. For such a script, Greasemonkey 1.0 acts as if it specifies "@grant none", a lot of scripts are affected. I'm just wondering if it may cause compatiblity problems and conflicts for some scripts.
Example:
test.user.js:
=================CODE==================
// ==UserScript==
// @name test
// @include http://localhost/test/test.html
// ==/UserScript==
(function () {
window.addEventListener("load", function () {
window.myVar = "modified";
}, false);
})();
=================END===================
localhost/test/test.html:
=================CODE==================
<!DOCTYPE html>
<html lang="en-US">
<head>
<title>test</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<script>
var myVar = "original";
window.addEventListener("load", function () {
window.setTimeout(function() {
alert(myVar);
}, 1000);
}, false);
</script>
</head>
<body>
</body>
</html>
=================END===================
It shows "modified" in Greasemonkey v1.0, but shows "original" before v1.0.
OK, Forget about the safety things.
Sorry, "without @grant and GM_xx" actually should be "without @grant or GM_xx", where I meant a script that does not specify any @grant line, yet does NOT call GM_* functions. For such a script, Greasemonkey 1.0 acts as if it specifies "@grant none", a lot of scripts are affected. I'm just wondering if it may cause compatiblity problems and conflicts for some scripts.
Example:
test.user.js:
=================CODE==================
// ==UserScript==
// @name test
// @include http://localhost/test/test.html
// ==/UserScript==
(function () {
window.addEventListener("load", function () {
window.myVar = "modified";
}, false);
})();
=================END===================
localhost/test/test.html:
=================CODE==================
<!DOCTYPE html>
<html lang="en-US">
<head>
<title>test</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<script>
var myVar = "original";
window.addEventListener("load", function () {
window.setTimeout(function() {
alert(myVar);
}, 1000);
}, false);
</script>
</head>
<body>
</body>
</html>
=================END===================
It shows "modified" in Greasemonkey v1.0, but shows "original" before v1.0.
Sam Larison
Aug 25, 2012, 10:31:26 PM8/25/12
to greasemon...@googlegroups.com
This is because the script does not use unsafeWindow.myVar = "modified"; if it had then even in the old version the variable would appear "modified"
The unsafe is basically so script authors know that the site the script is running on could mess with the script or do strange things, so you are trusting the site the script is running on to not do anything malicious using the GM_functions. The site could easily pick on the user and the user might wrongly blame the script author. This is what makes it unsafe. Most sites do not bother with such things, although there are probably a few glaring examples of abuse.
The unsafe is basically so script authors know that the site the script is running on could mess with the script or do strange things, so you are trusting the site the script is running on to not do anything malicious using the GM_functions. The site could easily pick on the user and the user might wrongly blame the script author. This is what makes it unsafe. Most sites do not bother with such things, although there are probably a few glaring examples of abuse.
Since grant none does not expose GM api, unsafe window is no longer unsafe.
You still must trust the script/script author regardless. Basically you only have to watch out for gm_xmlhttprequest, and it's usage is often non-invasive and beneficial. If they use gm_xmlhttprequest and they use unsafeWindow without specifying grant none you are fully trusting the site the script is running on to not abuse the API.
It seems like it will not cause compatibility problems from what Anthony just said, scripts that do not specify any grant rule auto grant privileges based on usage of API, which means unsafeWindow is still unsafe unless you specify grant_none or your script doesn't use GM_functions.
It seems like it will not cause compatibility problems from what Anthony just said, scripts that do not specify any grant rule auto grant privileges based on usage of API, which means unsafeWindow is still unsafe unless you specify grant_none or your script doesn't use GM_functions.
With a little bit of understanding one can easily add grant none and see if the site is overtly abusing the privilege, however some functionality may be broken in the process of testing this.
Sam Larison
Aug 25, 2012, 10:43:45 PM8/25/12
to greasemon...@googlegroups.com
To clear up one error in my previous message, I am pretty certain, in the old version, any usage of unsafeWindow meant that all of the GM_functions were exposed. Now I think only the explicitly
granted (or in the absence of grant, the presently used) functions are exposed. I am not certain how this search for used functions is performed, if the search includes comments, etc.
On Sat, Aug 25, 2012 at 10:31 PM, Sam Larison <samla...@gmail.com> wrote:
If they use gm_xmlhttprequest and they use unsafeWindow without specifying grant none you are fully trusting the site the script is running on to not abuse the API.
Anthony Lieuallen
Aug 25, 2012, 11:27:07 PM8/25/12
to greasemon...@googlegroups.com
On Sat, Aug 25, 2012 at 10:43 PM, Sam Larison <samla...@gmail.com> wrote:
There are not any currently known "leaks" of the API functions. It's
possible for a poorly or maliciously written script to directly expose
them (i.e. "unsafewindow.anything = GM_xmlhttpRequest -- even still,
they should be impossible for the content page to call. should be).To clear up one error in my previous message, I am pretty certain, in the old version, any usage of unsafeWindow meant that all of the GM_functions were exposed. Now I think only the explicitly granted (or in the absence of grant, the presently used) functions are exposed. I am not certain how this search for used functions is performed, if the search includes comments, etc.
But the fewer "not known" and "should"s involved, the better. There's no way for a @grant none script to do anything the page couldn't do on its own.
Example:
...
window.addEventListener("load", function () {
window.myVar = "modified";
}, false);
This is an anti-pattern. It's not a good thing to do. If scripts do this and break, they should be fixed. You have to explicitly do the "window." part of that assignment for there to be a chance for anything to break -- and before Greasemonkey 1.0 there was never a good reason to do that. (Though I've been surprised before with the creative things people have done, so I might be over-stating this.)
But the short version is: Yes. Greasemonkey 1.0 changes things. That's why the major version bump (0.x to 1.x). I believe the vast majority of real scripts will be unaffected, or trivial to fix. This isn't an accident. It's a probably only slightly bumpy path to what I believe to be a better state, in the future.
tomchen
Aug 30, 2012, 9:17:21 PM8/30/12
to greasemon...@googlegroups.com
http://www.greasespot.net/2012/08/greasemonkey-10-jquery-broken-with.html
https://github.com/greasemonkey/greasemonkey/issues/1614
The broken @require jQuery is exactly what I concerned about -- window.myVar confict problem. I think Greasemonkey should at least add a metablock that can control whether the script runs in sandbox or or. Otherwise, authors who want their scripts where any API is not used or detected, to run in sandbox, should add "@grant GM_xx", or a comment "//GM_xx" making it auto-detected by greasemonkey, although they don't need to use GM_xx API.
https://github.com/greasemonkey/greasemonkey/issues/1614
The broken @require jQuery is exactly what I concerned about -- window.myVar confict problem. I think Greasemonkey should at least add a metablock that can control whether the script runs in sandbox or or. Otherwise, authors who want their scripts where any API is not used or detected, to run in sandbox, should add "@grant GM_xx", or a comment "//GM_xx" making it auto-detected by greasemonkey, although they don't need to use GM_xx API.
Reply all
Reply to author
Forward
0 new messages