Policy: Use of URL shortening tools in entries [disallowed]

All suggestions about TPFC should be posted here. Discussions about changes to TPFC will also be carried out here.
Post Reply
Message
Author
User avatar
webfork
Posts: 7756
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Policy: Use of URL shortening tools in entries [disallowed]

#1 Post by webfork » Fri Oct 14, 2016 2:43 pm

To avoid a thread hijack, I created a new one on this topic.
smaragdus wrote:... usage of URL shortening services in the database entries should be disallowed
(source)

I think that's wise for a few reasons:
  • URL shortening services come and go and I'm already spending a LOT of my time on PFW updating links
  • A shortened URL could be modified to point to a different location than it's intended destination
  • It's an additional delay when someone clicks on a link
Can anyone think of a benefit?
Supporting Net Neutrality - BattleForTheNet | Why this matters | More from EFF.org

Specular
Posts: 280
Joined: Sun Feb 16, 2014 10:54 pm

Re: Use of URL shortening tools in entries

#2 Post by Specular » Fri Oct 14, 2016 4:16 pm

webfork wrote:Can anyone think of a benefit?
In the case of a PF entry, not really. Bit.ly for example allows creators to track analytics but that's only really of benefit to the creator.

I suppose with the appropriate service one could create a download link that is always a single URL and simply update what it links to, as a sort of middle man for download URLs that change depending on version, but the problem with that is browsers cache all redirects that these services use (there is a non-caching redirect available but no service I've found use it). It also shares the vulnerability of the service going down, or potential abuse.

Archive Team have a wiki entry of the hundreds of dead and alive link shortening sites they try/are trying to archive. The problem with shorteners is they obscure the original link, so if anything happens to the service it's not always clear where one would find an archived copy (which happens a fair bit on PF when program sites 404).

billon
Posts: 560
Joined: Sat Jun 23, 2012 4:28 pm

Re: Use of URL shortening tools in entries

#3 Post by billon » Fri Oct 14, 2016 4:36 pm

no benefits
we shouldn't use any url shorteners
it will break database transparency
why the hell this question appears in the first place

User avatar
joby_toss
Posts: 2902
Joined: Sat Feb 09, 2008 9:57 am
Location: Romania
Contact:

Re: Use of URL shortening tools in entries

#4 Post by joby_toss » Fri Oct 14, 2016 10:08 pm

billon wrote:why the hell this [...] appears in the first place
This!

User avatar
I am Baas
Posts: 4144
Joined: Thu Aug 07, 2008 4:51 am

Re: Use of URL shortening tools in entries

#5 Post by I am Baas » Fri Oct 14, 2016 11:23 pm

billon wrote:why the hell this question appears in the first place
Boom.

+1

Should be disallowed in the forums too.
Bəəs 2.0

User avatar
webfork
Posts: 7756
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Re: Use of URL shortening tools in entries

#6 Post by webfork » Sat Oct 15, 2016 9:57 am

I've updated the thread title to reflect the status of this topic as settled. If it comes up in the future, I'll just point folks here.
Supporting Net Neutrality - BattleForTheNet | Why this matters | More from EFF.org

xor
Posts: 105
Joined: Sat Apr 18, 2015 11:02 pm

Re: Policy: Use of URL shortening tools in entries [disallow

#7 Post by xor » Sat Oct 15, 2016 11:08 am

oh yeah! Short URLs would be cool! ...... :roll: :arrow: ....... NOT !!!!!

User avatar
Midas
Posts: 4195
Joined: Mon Dec 07, 2009 7:09 am
Location: Sol3

Re: Policy: Use of URL shortening tools in entries [disallow

#8 Post by Midas » Sat Oct 15, 2016 12:23 pm

FTR, shortening services do come handy in day-to-day use -- e.g., it's easier to transmit a Goo.gl 12 character string over the phone than a long convoluted URL that might not even work afterwards because of some minor error like a comma or a plus sign...

Having said that, I fully agree they have no place whatsoever in TPFC's database -- from where I stand I can see a clear attribution angle, on top of warding off the so called "bit rot" we have all witnessed here more than once.

Post Reply