Live data from Hacker News

A URL shortener not shortening the URL but makes it look very dodgy

github.com

71–80 of 104 posts

Re: A URL shortener not shortening the URL but makes it look very dodgy

#72

I would consider this innovative, but Office365 has had this built in (and as far as I can tell impossible to turn off) for years. What used to be a sensible link turns into a vast "safe link honest, guv" mess. I call it "man in the middle attack as a service"

I sent a URL through Teams to an Ops guy to put in an Nginx configuration file as an upstream server. He just copied and pasted and it's now a configuration file in production with all of the parameters Teams added.

Re: A URL shortener not shortening the URL but makes it look very dodgy

#74
post #61

Earlier quoted context omitted.

> URLs that encode more information than some of the meetings themselves in the worst case Sadly this is also possible with a 9-letter code.

I went to a government committee meeting, first one of the committee to get the ball rolling. 2+ hours of everyone introducing themselves, to folk who already know each other. And we're adjourned. Next month we'll discuss the rules of governance for the committee. That's two of the total 6 meetings the committee has allocated. And all the bureaucrats made plenty of show for the "progress we've made".

A lot of bureaucracy at the beginning might not be bad if it's indeed front-loading it for an otherwise successful collaboration.

Re: A URL shortener not shortening the URL but makes it look very dodgy

#78
post #55

Earlier quoted context omitted.

Same for MS Teams. Before, we used Google Meet, which produced 9-letter meeting IDs, that I would be able to remeber if I really wanted to. Teams just generates mile long URLs that encode more information than some of the meetings themselves in the worst case.

> URLs that encode more information than some of the meetings themselves in the worst case Sadly this is also possible with a 9-letter code.

Well, in the worst case a single bit is overkill.

Re: A URL shortener not shortening the URL but makes it look very dodgy

#80

Earlier quoted context omitted.

Same with PayPal. I've received perfectly valid emails direct from PayPal that include random sketchy links from third parties that are obvious phishing expeditions. I reported it to PayPal, but the ability still exists.

That's inherent to features that allow user generated content, which is obviously mandatory in the context of PayPals invoicing feature. The only reason why companies don't care about it in the context of mail is because there is no equivalent to safe browsing for mails, so Domains aren't penalized by Google for sending fraudulent messages at small scale. If this was to change, they'd all pivot to using secondary dom…

How about disallowing urls or even just vetting urls in the messages sent from your own service? One of the ones I received was a link to a fake PayPal login that was something along the of lines of (making this up) http://login.PayPal.com.somethingsketchy.biz/login.php and was a replica of the PayPal login screen. It was pretty blatant. Seems like they should figure out a way to avoid that is all, because I know my mother would have put in her PayPal credentials to that site and I'd be hard pressed to fault her for it. We train users to check if it's a valid/real email before clicking on links and this was a perfectly real email sent from PayPal with a malicious link. This seems like PayPal's responsibility to me. I'm shocked they don't care about this.
Post reply on HN