First Party Isolation

[Latitude]

First Party Isolation would be implemented in FF 52, according to Tor Browser blog.

https://blog.torproject.org/blog/tor-heart-firefox

Devs, would it be implemented in PM or not?

[Touchscreen Madness]

What exactly is "First Party Isolation" and how does it relate to Tor? The blog you linked to doesn't bother to explain.

[Fedor2]

This is about that many sites have connections to another sites for tracking. Consider that all which belong to the site are first party, and googlefonts, googleapis, facebook are not.
If you care about the privacy you are to block them all, but some sites become unusable because of the blocking. So to overcome this addons like decentraleyes was developed.

How it will be done in the Firefox is unclear, and in that link is only casual mention.

[HaleSun]

There is no need to implement this in Pale Moon, as the extension "uMatrix" does this by default. All scripts, plugins, frames, etc are blocked except for those of first-party origin. The uMatrix UI also allows for highly granular control making it far more powerful and effective than addons like Ghostery and more flexible than NoScript.
https://addons.mozilla.org/en-US/firefox/addon/umatrix/

However, as stated first party isolation will break many sites or greatly limit their functionality which is understandably why Firefox will have this feature disabled by default (most likely for the foreseeable future).

[kizo07]

I use Decentraleyes on the top of uMatrix (+whitelist hosts)...close to overkill, but anyway, sometimes 'I believe I can fly'

[GreenGeek]

Not overkill at all; they serve different functions. I even have reinstalled Request Policy and Blocksite Plus because uMatrix lets some connections through unless you get just the right configuration.

[dark_moon]

Not overkill at all; they serve different functions. I even have reinstalled Request Policy and Blocksite Plus because uMatrix lets some connections through unless you get just the right configuration.

Can you explain this more? I have set uMatrix to only allow css+pictures for origin domain, so all 3th party stuff is blocked.

Also Request Policy isnt in development anymore.

[CharmCityCrab]

It'll be interesting to learn how Firefox does this if it really gets implemented. Reason being: Just doing this in the most literal possible way would break a lot of websites, and a mainstream browser like Firefox can't afford to do that by default. Maybe they have found a way to make websites work anyway, or are adding this as an option that's not the default.

I would imagine that Pale Moon developers will have to look and see exactly what Firefox does and how they do it before determining if it is something that is desireable and if it will work with Pale Moon's code base. There isn't enough available information right now on it.

