Modifying Navigator Object Topic is solved

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10459
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Modifying Navigator Object

Unread post by New Tobin Paradigm » 2021-06-27, 17:53

How about you just put the work in the basement and stop for the good of everyone.
Conversion Software Version 7.0
Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 431
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Modifying Navigator Object

Unread post by RealityRipple » 2021-06-27, 18:27

Because I have too many never-finished projects as it is, and this is actually pretty interesting.

Just tried overriding window.Promise using this code:

Code: Select all

class NewPromise extends Promise
{
 constructor(executor)
 {
  super(
   function(_resolve, _reject)
   {
    console.log(gBrowser);
    return executor(wrappedResolve, wrappedReject);
   }
  );
 }
 then(success, reject)
 {
  console.log(gBrowser);
  return super.then(wrappedSuccessHandler, wrappedRejectHandler);
 }
}
window.Promise = NewPromise;
The content script's console.log(Promise) returns a function() with the name "NewPromise", but the extension's "wnd.Promise" (wnd = subject) still spits out a function() with the name "Promise", and none of the attempts to spit out gBrowser are run, let alone outputting a value or undefined. That messes with my view of how context works, but I guess it's a good thing in the end.

Edit: I guess the Xray protection thing would apply again, here, protecting chrome from content by using the base-class prototypes of window, even though everything else is content-context?

Unfortunately, this also means I can't compare wnd.Promise to Promise as they're technically two different implementations, one for content, the other for chrome.

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 431
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Modifying Navigator Object

Unread post by RealityRipple » 2021-07-20, 09:30

New rewrite on this using wrappedJSObject instead of waiving Xrays. Essentially it boils down to cloning the return value, exporting the promise function, and then the stuff I was doing before, but using wnd.wrappedJSObject for the context and wnd.navigator.wrappedJSObject to insert the new object in navigator.

Code: Select all

let dpc =
{
 request: function(consentRequestsList)
 {
  return new wnd.wrappedJSObject.Promise
  (
   Components.utils.exportFunction
   (
    function(resolve, reject)
    {
     resolve
     (
      Components.utils.cloneInto
      (
       {
        consent: [],
        withdraw: [],
        _object: []
       },
       wnd.wrappedJSObject
      )
     );
    },
    wnd.wrappedJSObject
   )
  );
 }
};
wnd.navigator.wrappedJSObject.dataProtectionControl = Components.utils.cloneInto
(
 dpc,
 wnd.wrappedJSObject,
 {
  cloneFunctions: true
 }
);
This way, hopefully, the parent Promise and the return data will start off in Content context rather than Chrome context, and stay there the whole time. No more warnings, no more weird behavior.
Last edited by RealityRipple on 2021-07-20, 17:00, edited 1 time in total.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 30824
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Modifying Navigator Object

Unread post by Moonchild » 2021-07-20, 10:50

Sounds a lot safer, yes.
"Just because you know something is going to break in the end, doesn't mean that it can't have an effect that lasts into the future. Joy. Wonder. Laughter. Hope. The world can be better because of what you built in the past." -- Tom Scott
Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 431
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Modifying Navigator Object

Unread post by RealityRipple » 2021-07-25, 09:31

New changes to this extension as of yesterday and today.

Turns out I completely misunderstood the "object" parameter. Also, turns out, the underscore in "_object" was just for the IDL definition pseudocode. Now there's a checkbox in the extension preferences to populate this parameter or not, with a link to Article 21.

Support for the 'decisionchange' event was managed with some unpleasant injection into the page's content when an event listener is added. I basically listen for and trigger a CustomEvent within chrome code, then pass it to content code as the injected custom "AdpcEvent" with my own addEventListener, removeEventListener, and dispatchEvent functions in the navigator.dataProtectionControl object. Lots more wrappedJSObject and cloneInto()/exportFunction() usage to make it all work. And yes, it's probably not good that the object isn't a true EventTarget. And yes, it ignores the "options/useCapture" parameter of addEventListener and removeEventListener at present. I might add support for "once" in the future. Fairly sure "capture/useCapture" and "passive" don't really apply to this event, though I guess I could at least use "passive" for the return value of dispatchEvent() anyway.

