Pure URL for Palemoon

[moonbat]

Dotted underline is a bit too unseen to my taste

The idea is to be as unobstrusive as possible, in fact I specifically did not want CleanLinks style highlighting. This is also why you can completely disable the UI (remove the toolbar button and option to hide from tools menu) and it will still do its job in the background.

Console errors are internal errors with Javascript that are beyond its scope to handle, don't worry about them.

I would like the "shared" part stripped out

Then create a new garbage field entry and add it to the list. The options to do so exist for exactly this reason
You can't expect me to know about every single filter for every single website that exists regardless of how often they're visited. The default list covers the most popular ones, it isn't meant to be exhaustive.

[wickedsp1d3r]

Then create a new garbage field entry and add it to the list. The options to do so exist for exactly this reason :roll:
You can't expect me to know about every single filter for every single website that exists regardless of how often they're visited. The default list covers the most popular ones, it isn't meant to be exhaustive.

Of course.
I asked this because this kind of a link is kinda different. The "shared" part is encoded within the URL and the parameter's value is missing. It is actually a path parameter. It appears in DOM like this:

Code: Select all

<a href="https://example.com/one/two/?shared%3D348950-3a5dafb0-1" target="_blank" class="my-class" rel="noopener">Foobar</a>

My garbage fields contain "shared@example.com", but it has no effect.

[WouterK]

When I run Pure URL 3.3 in Pale Moon 29.4.1 (using a new profile without any other extensions), in both Linux and Windows I encounter the following inconsistent behavior:

When I check/uncheck the "Expand shortened links" and "Intercept requests" checkboxes in the "Pure URL Options" dialog box and press OK, the corresponding menu items in the Pure URL toolbar button menu are automatically updated accordingly.
And when I switch these menu items from checked to unchecked, the checkboxes in the dialog box are updated accordingly.
So far so good.

However, when I switch the "Expand shortened links" or "Intercept requests" item in the menu from unchecked to checked, the menu item itself (correctly) receives a checkmark, but nothing else happens:

• The underlying preference ("palemoon.expandlinks" / "palemoon.request_hook_enabled") remains false.
• The corresponding checkbox in the "Pure URL Options" dialog box remains unchecked.
• Pure URL doesn't apply the corresponding operation to any links.
• Upon a restart of the browser, the menu item reverts to unchecked.

So there seems to be something wrong here.

By the way, the "On" item in the "Fix links on pages" submenu works correctly both ways.

[moonbat]

Options dialog preferences are only updated when you click OK. If you are using the toolbar button's submenu, then the changes you make are instantaneous.

[WouterK]

Options dialog preferences are only updated when you click OK. If you are using the toolbar button's submenu, then the changes you make are instantaneous.

Yes, that's my understanding of how things should work too.
But (as described in my previous post) switching the "Expand shortened links" or "Intercept requests" item in the toolbar button menu from unchecked to checked doesn't achieve anything (apart from adding the checkmark to the menu item itself).
So I think there's something wrong with the event handlers of these two menu items.

[moonbat]

Works fine here. The two about:config preferences are expandlinks and request_hooks_enabled and both toggle correctly along with the toolbar button preference.
Edit - what I've seen is the toolbar button color and the tooltip status sometimes are inconsistent with the current state.

[WouterK]

I've found and fixed the bug:

In Pure URL 3.3's init.js, toggleInterceptChk and toggleExpandLinks assign event.target.checked to request_hook_enabled and expandlinks:

Code: Select all

		toggleInterceptChk : function(event){
			var selected = event.target.checked;
			puPrefBranch.setBoolPref("request_hook_enabled",selected);
		},

Code: Select all

		toggleExpandLinks : function(event){
			var selected = event.target.checked;
			puPrefBranch.setBoolPref("expandlinks",selected);
		},

But in both cases event.target.checked always has the value of 'undefined'.
Consequently toggleInterceptChk and toggleExpandLinks always set request_hook_enabled and expandlinks to false.
This explains the behavior I described in my previous posts.

