在所有地址上运行我自己的用户脚本是否有风险? [英] Is it risky to run my own userscripts on all addresses?
问题描述
Tampermonkey(适用于大多数浏览器)和 Greasemonkey(适用于 Firefox)同时支持 @match 和 @include 指令.
Tampermonkey (for most browsers) and Greasemonkey (for Firefox) support both @match and @include directives.
当我开始阅读它们之间的区别时，结果发现 @match 更严格一些:不会在某些地址上启动 userscript，这可能被认为有潜在危险或只是不需要.
When I started to read about the difference between them, it turned out that @match is somewhat stricter: userscript will not be launched on some addresses, which could be considered as potentially dangerous or just unwanted.
- https://wiki.greasespot.net/Include_and_exclude_rules
- https://wiki.greasespot.net/Metadata_Block#@match
由此产生了一个问题:
a) 在所有地址(即@match *://*/* 和 @include 相同)?
a) Is there any potential risk to launch my own userscripts on all addresses (i.e. @match *://*/* and the same for @include)?
或者，b) 在某些地址上启动用户脚本的限制仅与 3rd-party 用户脚本相关，即从某些站点下载并因此可能包含一些恶意代码的用户脚本?
Or, b) the limitations of launching userscripts on some addresses are relevant for only 3rd-party userscripts, i.e. userscripts which were downloaded from some sites and therefore potentially containing some malicious code?
推荐答案
在所有地址上运行您自己的用户脚本是否存在潜在风险?是的，一个小的；见下文.
Is there any potential risk to run your own userscript on all addresses? Yes, a small one; see below.
(目前)不在所有页面上运行您自己的用户脚本的主要原因是:
The main reasons (currently) not to run your own userscript on all pages are:
- 浏览器性能:加载和运行脚本需要时间、CPU 周期，有时还需要磁盘访问.通常情况下，延迟几乎不会引起注意，但如果它没有提供有用的服务，为什么还要延迟呢?
- 意外的副作用:您认为您的
$(".someclass").remove();代码只影响 X 页——直到它没有.挠头，然后是可选的诅咒……
其他常见的副作用包括 导致页面或用户脚本失败的脚本冲突. - iframes:默认情况下，脚本在 iframes 上运行，并且一些页面有几十个 iframes 和/或 iframes 嵌套了好几层.
这是性能和副作用问题的乘数. - 风险:泄露敏感代码: 使用
$.get( "frbyPlay.me/pics?user=admin&pw=1234"...，在非沙盒中代码和错误的站点可以看到它(或 AJAX).
使用页面的JS时，攻击的途径是无限的.幸运的是，这通常是一种非常低的风险并且很容易减轻，但无知或自满可能会导致严重的尴尬. - 风险:接触绝命毒师":最近，以前备受喜爱和信任的扩展变成了邪恶.
当您的脚本使用的某些库(如 jQuery)被黑客入侵或商业优化"时会发生什么?脚本运行的页面越少，发生恶作剧的机会就越少，损害传播越低.
(当然，如果 Tampermonkey 本身也长了山羊胡子，那么无论如何我们都会被掠夺.)
- Browser performance: Loading and running a script takes time, CPU cycles, and sometimes disk-access. Normally, the delay is hardly noticeable, but why have it at all if it is not performing a useful service?
- Unexpected side effects: You think your
$(".someclass").remove();code only effects X pages -- until it doesn't. Head scratching, and optional cursing ensues...
Other common side effects include script clashes that lead to page or userscript failures. - iframes: Scripts run on iframes by default, and some pages have scores of iframes and/or iframes nested several levels deep.
This is a multiplier for the performance and side-effects concerns. - Risk: Leaked sensitive code: Use
$.get( "frbyPlay.me/pics?user=admin&pw=1234"..., in non sandboxed code and the wrong sites can see it (or the AJAX).
When using the page's JS, the avenues for attack are infinite. Fortunately, this is usually a very low risk and easily mitigated, but ignorance or complacency can lead to major embarrassment. - Risk: Exposure to "Breaking Bad": Recently, a formerly much loved and trusted extension turned evil.
What happens when some library that your script uses, like jQuery, gets hacked or "commercially optimized"? The fewer pages the script runs on, the less chances for shenanigans and the lower the damage spread.
(Of course, if Tampermonkey itself ever grew a goatee, then we're pwned regardless.)
<小时>
请注意，原因 1 和 2 也是您应该尽可能多地使用 @match 而不是 @include 的原因.@match 可以更快地解析网址，并且在不需要/意外的网站上触发的可能性也大大降低.
(并且，在 Tampermonkey 中，@match 在 Tampermonkey 仪表板中添加了那些小站点图标.)
Note that reasons 1 and 2 are also why you should use @match as much as possible instead of @include. @match parses web addresses faster and is also very much less likely to trigger on unwanted/unexpected sites.
(And, in Tampermonkey, @match adds those little site icons in the Tampermonkey Dashboard.)
这篇关于在所有地址上运行我自己的用户脚本是否有风险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
