Impersonating the brave.com website to deliver malware
arstechnica.com
arstechnica.com
Ah I see it’s more nuanced - and works to detect homographs whilst permitting pure Chinese (for example).
https://mobile.twitter.com/moo9000/status/138419716439861658...
https://mobile.twitter.com/moo9000/status/136785214503120896...
Every page will be signed by a key and our browser will show the popularity and karma of that key.
The popularity and karma of a key will probably be readable on a blockchain, similar to the account balance of a Bitcoin address.
If one was to download a popular software and then sees the website is not signed by a popular key, they would double check if they are on the right site.
Karma will probably be a customized value. Counting the opinions of my friends over the opinions of my friends friends etc.
WOT: "The owner of this key is Joe Doe as confirmed by Susi Dusi and Lars Lampert".
What I mean: "The ownder of this key has a popularity of 23 (as can be seen on chain) and a karma of 75 (as calculated from my personal social graph or interests and on chain data)".
Looking at a Bitcoin address you can see that the owner of that address owns at least X bitcoin. But you don't know who he is. This is what I propose for popularity and karma.
I think it should go one step further - if Google determines a link is a Apple ID phishing link it just silently redirects it to Apple’s real ID login page. Anything that presents a barrier that you can apparently solve is going to be bypassed.
The largest providers could register their login page look and feel with the biggest browsers and nobody would be allowed to mimic them.
Lol, amazon would in a heartbeat declare any page which has two input fields and a button as a 'login page' (regardless of the actual styling).
Of course all three options fail to gain significant traction. The Windows Store tries to change the entire concept of a Windows application, while Choco and Scoop are command line applications targeted at IT admins.
In the meantime browsers can include a list of all popular software vendor domains and flag users navigating to similar but different domains. This will not be the first or the last whitelist that browsers include.
I don't think it automatically leads to "hyper lock-down". An environment like the browser can do almost anything users want, and can be made safer. But if the tech sector refuses to cooperate, or is inept, then we might head down lock-down road.
You cannot educate your users. You need to solve this some other way.
It’s too easy to blame the users for not checking everything - but nobody has the time to check everything. Not everyone can be a domain expert in everything.
Do you verify that the building claiming to be your bank is still your bank and wasn’t replaced overnight?
I agree that it can’t be solved by “making people smart” - the solution has to be something else. Things like “sign in with Apple” that are engineered so that they sign in CANNOT work at a non Apple domain (because the username the phone sends is based on the certificate sent by the website or something) are things we’ll need.
IQ is normalized on averages, not medians.
That makes quite a difference. E.g. you could have a massive number of people at 99.9 against a few of 150.
The article says that the site has a valid certificate and it should have been possible to detect that domain certificate generation through one of the CT logs? The website hosting company took the domains down in this case but maybe there needs to be a good automated solution which would help most companies report when they did find phishing sites using lookalike domains. Not a trivial problem to solve, I guess.
https://chromium.googlesource.com/chromium/src/+/main/docs/i...
https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm
Safari (implicitly) bans scripts with letters that look like Latin characters. https://support.apple.com/kb/TA22996
https://en.wikipedia.org/wiki/IDN_homograph_attack#Client-si... also indicates that Edge, Opera use Chrome's algorithm (makes sense, being built on Chromium).
Wouldn't applying Unicode normalization on domains solve this issue? For example, if a site attempts to send me to “ápple.com”, my user-agent would send me to the correct domain. Domains in Japanese, for example, would still work just fine.
Ideally, this would be handled at the DNS spec level (“no two domains shall map to the same normalized form”), but that would be even more “too late” to change.
"Did you intend to go to “ápple.com” (suspected malware host), or “apple.com” (100b visitors a year)?
Though why you should be able to purchase .com domains with punycode, I don't know.
The .com TLD registry's priority is profit at any cost. A crook's money is just as good as anybody else's, right?
Just 13% of the world speaks english. It is not a reference for how we do or should write on the web.
It would maybe make sense to restrict url display to the computers language setting.
Unless you're proposing we let it live in case someone somewhere ever uses it. Then, sure.
Of course that registry actually has a sane punycode policy, so such impersonations are impossible there, whereas they're happening all the time in .com. Maybe time to re-evaluate your idea of "reality" versus "theory".
It does make sense to permanently disable Punycode.