I simplified and standardized the prompting paradigm, getting rid of the preference to show a dialog directly when called with JS: it'll always show a doorhanger first. And I made it so previously selected choices are not prompted for again in JS, as apparently the spec intends JS to call the navigator.dataProtectionControl.request() function any time they want, so that the server (or a script) doesn't have to store a user's preferences; they can just ask for them again. The preference to show site-provided text in the doorhanger still exists, and is still false by default for security reasons.

I also tried to minimize the ability to abuse this standard for tracking by always sending responses with 'withdraw=["*"]' in JS, just like I did for headers and tags, rather than specifying the ID of every denied or ignored request. Users can still potentially be tracked via requests with unique IDs, but only if they choose "Accept" for such a request.

Additionally, it's apparently against the GDPR to have a "always allow", so I changed the "Default Response: Unset/Accept/Reject" dropdown to a "Reject All" checkbox in the preferences dialog as well.

Finally, I added a URLBar icon (Image) which opens the Page Info dialog to the Permissions tab, because the GDPR also says "Withdrawing consent should be as easy as giving it" at the end of Article 7. It only shows up on sites that the user's browser has an ADPC entry for, of course.


As a test, my website now uses ADPC whenever you change Page Styles. If navigator.dataProtectionControl exists, the site saves the "style" cookie only if allowed, and uses the 'decisionchange' event to create or delete the cookie immediately when you change it in the extension preferences or the Page Info dialog (if the site is open at the time).

While this standard is still definitely dangerously bad, a good implementation mitigates a decent amount of that danger.

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10459
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Modifying Navigator Object

Unread post by New Tobin Paradigm » 2021-07-25, 15:59

So does the blocklist. I hope your impl is solid else there could be a problem.
Conversion Software Version 7.0
Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 431
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Modifying Navigator Object

Unread post by RealityRipple » 2021-07-25, 16:11

I'm still definitely not planning to ever submit this one to the official list, but I'm pretty sure everything that can be done to make as much of this run in Content context as possible has been. And in a less hacky way than WaiveXrays. I'll keep a few testcases on my site to make sure Chrome is never inadvertently leaked to Content. I actually need to write a new one to see if overriding the new "AdpcEvent" can cause trouble.

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10459
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Modifying Navigator Object

Unread post by New Tobin Paradigm » 2021-07-25, 16:57

Your submission is irrelevant. If it breaks security it will be placed on the blocklist. Make sure it doesn't.
Conversion Software Version 7.0
Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 431
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Modifying Navigator Object

Unread post by RealityRipple » 2021-07-25, 17:47

There's a bug where making a new AdpcEvent class within Content code caused the extension to break, but one try{} around the instantiation and call fixes that. Context-wise, though, it's definitely Content. No access to "browser", "gBrowser", or the extension's "adpc_control" class, no access to Chrome-level window, document, or navigator objects. Tested in constructor() and set userDecisions(), which are the only things of AdpcEvent the Chrome-context script touches. I also tested get userDecisions(), just in case; same thing. So no security break.

I just have to decide what to do about pages that might redeclare AdpcEvent. But I think as long as I'm injecting its declaration into the content's code, it's gonna be content-editable. And declaring it as part of navigator.dataProtectionControl wasn't working out too well, and definitely would be risky since it would be declared within Chrome context. But since it's literally passed as a Content-context parameter to the Content-context callback function, which is also client-defined, it should definitely not ever bleed into Chrome with this setup. Plus, this potentially lets developers add other properties to the event, should that need arise. And if it fails because the required "userDecisions" property has been changed or removed, I guess I'll just show a warning about it in the Browser Console and skip calling that callback in the stack.

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10459
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Modifying Navigator Object

