Bug 1571003 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

There's also a similar AutomaticAuth prompt. These were implemented in 2004 (bug 232567) when many phishing attacks came through text links in mail or chat apps (AIM!). Spoofing users via the source link was popular: people looked more closely at what they were clicking on than they were likely to double-check the URL bar to make sure that's where they ended up. Potential victims knew spoofing via HTML was easy -- the link didn't have to look like a  URL at all -- but tended to trust text more.

This also predated SafeBrowsing phishing protection by 5 years or so. Attacks are different now, and we have other defenses.

Pretty sure we can rip these out, but if we want to be more conservative we could pref them off and add telemetry to count how many times we see it being used in the wild. Between the two prompts there appear to be three cases.

SuperfluousAuth is used in two places:
* the site does not use Auth (always suspicious)
* the site uses auth (returns 401/407) but auth fails (might be a legit error, might be a phish trying to avoid the first case)

AutomaticAuth is a warning for the "normal" case of a URL with userinfo. Maybe it's legit, or maybe the phisher implemented auth to avoid the SuperfluousAuth warning.

We implemented these rather than follow IE's lead and simply reject any attempt to load a URL with userinfo. If telemetry shows a low incidence of the legit case maybe we can just follow suit at long last. But _this_ bug should not be able that. Telemetry yes, but otherwise just solve the prompt DOS issue. We can revisit bug 479038 if we want to disable these entirely.
There's also a similar AutomaticAuth prompt. These were implemented in 2004 (bug 232567) when many phishing attacks came through text links in mail or chat apps (AIM!). Spoofing users via the source link was popular: people looked more closely at what they were clicking on than they were likely to double-check the URL bar to make sure that's where they ended up. Potential victims knew spoofing via HTML was easy -- the link didn't have to look like a  URL at all -- but tended to trust text more.

This also predated SafeBrowsing phishing protection by 5 years or so. Attacks are different now, and we have other defenses.

Pretty sure we can rip these out, but if we want to be more conservative we could pref them off and add telemetry to count how many times we see it being used in the wild. Between the two prompts there appear to be three cases.

SuperfluousAuth is used in two places:
* the site does not use Auth (always suspicious)
* the site uses auth (returns 401/407) but auth fails (might be a legit error, might be a phish trying to avoid the first case)

AutomaticAuth is a warning for the "normal" case of a URL with userinfo. Maybe it's legit, or maybe the phisher implemented auth to avoid the SuperfluousAuth warning.

We implemented these rather than follow IE's lead and simply reject any attempt to load a URL with userinfo. If telemetry shows a low incidence of the legit case maybe we can just follow suit at long last. But _this_ bug should not be about that. Telemetry yes, but otherwise just solve the prompt DOS issue. We can revisit bug 479038 if we want to disable these entirely.

Back to Bug 1571003 Comment 4