3 ms·

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

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.

byecomputer 6y ago
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.
- resoluteteeth 6y ago
  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.
  - chrismorgan 6y ago
    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.
    - resoluteteeth 6y ago
      > 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.
      - byecomputer 6y ago
        They could always try asking me if I want to be tracked, no code injection necessary.
chrismorgan 6y ago
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()).
- jannes 6y ago
  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.
  - chrismorgan 6y ago
    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.
    - jannes 6y ago
      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/WebExtensions/manifest.json/content_scripts https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

byecomputer 6y ago

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.

resoluteteeth 6y ago
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.
- chrismorgan 6y ago
  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.
  - resoluteteeth 6y ago
    > 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.
    - byecomputer 6y ago
      They could always try asking me if I want to be tracked, no code injection necessary.

chrismorgan 6y ago

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

jannes 6y ago
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.
- chrismorgan 6y ago
  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.
  - jannes 6y ago
    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/WebExtensions/manifest.json/content_scripts https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...