The fix is the approach already used by toggleFixLinks:

Code: Select all

		toggleInterceptChk : function(event){
			puPrefBranch.setBoolPref("request_hook_enabled",PureURL.Launch.btnchkIntercept.hasAttribute("checked"));
		},

Code: Select all

		toggleExpandLinks : function(event){
			puPrefBranch.setBoolPref("expandlinks",PureURL.Launch.btnchkExpandLinks.hasAttribute("checked"));
		},

Then these menu items work correctly.

[moonbat]

Thanks, I'll get round to publishing a fix

[Drugwash]

I see you have a few URL shorteners listed as included with this extension. Have you checked with the old DeTiny Short Url extension that apparently claims it is not limited to specific services?

Expand any shortened (redirecting) URL - not limited to specific services

Maybe you could improve your code to expand any shortened URLs not only a specific subset.
Also Redirect Cleaner 2.2.0 by Alexander Bergmann may be of some use in case there are problems with URL redirectors.

[moonbat]

Haven't heard of these, I'll take a look.
DeTiny relies on the defunct toolhaus.org to do its business, hardly an example of a reliable extension. This is an example of a 'service' extension that has an unnecessary dependency (for this purpose) on an external website and is thus broken for good once the site in question goes down, as the notice on the main page for the site says. The extension page doesn't offer any licensing information either as I now notice - so anyway forking or modifying it becomes verboten as a result because absence of a license implies all rights reserved by the author.
Also, Pure URL's main purpose is stripping junk URL parameters; the URL expansion works for sites that can be queried for the full URL in the background without much complication so it doesn't delay page loads. If you find any newer URL shorteners, I'll see if they can be integrated the same way.

[Drugwash]

absence of a license implies all rights reserved by the author.

In the manually modded package of DeTiny Url that I have installed in my Pale Moon there is a LICENSE.txt file (317 bytes dated March 2, 2010) that states:

This work is licensed under the
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States
License.
To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-sa/3.0/us/ or send a letter to
Creative Commons
171 Second Street, Suite 300
San Francisco, California, 94105, USA

So I guess it could be used somehow. The extension also provides an e-mail address in its details (visible in the RDF file too) that one could try for obtaining any useful details provided the author still responds to that address.
The main purpose of the site was different, it had to do with something related to eBay. There probably still is some underlaying code on that site that still works with the DeTiny Url extension though. Maybe you shouldn't give up so easily.

[moonbat]

What's the point in working on an extension that depends on a site not under your control to do its job? The site is already defunct per the main page anyhow. And expanding short links is hardly something that needs to be server side. That's after the privacy implications of an extension sending every short link you encounter to a third party

[Moonchild]

That's after the privacy implications of an extension sending every short link you encounter to a third party

Maybe I misunderstand something here but isn't this always the case? I mean a URL shortener will have a server-side database which short URLs map to which expanded ones... and that information can't be magically reproduced out of thin air without sending the URL to the shortening service (a third party)...

[Drugwash]

We're talking here about the reverse situation where a shortened URL has to be unshortened. However, the extension in question sends the short URL to its author's server where it gets "decoded" and then sent back to the extension for the output. That's the issue of the third party that moonbat is talking about.
The fact that the decoding has to go through the shortening service is yet another third-party, one that could be called "the original".

My idea was that the code on the Toolhaus site that performs the actual decoding could be provided (or licensed or whatever) to moonbat's extension so it could be used locally. I didn't ask or imply that the same Toolhaus server should still be used. Maybe it wasn't clear enough on my part.

Now, as a side discussion, I'd rather have a random individual maybe gather my URL decoding activity (and possibly not use it at all) than a large service that most likely gathers and uses that data for unknown purposes. And the upside is that the shortening service will never know it was me to send that URL, since the request always comes from the author's server.

[moonbat]

My idea was that the code on the Toolhaus site that performs the actual decoding could be provided

