Add "prevent-console-hijack(ing)" scriptlet?

[contribucious]

Hello,

  A lot of websites like TF1.fr hijack window.console — allowing them, if necessary, to send the results of console.error, etc. to their servers.

This forced me to create this userscript in Tampermonkey because of my many uses of console.xxx during my tests:

// ==UserScript==
// @name         Force keeping native window.console on different websites
// @namespace    http://tampermonkey.net/
// @version      0.3
// @description  Force keeping native window.console on different websites (currently: various catch-up TV websites).
// @author       Contribucious
// @match        http*://*.6play.fr/*
// @match        http*://*.rtlplay.be/*
// @match        http*://*.tf1.fr/*
// @run-at       document-start
// ==/UserScript==

(function() {
    'use strict';

    // Based on: https://humanwhocodes.com/blog/2014/04/22/creating-defensive-objects-with-es6-proxies/

    // Function(s)
    function createDefensiveObject(target, wanted) {
        return new Proxy(target, {
            get(target, prop) {
                if (prop in wanted) {
                    return wanted[prop];
                }
            }
        });
    }

    // Main
    unsafeWindow.console = createDefensiveObject(window.console, unsafeWindow.console);
})();

// @grant none must not be present (i.e. sandbox required here for this to work).

 

:arrow_right: What about adding an equivalent in AdGuard, to be added here afterwards, as:

• example.org#%#//scriptlet('prevent-console-hijack') or
• example.org#%#//scriptlet('prevent-console-hijacking'),

… to keep a name similar to prevent-window-open and others? 🙂

[ameshkov]

Not the same thing, but kinda relevant since dev tools detection also relies on console: https://greasyfork.org/en/scripts/41559-devtools-anti-detector/code

I have a question, though. Do you think it makes sense to have this as a general-purpose scriptlet or just use it when debugging?

I think that scriptlets that are supposed to be used for debugging purposes need a special prefix, something like "debug-prevent-devtools-detection".

[contribucious]

I was having this same thought earlier when I saw the list here of some used for debug purposes, yet mixed without distinction with the "standard" ones in this global list. I support the idea of a prefix then.

Regarding your question, personally, I only consider it for my website analysis sessions, so … "debugging".

The case of prevent-console-hijack is to be able to simply work in analysis / inspection with complete peace of mind on a specific website, for a certain period of time, without a monitoring by the latter for sure, by doing various tests in the DevTools > Console part, but also related to any source generating console.log/warn/etc. whether it comes from myself directly, a (Tampermonkey) userscript used to print some stuff for inspection with conditions, another scriptlet, etc. Knowing that we can be sure that our trial and error is not monitored / analyzed later at all, basically.

One could imagine dev- or advanced- or adv- (for power users who like privacy and do little development but like privacy when testing). But that might complicate things: it's probably better to keep just debug- though.

[contribucious]

Speaking of debugging (and of JSON recently):

[…] :arrow_right_hook: (moved to a dedicated issue) :heavy_check_mark:    

---

By the way … (update: PR available :heavy_check_mark:)

 

json-prune, which I think should be added to this list visible below, right?

The following scriptlets may be used for debug purposes when applied without any parameters:

requestAnimationFrame
prevent-setInterval
prevent-setTimeout

Update 2021/12/17

I'll try to find the time to do a PR on this (and also include what's new since: prevent-fetch, prevent-xhr, …).  

Update 2022/03/21

See/Follow PR [wip] update debug-scriptlets section by @stanislav-atr. 🙂