Esteemed List Members--
Thanks to all who responded to my URL shortener poll some months back.
Apologies for my glacially paced follow-up for those who expressed interest.
I think it’s a fascinating phenomenon where security, UX, and cool
convenience all meet. What could be more fun than that?
First, I wanted to respond to Rich Kulawiec’s concerns, shared earlier in
this thread. Although I heartily support the shortener concept and am far
from impartial, I think even the gruffest of IT security folks out there
must have to come to grips with the “they’re gonna do it anyway”
realization, which then becomes a matter of managing what’s going on. Bit.ly
and tiny.url instances abound in .edu land I’m sure (with institutional
variations; for example, tiny.utk.edu). The Realpolitik solution would
seem to me: if you can’t beat ’em, join ’em in a way that works for the
best, safest solution. To me (and to Rich’s point #4), *institutional*
shorteners are a way of lending some small measure of gravitas to shortened
links because someone must log in to use the service on a system *governed
by a usage policy* from their institution at some level, increasing trust
for most people at the link-clicker’s end, I would think.
With your help, I collected data
<https://docs.google.com/spreadsheets/d/1FrDdn0mptFJoCMy4LNzWUhQ7MCo4cWomdxgP34zSO9A/edit?usp=sharing>
from 32 institutions, 30 of which do have institutionally available URL
shortener services. Very handily for marketing, several also pair the
service with QR code creation, which also syncs with the “governed by a
usage policy” point.
For the linguists among us, syntactically it seems that “go.[*].edu” is an
emerging standard (go.gmu.edu, go.hawaii.edu, go.iastate.edu,
go.illinois.edu, go.niu.edu, go.rutgers.edu, go.uky.edu, go.umd.edu,
go.unl.edu, go.uvm.edu, go.vcu.edu, go.wisc.edu), with single letter
prefixes also sustaining their early popularity (s.uconn.edu, u.tamu.edu,
z.umn.edu), while a few others entirely forsake the .edu turf for other
concise domains (aub.ie, buff.link, duke.is, col.st, myumi.ch, umresear.ch,
vanderbi.lt). Then there are Austinaciously extravagant smorgasbords
<https://ut.service-now.com/sp?id=kb_article&number=KB0011746>…
I hope you enjoyed my quick look at URL Shorteners. Thanks again for
helping me understand the practice,
--DBL
David B. Lowe
Research Data Management Librarian
LSU Libraries
On Mon, Mar 17, 2025 at 11:04 AM David Lowe <
[log in to unmask]> wrote:
> Thanks, Rich! A very nice explication of some very valid concerns. Happy
> to hear from more infosec folks.
>
> Meanwhile, I'd love more responses in the poll, especially if your
> institution hosts a URL shortener service:
>
> https://docs.google.com/forms/d/e/1FAIpQLScCtqbpq97ffNdiq6so6QmIgnT2Yl0cyeV-FLy4OZS0yv8GGw/viewform?usp=dialog
>
>
> Will summarize to this list some time next week.
>
> Peace,
> --DBL
>
> On Sat, Mar 15, 2025 at 10:09 AM Rich Kulawiec <[log in to unmask]> wrote:
>
>> Speaking from one infosec perspective: URL shorteners are a worst
>> practice in
>> computing. Here's why (briefly) (very briefly) with some references
>> below:
>>
>> 1. Any functional piece of software should be able to handle fairly
>> long URLs -- roughly: 2000 characters, which most contemporary browsers
>> can handle. (RFC 3986 doesn't specify a maximum length for URLs,
>> but does set the domain part's maximum length at 255 in section 3.3.2.)
>>
>> 2. General URL shorteners (such as those operated by various operations)
>> facilitate surveillance and are subject to manipulation. (Or they may
>> *be* surveillance/manipulation, i.e., they may not be what they claim.)
>> They're also impermanent: when they go away, all the links using them
>> stop working -- or worse, the domain may be re-registered by a malicious
>> actor so that all the links keep working, just not for their originally
>> intended purposes. They're also single-points-of-failure, which make
>> them excellent targets for various kinds of attacks -- and not just
>> technical ones, see one of the links below.
>>
>> 3. Specific URL shorteners (such as those operated by a company or
>> university) represent a single point of failure. In other words,
>> if a university with 8 schools and 62 departments decides to use a
>> single URL shortener for the institution instead of publishing full URLs
>> (which presumably would use subdomains for those schools and departments)
>> then what the university has built isn't a resource: it's a target
>> whose compromise allows an attacker to go after all 8 schools/62
>> departments
>> simultaneously.
>>
>> 4. URL shorteners discourage users from scrutinizing links before
>> following them. Some users, of course, don't do this anyway; but careful
>> users stare at and evaluate URLs before using them. Shortened links are
>> inscrutable and discourage this useful/judicious habit -- in other words,
>> they help train users to be victims. Note that this problem has been
>> exacerbated in recent years by the proliferation of ~1000 new TLDs
>> and by the accelerating trend of very bad UI designs that obfuscate URLs,
>> domains, and email addresses -- so there's plenty of blame to go around.
>> ;)
>>
>> 5. I recommend permanently banning all general URL shorteners the moment
>> you're aware of their existence. Depending on context/application, this
>> could mean things like using DNS RPZ to keep them from resolving, blocking
>> them in HTTP proxies, etc. I recommend not building a specific URL
>> shortener and instead making judicious choices in hostnames, subdomains,
>> and URL RHS strings [1] -- because doing so obviates the need for a URL
>> shortener. And finally, I recommend training users -- as much
>> as possible, and that may not be much -- to never use URL shorteners.
>>
>> Some references/supplemental material (by no means complete):
>>
>> This URL shortener situation is officially out of control - Scott
>> Hanselman
>>
>> http://www.hanselman.com/blog/ThisURLShortenerSituationIsOfficiallyOutOfControl.aspx
>>
>> Why I Don't Like URL Shorteners | Altmode
>>
>> https://altmode.wordpress.com/2013/10/07/why-i-dont-like-url-shorteners/
>>
>> on url shorteners -- joshua schachter's blog
>> http://joshua.schachter.org/2009/04/on-url-shorteners
>>
>> Libya Seizes URL Shortener Vb.ly | PCMag
>>
>> https://www.pcmag.com/archive/libya-seizes-url-shortener-vbly-255360
>>
>> URL Shorteners: Convenient But a Potential Security Risk | News
>> & Opinion | PCMag.com
>>
>> https://www.pcmag.com/news/343781/url-shorteners-convenient-but-a-potential-security-risk
>>
>> Massive cybercrime URL shortening service uncovered via DNS data
>>
>> https://www.bleepingcomputer.com/news/security/massive-cybercrime-url-shortening-service-uncovered-via-dns-data/
>>
>> Google URL Shortener Links Will Return a 404 Response - Slashdot
>>
>> https://news.slashdot.org/story/24/07/18/216211/google-url-shortener-links-will-return-a-404-response
>>
>> ---rsk
>>
>> [1] For instance: "projects.geology.example.edu/glacial-rebound" might be
>> a project studying glacial rebound in the geology department of Example
>> University, while "projects.geology.example.edu/pacific-rim" might be
>> a different project studying volcanic activity on the Pacific Rim.
>> These aren't particularly long URLs, they're communicative, they're
>> somewhat memorizable, and they use hostnames, subdomains, and RHS URLs
>> to maximize the information conveyed per character.
>>
>
|
