Pale Moon forum

Posted: **2022-07-18, 12:40**

andyprough wrote: ↑
2022-07-18, 12:37
According to the Ghacks article which Slashdot points to, it was not Firefox or Brave that screwed you, but Facebook itself by encrypting its url tracking parameters

Off-topic:
And which browsers blocking Facebook's tracking ID with built-in functionality would you say hastened this change from Facebook?

Posted: **2022-07-18, 13:28**

Off-topic:

andyprough wrote: ↑
2022-07-18, 12:37
it was not Firefox or Brave that screwed you, but Facebook itself by encrypting its url tracking parameters

This was in direct response to at least one mainstream browser manipulating/stripping the parameters out-of-the-box. Why else would Facebook invest in an elaborate URL-encrypting scheme?

Posted: **2022-07-18, 13:51**

Off-topic:

Moonchild wrote: ↑
2022-07-18, 13:28

Off-topic:
andyprough wrote: ↑
2022-07-18, 12:37
it was not Firefox or Brave that screwed you, but Facebook itself by encrypting its url tracking parameters
This was in direct response to at least one mainstream browser manipulating/stripping the parameters out-of-the-box. Why else would Facebook invest in an elaborate URL-encrypting scheme?

They are "privacy" browsers, their business models requires cranking out "privacy tool" press releases. Referral trackers is low-hanging fruit, of course they are going to strip it. They are just following their business models, can't be helped.

At the same time, your point is valid, Facebook is an ad revenue company, they must track users to make money, can't be helped. Of course they are going to respond to the stripping of referral trackers with something like encrypted trackers. So it's an arms race, and the poor Facebook users are caught in the middle. In the end, the web is simply not a friendly place, and it's probably going to get a lot less friendly.

Posted: **2022-07-19, 01:19**

Redirect Bypasser from CAA can decrypt Base64 encoded URL parameters, so worth trying with FB URLs.

Posted: **2022-07-19, 02:28**

Doesn't look like valid base64 to me. And I doubt Facebook would do something that simple.

Posted: **2022-07-24, 04:34**

I've been finding some odysee.com videos that won't play unless I turn off the "Expand shortened links" option in Pure URL, such as this one today: https://odysee.com/@AlexanderMercouris: ... retreats:c

I don't think they are so much shortened links, as they are weirdly put together links. I have other programs, such as RSS feed readers and streaming video players, that have problems with similar odysee links.

I looked for errors in the error console, but did not see any. This is not happening with all odysee videos, just some of them. My solution for now is to disable the 'Expand shortened links' option when trying to play these particular videos, which is fine.

Posted: **2022-07-25, 08:05**

Use the extension's logging ability to see what it modified on the page, if any.

Posted: **2022-07-25, 12:43**

moonbat wrote: ↑
2022-07-25, 08:05
Use the extension's logging ability to see what it modified on the page, if any.

OK I did get an error while attempting to play the following video with 'Expand shortened links' enabled in Pure URL: https://odysee.com/@AlexanderMercouris: ... ffensive:2

Timestamp: 07/25/2022 07:39:39 AM
Error: SyntaxError: expected expression, got '<'
Source File: https://odysee.com/public/ui-f1503317-8 ... 77ea72b.js
Line: 1
Source Code:
<!DOCTYPE html>

As I said, I assume that odysee simply mis-forms its own links sometimes. Maybe Pure URL views it as some type of a mis-formed email address or something?

Posted: **2022-07-25, 14:08**

andyprough wrote: ↑
2022-07-25, 12:43
I assume that odysee simply mis-forms its own links sometimes.

if it tosses back an HTML page when it should serve you a script, then it's most likely that too much was stripped from the URL

Posted: **2022-07-26, 03:03**

andyprough wrote: ↑
2022-07-25, 12:43
OK I did get an error while attempting to play the following video

I mean see what PureURL does to the page. Whatever it does gets prefixed with PureURL: so you can search the console log and see.
Clear the log, enable logging in Pure URL and then refresh the page in question, you will see what PureURL has caught, if any. If one of the parameters it removed was actually essential, you can remove it from the list of garbage parameters.

Posted: **2022-07-26, 03:50**

moonbat wrote: ↑
2022-07-26, 03:03
I mean see what PureURL does to the page. Whatever it does gets prefixed with PureURL: so you can search the console log and see.
Clear the log, enable logging in Pure URL and then refresh the page in question, you will see what PureURL has caught, if any. If one of the parameters it removed was actually essential, you can remove it from the list of garbage parameters.

