2

Tampermonkey (for most browsers) and Greasemonkey (for Firefox) support both @match and @include directives.

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.

From this arose the question:

a) Is there any potential risk to launch my own userscripts on all addresses (i.e. @match *://*/* and the same for @include)?

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?

Brock Adams
  • 90,639
  • 22
  • 233
  • 295
john c. j.
  • 725
  • 5
  • 28
  • 81

1 Answers1

4

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:

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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.)

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.)

Brock Adams
  • 90,639
  • 22
  • 233
  • 295