Ah yes, I remember when Tinyurl first came into play - people were extremely hesitant to click anything behind one because so often it was a goatse.
How does link shortening do that?
Though I agree it's not ideal.
Also -- anyone who views a copy/pasted version of this content won't get this protection.
It's not more secure, but it's not less secure and it doesn't break the web. It also shouldn't add an appreciable amount of complexity, given that most of the heavy lifting to sanitize, parse, and format UGC content already happens on the server. E.g. if you're already turning UGC snippets into an AST on the server so that you can cleanly syndicate them in different formats, having the AST generate some js around URLs isn't a big lift.
I still don’t understand why you think url shorteners break the web.
How do you know where the links resolve to once FB goes out of business?
Given the fact that there are still lots of people whose entire job is translating 6,000-year-old grocery receipts from Sumeria, it's not at all unlikely that tweets being written today will be still be widely studied and considered important 10,000 years from now. But those short links are unlikely to resolve for even the next 20 years.
Also, adding js should no longer add more attack surface now that we have things like subresource integrity in addition to CSPs.
(although evidence of this happening in practice hasn't crossed my radar, but it's probably because I just don't click those links in the first place)
Also note that a ".info" suffix might sometimes be easier to type. [1][2]
Too bad most URL shorteners don't support them. :(
[0]: http://goo.gl/vulnz+
https://developers.googleblog.com/2018/03/transitioning-goog...
from a Don Norman design-of-everyday-things perspective the design is completely non-discoverable https://en.wikipedia.org/wiki/Affordance#As_perceived_action...
Shortened links become trackable by a third-party (less secure), obfuscate the real URL (less secure), and can be brute forced easier: https://www.schneier.com/blog/archives/2016/04/security_risk...