I'm guessing he just maps the relevant code path for each URL shortener and calls it accordingly. The extension isn't rocket science, it just sends a background request, extracts the expanded URL from the response and modifies the link on the webpage using the DOM. This approach doesn't work for all services, hence I had to test them individually. At any rate the most popular ones are well supported.

[Moonchild]

However, the extension in question sends the short URL to its author's server

Oh, I see... So it'd be a "4th party" request then. Yeah I don't really see why an extension can't just call the URL shortening service directly that's needed anyway instead of centralizing this with the risk of tracking every URL through the extension author's server.

[Drugwash]

I'm guessing he just maps the relevant code path for each URL shortener and calls it accordingly. [...] This approach doesn't work for all services [...]

Could be, or could be more - no idea, haven't loked at the site code. Maybe it does do more than the simple things. That's why I mentioned it: to be checked, and if useful forked the relevant code.

I don't really see why an extension can't just call the URL shortening service directly [...]

Don't know author's intentions but it may be as mentioned above: an attempt at anonymizing the requests by always having the site as the requester, thus protecting users' privacy to some degree. Of course the issue becomes how trustworthy is the author and whether the code tracks/logs all requests or not, but at least direct calls to the service guarantees their tracking. Anyway, this is now just an academic issue.

Well, my role here is done, said what had to say, got no dog in this fight so whatever results of this is alright with me.
Enjoy the week-end gentlemen!

[moonbat]

Of course the issue becomes how trustworthy is the author and whether the code tracks/logs all requests or not

That is definitely a privacy concern, but beyond that is the worrying trend these days of pushing everything to the server side that doesn't need to, in some cases so that they can charge a subscription (a popular trend in the Android world - I've seen apps that run 100% locally on your phone with no dependency on a server infrastructure still use a subscription service). In this case, I forked the original Pure URL for Firefox because it has a ghastly (actually non existent) UI, partly due to being a Jetpack 'restartless' extension. So I've converted it back to a regular overlay extension and the options dialog, toolbar button and link expansion are all features I added. In Web Extensions land, an equivalent extension would not let you customize the garbage fields list with your own additions and/or probably rely on the extension developer issuing updates (by updating the extension each time the list has to be changed rather than downloading updates from their server).

[Moonchild]

an attempt at anonymizing the requests by always having the site as the requester, thus protecting users' privacy to some degree.

Just for the record, while you can effectively gather statistics of requests by using a shortening service, it's very difficult if not impossible to track anyone through it. Tracking requires unique identifiers; a short URL by design doesn't have any unless it's unique to each visitor, which is not the way shortening services work. Of course you can play devil's advocate and complain that it's technically possible for the shortener to gather some minimal data on the visit (like IP/geo and other public information a browser sends with requests), but that would still happen in that case if the request was "funnelled" through an extension author's server. With the added risk of course that the shortening service can easily blacklist the extension server for being abusive, effectively killing its function.
I personally think the risk of sending all your unshortening requests through one unnecessary step has a much higher risk of being compromised than having a client-side request being done to the shortening service; a request that would happen anyway if you want to know the original URL before going there. After all, you'd be sending all short URLs to one location, centralizing it more and being able to correlate your requests across multiple unrelated sites using different shortening services. So from a privacy point of view, IMHO you certainly lose more than you gain.

Sorry for going on at length here. I know you're done with this thread, I just felt it'd be at least somewhat informative to add my opinion coming from a tech perspective.

[andyprough]

Just a note - the outlook.com webmail site uses about an extra 700mb of memory and much more cpu and ocassionally locks up palemoon for me when using Pure URL with 'Expand shortened links' checked. Toggling off 'Expand shortened links' allows palemoon to handle outlook.com normally with far fewer resources and no lockups. I'm assuming this is the case because outlook.com must use some Microsoft link shortener on nearly everything, just like it adds utm trackers to nearly every link.

I prefer to continue using Pure URL with 'Expand shortened links' toggled on for all other websites. Is there any way to only toggle it off for this one website, and allow it to work on the others where it doesn't result in high memory and cpu usage?