It's just some bit.ly links that look like they are expanded properly by Pure URL. Also today the video is playing with the expanded links, and now I'm trying to find one that won't play but not having any luck.

Code: Select all

[PureURL:]Resolved https://bit.ly/3hg1B3R to https://superu.net/channel/055dc88f-aec7-475a-a7ad-1ad271b0282d/
[PureURL:]Resolved https://superu.net/channel/055dc88f-aec7-475a-a7ad-1ad271b0282d/ to https://www.superu.net/channel/055dc88f-aec7-475a-a7ad-1ad271b0282d/
[PureURL:]Original link: https://bit.ly/3hg1B3R
Expanded link: https://www.superu.net/channel/055dc88f-aec7-475a-a7ad-1ad271b0282d/
[PureURL:]Resolved https://bit.ly/354ASQ9 to https://soundcloud.com/user-901836666
[PureURL:]Original link: https://bit.ly/354ASQ9
Expanded link: https://soundcloud.com/user-901836666

I still think it was just odysee doing something odd, which seems typical for them.

Posted: **2022-07-31, 23:31**

andyprough wrote: ↑
2022-07-26, 03:50
I still think it was just odysee doing something odd, which seems typical for them.

That's probably what it is.

Posted: **2023-04-12, 08:01**

Changelog for 3.3.4:

Restore Basilisk support
Raise compatible major version to 32.* in install.rdf (makes no difference, you still could install it before when it said 28.* since it doesn't specify strict compatibility)

Posted: **2023-09-22, 11:00**

1. I guess the extension ignores first param introduced via ? character and filters only subsequent params introduced via & character. This would be a bug.
I propose to enhance lines 118 and 127 in common.jsm - insert |\? additionally before |&, line 254 insert \?| before &]. Not sure how to fix line 287, probably no fix here necessary, however, it seems to me, the proper command to replace potentially multiple &&&... via single & should be:
var cleaned = args.replace(regexp, '').replace(/^[&]+/i, '&');
the intention is to replace '&&&' with & not to strip & totally, but I could probably miss the point of the code.

2. the Facebook uses tracking param __cft[0]__ with arrray brackets and index in it. Could backslashing brackets work for PureURL option setting: __cft\[0\]__ ?
the param name identification is programmed as anything except & and #, that means brackets should be taken as they are during param name parsing, but not sure...

Posted: **2023-09-22, 12:34**

pm-ext wrote: ↑
2023-09-22, 11:00
1. I guess the extension ignores first param introduced via ? character and filters only subsequent params introduced via & character.

Any example URL? Remember that you can always add your own fields to be filtered unlike similar extensions for other browsers, and that enabling logging, clearing the browser console and reloading the page will show you exactly what URLs were processed.

Posted: **2023-09-22, 15:26**

https://www.facebook.com/groups/235648462818/posts/10160687820852819/?comment_id=10160688181337819&__cft__[0]=AZWLxjjS7s1y-g_yeslt59x3w
I removed some not meaningful letters from last param to get this test URL. The param name is __cft_[0] - you can see.
The question is
1. how to configure PureURL to strip this param and
2. what if that param would come immediately after ?, f.e. https://www.facebook.com/groups/235648462818/posts/10160687820852819/?__cft__[0]=AZWLxjjS7s1y-g_yeslt59x3w

Posted: **2023-09-22, 22:43**

Ok, looks like the original parser didn't take these arrays into account; my fork hasn't touched that part of the code. The position of the parameter shouldn't matter, as you said earlier it's probably due to not parsing the array brackets properly.

Posted: **2023-09-23, 08:33**

I am not sure if the brackets are valid in HTTP standard. I does not make sense to me, HTTP params are never arrays. It is possible, that this is tactics of FB against link strippers, it makes sense because all parsers programmed on standard will fail on such construct.

Posted: **2023-09-23, 10:56**

pm-ext wrote: ↑
2023-09-23, 08:33
I am not sure if the brackets are valid in HTTP standard.

They aren't, unless they are %-encoded. See RFC 3986 Appendix A
(I'll break it down for your convenience):

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

query = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

So query = a string of pchars and / or ? delimiters, where pchar boils down to alphanumeric characters, digits, and :@-._~!$&'()*+,;=
and anything else should be %-encoded. including [ and ]

Posted: **2023-09-24, 01:03**

Trust Facebook and other big tech to do something non standard. Or revise the standard every few days making it meaningless in Google's case

Pale Moon forum

Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon

Re: Pure URL for Palemoon