Banks and credit card companies have always been the absolute worst offenders for this, requiring people to use hidden iframes from all sorts of acmegenericsecure.net domains, and all the while professing to be the high priests of good practice with their absurd PCI racket, not to mention asking people to install random third party software just to use their websites because browsers apparently aren't good enough.

Chase likes to send emails from the not-at-all-suspicious "acctmanagement.com" domain[1].

[1]: https://twitter.com/8x5clPW2/status/1046244493203263488

Google's use of gvt1.com had me convinced for the longest time that I was backdoor'd by some unknown branch of the government that was either not bright enough to cover their tracks or ballsy enough to just say "yea, it's us. the government. and we're in your computer"

Their reply to your tweet pisses me off

Not as bad as T-Mobile defending the practice of storing passwords in plaintext!

Defending at least implies engaging with the complaint.

Chase just said "go file a ticket". In other words, "fuck off".

Just last year I told Ikea that they use a phishing like url in my country. Something like makeyourhomegreat.com (I can't remember the exact URL). They actually stopped using that URL but I'm not sure it was because of me or some other reason.

>not to mention asking people to install random third party software just to use their websites because browsers apparently aren't good enough.

is this still a thing? maybe this was true back in the days when activeX was still common, but not now.

Check out Rapport, big banks prompt you to install it everytime you visit their login page.

Which banks? Chase, BofA, and Amex do not, and I'd like to stay far away from those that do.

The sensible thing would be to have dedicated software for anything involving handling money, in particular banking. Then you could tell people to never interact with their bank using a web browser.

> The many mobile browsers which hide the address bar are training people to ignore website urls.

This is my biggest complaint about forcing users to use apps to browse a website-- it hides everything. I have no idea if any given app is actually using SSL. Oversights have happened before to Credit Karma, Fandango and others.

IIRC you can still submit an app with exemptions to this rule; you will just have to provide a justification for it that Apple deems reasonable.

On the positive side, with apps, there's a lower chance to land on a phishing app, because apps need to be reviewed before they appear on the store.

RIP Microsoft. IMO this is a big reason why their phones/app store died. Try finding the real VLC player in the store - last I checked they dont even have a app store version (but you'll find tons of results for it).

There's real vlc app in both Windows and WP app store. In fact there were two official VlC apps for Windows Phone. One was written with c/c++ and the other UWP version

^ Though, it should be noted that the fact that there's two official versions speaks to a somewhat parallel issue.

> email tracking links ... domains have nothing in common with the destination URL

The tradeoff has been CNAME-ing your own subdomain to your Email Service Provider’s tracking domain, which gets you a recognizable(-ish) URL, but has historically prevented https links, or using the ESP’s tracking domain directly, which allows https but makes sketchy-looking URLs.

I’d think Let’s Encrypt would make it possible to offer https on white-labeled (CNAME’d) tracking domains. Seems like an opportunity for some enterprising ESP.

(Yes, two other options are not tracking email links, or running your own tracking. I’m going to assume these are not realistic for most marketing departments.)

> I’d think Let’s Encrypt would make it possible to offer https on white-labeled (CNAME’d) tracking domains.

Technically, Let's Encrypt is not unique here. AFAIK, most CAs allow subdomain certs (and only validate ownership of said subdomain, not the top-level domain).

Let's Encrypt just makes it scalable financially.

Relying on users manually confirming that the domain is correct has never been a good strategy. The user is supposed to tell microsoft.com from micros0ft.com from microsoft.co from microsoft-corp.com?

I recently saw a MacKeeper landing page url: "www.apple.com-spamsite.info/landing"

It was truncated in the url-bar enough to look like "www.apple.com".

The landing page, of course, was a clone of the apple.com website with a "Scan Computer" button that did the ol trick of showing you some animations before suggesting you use MacKeeper to clean up 17 viruses.

That is modern art!

Another thing is the login with Google/Facebook buttons that do a redirect where you enter your password. It always makes me nervous that a website could create a fake Google/Facebook login page and collect my password, and I make a point of looking at the login page extra carefully. However, I bet that the average computer user doesn't do this.

Sounds like you are talking about the OAuth authentication flow which is designed to use a separate window/iframe for entering credentials. This allows the application to authenticate the user without ever having access to the cleartext credentials.

That’s providing that the login page you enter your credentials in actually is Google/Facebook. The app can easily open a login page which looks identical, but actually submits your credentials somewhere nefarious.

Whatever.ms/login? Mont-fricking-serrat? Well that's all but screaming FAKEFAKEFAKE.