Unread post by New Tobin Paradigm » 2021-07-25, 19:24

I'd recommend you show it in the Toolkit Error Console. DevTools Consoles aren't a guaranteed thing to be present outside of Phoenix-class web clients or in the future. Put simply, don't rely on any behavior or facility provided by MozDevTools (or Jetpack for that matter). It is also not within the scope of the Toolkit Error Console to monitor the Google-spec browser console object.

As for the security point, if there isn't a problem.. There isn't a problem. Though I still question why anyone especially in California would care about EU Nonsense or insane specs. But I guess that is a self-answering question if you think about it.
Conversion Software Version 7.0
Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 431
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Modifying Navigator Object

Unread post by RealityRipple » 2021-07-25, 20:21

I just used console.log for now.

California's got the CCPA, but the GPC protocol made for it is basically identical to DNT, but with a boolean javascript property in navigator and a /.well-known/ json file.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 30824
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Modifying Navigator Object

Unread post by Moonchild » 2021-07-25, 23:02

Dude, sec-GPC is already in our issue tracker and I'll tackle that when it's prudent.
"Just because you know something is going to break in the end, doesn't mean that it can't have an effect that lasts into the future. Joy. Wonder. Laughter. Hope. The world can be better because of what you built in the past." -- Tom Scott
Image

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10459
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Modifying Navigator Object

Unread post by New Tobin Paradigm » 2021-07-26, 00:26

So really, isn't all this redundant and academic at best?
Conversion Software Version 7.0
Image

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 30824
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Modifying Navigator Object

Unread post by Moonchild » 2021-07-26, 00:36

No there's 2 different things here

GPC = Global Privacy Control, which is the signal for websites to "not share or sell data"
the other is Data Protection Control which is the complex, stupid permissions system for cookie configurations at a global API level instead of per site. (which is what RealityRipple has been working on with his extension). DPC is basically a way to try and reduce the annoyance of GDPR cookie dialogs on every bloody site.
"Just because you know something is going to break in the end, doesn't mean that it can't have an effect that lasts into the future. Joy. Wonder. Laughter. Hope. The world can be better because of what you built in the past." -- Tom Scott
Image

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10459
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Modifying Navigator Object

Unread post by New Tobin Paradigm » 2021-07-26, 01:25

DPC would include control of the storage APIs as well.. But how can global control instead of per-site even work with our current permissions system. Doesn't that amount to just a response if the site can store first or third party cookies?
Conversion Software Version 7.0
Image

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 30824
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Modifying Navigator Object

Unread post by Moonchild » 2021-07-26, 01:39

I don't really know how the API works for websites and to be frank I don't even want to know. it's just more trying to pour something like this into a "mobile app permissions system" sort of thing. I suspect there are plenty of ways around it, too, not to mention it's going to make it much more difficult to enforce that websites are actually going to do what you tell them to do (or not do) with your data because something global like that can't really do more than broad stroke permissions, I think.
"Just because you know something is going to break in the end, doesn't mean that it can't have an effect that lasts into the future. Joy. Wonder. Laughter. Hope. The world can be better because of what you built in the past." -- Tom Scott
Image

User avatar
moonbat
Knows the dark side
Knows the dark side
Posts: 3395
Joined: 2015-12-09, 15:45
Contact:

Re: Modifying Navigator Object

Unread post by moonbat » 2021-07-26, 07:50

Far better to take control of one's own browsing and block the hell out of unwanted cookies, scripts and tracking crap than depending on a website to pinky swear to not track you with all these new fangled protocols.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
Linux Mint 20.1 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 431
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Modifying Navigator Object

Unread post by RealityRipple » 2021-07-26, 07:55

Yeah, there's zero programmatic control. It's all "the website is legally obligated to do it" with nothing even remotely server-side part of the definition. 100% signalling.

Post Reply