Hyperlinks Do Not Work

[sake-bottle]

Greetings,
URLs in torrent descriptions or comments don't work as expected; e.g. clickable hyperlinks that can be opened.
See Team.png, Alice in wonderland librivox, or tttml for context.
Cheers.

[josecelano]

Hi @sake-bottle, that's a feature we implemented to increase user privacy. We remove all external links from torrent descriptions. See https://github.com/torrust/torrust-index-gui/blob/develop/src/domain/services/sanitizer.ts#L20-L31

The torrent uploader can insert a URL (e.g. https://yourserver.com/resource) to track the user's IP.

If you want to enable it, maybe we should include a new configuration option.

[sake-bottle]

Hi @sake-bottle, that's a feature we implemented to increase user privacy. We remove all external links from torrent descriptions. See https://github.com/torrust/torrust-index-gui/blob/develop/src/domain/services/sanitizer.ts#L20-L31

The torrent uploader can insert a URL (e.g. https://yourserver.com/resource) to track the user's IP.

If you want to enable it, maybe we should include a new configuration option.

While the reasoning is valid, the result removes an essential part of how users interact with the web. Not allowing their use assumes the tracker's main use-case to only be a free-for-all where any uploading user is presumed to possibly have malicious intents; id est, logical, but cannot be considered representative.
You are correct, it should be included as an option and to the discretion of the admin.

[josecelano]

Hi @sake-bottle, that's a feature we implemented to increase user privacy. We remove all external links from torrent descriptions. See https://github.com/torrust/torrust-index-gui/blob/develop/src/domain/services/sanitizer.ts#L20-L31
The torrent uploader can insert a URL (e.g. https://yourserver.com/resource) to track the user's IP.
If you want to enable it, maybe we should include a new configuration option.

While the reasoning is valid, the result removes an essential part of how users interact with the web. Not allowing their use assumes the tracker's main use-case to only be a free-for-all where any uploading user is presumed to possibly have malicious intents; id est, logical, but cannot be considered representative. You are correct, it should be included as an option and to the discretion of the admin.

On second thought, I think this should be maybe a user setting so each user can enable/disable it. What do you think? We can also combine both:

• The admin can disable all links for all users.
• If external links are not disabled, users can disable them in their settings. This would work only if they are logged in or if we also allow to disable them for guest users (with a session setting).

[sake-bottle]

On second thought, I think this should be maybe a user setting so each user can enable/disable it. What do you think? We can also combine both:

* The admin can disable all links for all users.

* If external links are not disabled, users can disable them in their settings. This would work only if they are logged in or if we also allow to disable them for guest users (with a session setting).

A per-user setting seems redundant; if you don't want to risk clicking on a potentially harmful link, you won't open it in the first place. What if you decide you want to click a specific one, do you have to go disable it in settings? It also introduces the potential feature request where you would want to whitelist specific users for your account view; it's messy.
At that point, I'd review implementing a global config option and torrust/torrust-index#211 where different user classes exist which can be admin-chosen and marked trusted to remove the hyperlink block.

[josecelano]

On second thought, I think this should be maybe a user setting so each user can enable/disable it. What do you think? We can also combine both:

* The admin can disable all links for all users.

* If external links are not disabled, users can disable them in their settings. This would work only if they are logged in or if we also allow to disable them for guest users (with a session setting).

A per-user setting seems redundant; if you don't want to risk clicking on a potentially harmful link, you won't open it in the first place.

Links could also be the src in a image, so you don't have to click to load it. The browser does it automatically, and it could also be prefetched even before you see it.

What if you decide you want to click a specific one, do you have to go disable it in settings?

You can just copy/paste the link. Most browsers allow you to select the link and open it in a new tab (right mouse button).

It also introduces the potential feature request where you would want to whitelist specific users for your account view; it's messy. At that point, I'd review implementing a global config option and torrust/torrust-index#211 where different user classes exist which can be admin-chosen and marked trusted to remove the hyperlink block.

I was thinking more like a switch on/off component next to the description, but yes, I think it's a little bit messy. It's probably better to allow the admin to define the policy. When links are enabled, users can use other methods to avoid being tracked.