I'm kind of happy about that now.
I'm kind of happy about that now.
For companies, marketers, etc, bitly, and other url shortners provide data and analytics ontop of the links, allowing more insight into link shares & clicks.
When you're interested in tracking the data from a link, or series of links, having a persistent account is necessary.
My guess is that logins probably help bitly track usage patterns, improve the product, and keep an eye out for ways to increase their value by measuring engagement with their userbase. Maybe it was just "everyone's adding a social layer" peer pressure. Not sure.
There are security costs to "use passwords everywhere, for everything," but they are more diffuse. We've ended up with a system where security best practices would recommend using hundreds of distinct passwords that are each too complex to memorize (so you can dump them in a locker or support one login services, each creating a single point of failure, or you can use a similar password or mental password algorithm for each site, it's all tradeoffs).
I don't think there's an obviously better solution, I think it's just a tragedy of the commons we were probably inevitably going to trip over sooner or later.
Also, you'd have to see a massive amount of value in not signing up to Bitly to offset the hours you'd spend creating a vastly inferior hack job on your own.
All I'm claiming is that bitly could have offered stats without a login system. IFTTT was just a proof of that concept, a gratuitous example, not some idealized form of stat tracking that everyone should run out and implement.
You're probably right that the solution I thought of in around ten seconds sucks. I've spent more time on worse ideas. My real point is that login systems, despite their ubiquity, have their own share of downsides. Some of these downsides should be painfully evident today given the article.
It's quite common for a company to want to use their own identity portal for employee authentication with a particular piece of software and a few companies implement this via giving users shortened links which resolve to the identity portal location. They will hardcode the request to bit.ly & then give the users the token to enter when the software starts. It will then send the full bit.ly request and get a destination location back for the portal.
In every case I've seen this, I've written it as a high risk finding since neither the software vendor nor the company using the solution has ever done an audit of the security controls at bit.ly or the other link shortening services. If a link shortening company like bit.ly is compromised & a bad guy is able to modify link destinations then it's pretty much over in terms of security for a software solution implementing this model. There also tends to be some issues in terms of implementing public key or certificate pinning when using a third-party but I'll save that for another day.