Hacker News Reader

Comment by chrismorgan | Hacker News Reader

Any guesses on why it creates the script element rather than just executing the JavaScript directly? Surely nothing would actually be looking out for a __gaOptOutExtension element in the DOM? (… to say nothing of it creating an incorrect DOM by inserting the script element as an immediate child of the <html> element, rather than inside the head or body.)

  window["_gaUserPrefs"] = { ioo : function() { return true; } }

View on HN

Chrome Extension content scripts are evaluated in an isolated JavaScript environment which does not share variables with the page's JavaScript.

By creating a script in the page itself, the "_gaUserPrefs" variable is made accessible to the Google Analytics script.

Having to circumvent your own extension policy that prevents tracking in order prevent the tracking you were doing is not the best way to look competitive.

It's not "circumventing" a "policy." Injecting html is what you're supposed to do in this situation because it's safer than allowing contentscripts to directly execute javascript in the page context. This is how all chrome extensions do it.

Injecting HTML is a terrible idea. It has extreme overhead compared to just evaluating some JavaScript in the page context, and it will break the occasional page that expects certain things of its DOM, and it’s fairly inevitably broken when you have CSP things. The DOM belongs to the document. You shouldn’t touch it unless you actually have to to provide your functionality, and this isn’t such an extension. There’s a a proper mechanism for executing scripts in the document context, which should be used.

> There’s a a proper mechanism for executing scripts in the document context, which should be used.

Which is?

Edit: In the interest of saving time, it looks based on your other comment that you're referring to chrome.tabs.executescript, but code executed this way executes as a content script so it doesn't run in the page context and can't communicate with javascript running on the page.

If there's another way of running code in the page without injecting html I'd love to hear about it, though.

They could always try asking me if I want to be tracked, no code injection necessary.

Ah, that makes a lot of sense and explains the bad idiom. I think, then, that it should be something like this instead?

  browser.tabs.executeScript({
    code: `
      window["_gaUserPrefs"] = { ioo : function() { return true; } };
    `,
    allFrames: true,  // And maybe this for good measure?
    runAt: "document_start",
  });

(Spelled browser for WebExtensions, and chrome for most Chromium-based browsers.)

This may well be incorrect or incomplete. I’m not properly familiar with the details here. I haven’t made any browser extensions in the WebExtensions era, all I’ve done is plenty of Greasemonkey scripts, where you can use unsafeWindow.eval() for these purposes (and there, if you instead did unsafeWindow._gaUserPrefs = …, you’d run into a SecurityError when the user code tried calling _gaUserPrefs.ioo()).

That wouldn't work, because it needs to execute before the analytics script. The runAt:"document_start" doesn't really do anything unless you invent time travel.

I imagine it’d be no different from whatever it does at present—this is just about replacing the script element insertion technique, it doesn’t control when this script is actually executed.

I was talking about the use of `browser.tabs.executeScript`. You have to define a content script [0] in the manifest instead. I presume that's what Google's extension does, too.

[0]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Reply on news.ycombinator.com