[Edit: Read the article, Firefox is going to disable this by default. I wouldn't waste my time on this if I were a Pale Moon dev, given the limited number of devs and limited time and resources PM has. This is not a mainstream feature. It breaks too much of the Internet. Let users use umattix or other add-ons if they want that feature. To me, this is only worth doing if it doesn't break websites, and it does, so it's not. If someone can find a creative way around it breaking sites, then would be the time to consider adding it IMO.]

[GreenGeek]

I have set uMatrix to only allow css+pictures for origin domain, so all 3th party stuff is blocked.

No, all other connections are not blocked by default just based on what you see in the matrix, but the ones that originate from within opened pages might be (haven't attempted to get proof). There are things connecting other ways that uMatrix doesn't block by default. Some (all?) of these are covered by the various "matrix scheme" labels, but I doubt most people understand those well (I still don't know what all each of these covers and I started using HTTP Switchboard in Chromium before uMatrix was created as far as I know). I haven't kept a list, but I have seen them in the log. I guess we could compare notes on the various schemes enabled and what gets through if desired. I know extensions for one thing do make connections behind the scenes but not necessarily produce any visible activity (mostly OK but some are questionable).

Also Request Policy isnt in development anymore.

It's true the original developer more or less quit. Then a couple of other guys started a "fork," Request Policy Continued." But that one is SDK, so it won't work in PM27 yet; but, it might after the next release. The original one still works in current PM.

[kizo07]

Not overkill at all

Yes, you are right. But also I was thinking about fingerprinting and generally I prefer not 'so many' add ons. uBO+Decentraleyes+uMatrix (with Decentraleyes+NoScript and some others rules) satisfied pretty much my needs. I have 'light' and 'flying' user experience too.
btw thanks for uMatrix tip you published somewhere here before ('ua-spoof: palemoon.org false'). In one week I wondered what's going on.

[HaleSun]

No, all other connections are not blocked by default just based on what you see in the matrix, but the ones that originate from within opened pages might be (haven't attempted to get proof). There are things connecting other ways that uMatrix doesn't block by default. Some (all?) of these are covered by the various "matrix scheme" labels, but I doubt most people understand those well (I still don't know what all each of these covers and I started using HTTP Switchboard in Chromium before uMatrix was created as far as I know). I haven't kept a list, but I have seen them in the log. I guess we could compare notes on the various schemes enabled and what gets through if desired. I know extensions for one thing do make connections behind the scenes but not necessarily produce any visible activity (mostly OK but some are questionable).

The advanced features of uBlock Origin and uMatrix often overlap so I sometimes forget which features belong to what, but it sounds like what you are looking for is uBlock's dynamic filtering, which was designed to be "a complete replacement of RequestPolicy":
https://github.com/gorhill/uBlock/wiki/ ... -filtering

By default, certain behind the scenes requests are allowed as to not break the web, but if you know what you want to block, you can create finely-tuned rulesets to block all those hidden connections as well:
https://github.com/gorhill/uBlock/wiki/ ... k-requests

[GreenGeek]

Yes, "finely-tuned rulesets," that's the same as what I said above. But RP is easier.

[superA]

Those connections, are ''hidden'', because they took place if you just only allow first party staff to run.
They can't be blocked from RP either, be sure about this.

So, you either block everything with NoScript and whenever you allow first party domains, check them out in ublock/umatrix logger, or just ignore the whole thing, set a good blocker to catch as much as you can tolerate and stop babysitting every single site out there.

[GreenGeek]

Well, since the topic of the thread is what it is, RP is certainly relevant because that is what it does - arguably better than anything else. RP never was for blocking first party links, so that is not an issue unless there is a misunderstanding somewhere in the discussion. Blocksite Plus which I also mentioned fills that niche, for me in blacklist mode, although whitelist mode is an alternative. And it would be really awkward to use uMatrix or uBlockOrigin to block all first party links by default, so if that becomes the topic I will lose interest.

One of the things about uMatrix that bothers me is, in the grid, the ambiguity of both XHR and Other - what am I allowing when I allow those? Also in the rules, what do all the various matrix schemes really mean? I know there is documentation for explaining these (and I have read some of it) but don't bother posting more links for me of pages few users will ever read. Other tools like RP and Blocksite don't require reading additional documentation to use (for me at least).

It is not at all clear that behind the scenes connections are always first party, unless you simply define them as such. In fact, the terms lose their meaning without the context of a page attached. For these, I think authorized/permitted destinations/connections would be more appropriate terminology. I have some that are meant to be allowed at times but not other times, and that makes it really hard to explain as well as to block. It would get unwieldy to discuss specifics here, so I will simply say it can probably be done with uBO or uM rulesets if those are your chosen tools for that, but they aren't for me.

There's nothing wrong with people making their own decisions about what is appropriate security, including what happens behind the scenes, so your "babysitting" comment is just your own perspective and would better have been kept to yourself.

[superA]

GreenGeek,
I did not mean to offend you, I just talking in general, sorry for the inconvinience.
And yes, the babysitting comment was actually for me, I fed up with all this effort to watch,catch and understand those tracking staff, so I set things in my browser as tight as I can deal with and stoped bother..

One of the things about uMatrix that bothers me is, in the grid, the ambiguity of both XHR and Other - what am I allowing when I allow those?

That's the case in my point of view.
No matter how many filterlists you add, hosts, or blacklisting rulles, in some cases, too often by now, all the tracking happens if you allow XHR and other requests, even first party and certainly not from RP.

[Andrew Gilbertson]

It's true the original developer more or less quit. Then a couple of other guys started a "fork," Request Policy Continued." But that one is SDK, so it won't work in PM27 yet; but, it might after the next release. The original one still works in current PM.

Slightly off-topic, but: RequestPolicy Continued 1.0.beta12.4 has been working fine for me in all the 27.0.x versions of Pale Moon. (I'm not sure that non-beta versions will work with Pale Moon at all. But this beta version definitely does.)

[GreenGeek]

Yea, thanks, I tried again and it installed fine. It's restartless but not SDK. I know PM gave an error before (and that's why I dug up the old ver.), but not sure what it was.

Users do need to be careful to set the new one to block mode. And I personally disable subscriptions as well.

[HaleSun]

One of the things about uMatrix that bothers me is, in the grid, the ambiguity of both XHR and Other - what am I allowing when I allow those?

I don't understand how allowing XHR is any more ambiguous than allowing say, scripts. Blocking XHR means anything with an XMLHttpRequest() constructor is blocked, simple as that. XHRs allow the retrieval of basically any type of data to update a webpage without reloading the whole page, i.e. dynamic updating. A common example would be email updates showing up without you having to refresh the page every time. XHR was originally conceived with email in mind as it first appeared in Microsoft Exchange Server 2000, which also means it's quite old.

As for the "Other" category, this covers everything that is not explicitly defined elsewhere, which includes non-HTTP schemes like file:// and resource://. This also includes all the hidden "behind the scenes" connections whose origins cannot be traced back to a specific browser tab.

Also in the rules, what do all the various matrix schemes really mean?

To paraphrase gorhill, uMatrix needs a web page to have a proper hostname to work properly, so any scheme other than 'http' and 'https' is remapped into a "fake URL" which tricks the rest of uMatrix into being able to process an otherwise unmanageable scheme.

"Scheme" in this sense essentially means a made-up domain name. For instance, gorhill created a scheme to handle all behind the scenes requests and aptly named the scheme "behind-the-scene". It's really that simple.

Another concrete example would be when I was trying to solve an issue with Deviantart. When you press the "Download" button next to an image, a new window is supposed to open with the full-res image, however with uMatrix installed, the image was blocked, even when everything was set to "allow". Checking the log, uMatrix kept referencing "wyciwyg". As it turns out, "wyciwyg" is a Mozilla registered internal URI scheme to reference locally cached pages made by the browser. So basically Mozilla made up a scheme to sort cache references and called it "wyciwyg" (what you cache is what you get). By adding "matrix-off: wyciwyg-scheme true" to uMatrix's rules the download images function worked again.

It is not at all clear that behind the scenes connections are always first party, unless you simply define them as such. In fact, the terms lose their meaning without the context of a page attached. For these, I think authorized/permitted destinations/connections would be more appropriate terminology. I have some that are meant to be allowed at times but not other times, and that makes it really hard to explain as well as to block. It would get unwieldy to discuss specifics here, so I will simply say it can probably be done with uBO or uM rulesets if those are your chosen tools for that, but they aren't for me.

Yes, behind the scene connections have no determined origin so "first party" or not is irrelevant. You do have the option to block or allow only specific hostnames with dynamic filtering or use static filtering if you prefer. At the end of the day there are many ways to accomplish the same thing. Some find one way easier while others find another way more flexible, but the point is you have options.

[GreenGeek]

I'll try to respond coherently despite needing sleep.

XHR: I wasn't referring to needing a definition; that's easy enough to get, but doesn't help. I meant more in the context of what are the websites using it for. The devil, if there is one here, is in the details. We could say the same about JS but I'm less prone to worry about it now on sites where I want to allow it. Sometimes I look at the log before allowing XHR. I don't know of any bad result from allowing it but I am careful.

Other: "everything else" doesn't clarify it at all; again, it's the details that make it OK or not. I hate allowing this one, but that is somewhat less worrisome because I have other protection. it kind of seems like unlocking the back door and hoping no bad guys come in.

Matrix schemes: that helps a little - I do remember the download issue (I posted a github issue message or something but too long ago to remember details). I'm not sure I would have taken his general approach though.

This could all be handled a lot easier if the websites were cooperative and trustworthy. But they try to force ads and tracking on us every way they can.

[HaleSun]

I suppose it would be too messy to expand the "Other" category and itemize everything it covers in another submenu, but point taken, there's a lot stuffed into one category, but it's mostly things that don't directly relate to general web browsing.

The simpler approach would be to deny-by-default. If you were to block all XHR, and nothing (important) breaks, then there's no harm in doing so.
The cases where you'd be missing features but remain unaware of it will be very rare.