Hey, On Wed, Apr 19, 2017 at 04:08:41PM +0100, John Lane wrote: > Is it possible to do this in qutebrowser - I couldn't find a setting for > it on "qute:settings" ?
Currently it's not. Such a setting would be a first line of defense, but I also want to think some more about fix this properly while still showing the encoded form for "normal" IDN domains (say, a German domain with umlauts in my case). I opened an issue here with some first thoughts: https://github.com/qutebrowser/qutebrowser/issues/2547 > What's also interesting is that clicking the "apple.com" link on that > register article does not work in qutebrowser with the qt5-webkit-ng > backend. It does work with the qt5-webengine backend. Looks like Qt's QUrl doesn't like something about that. While I can open it with QtWebEngine, I can't e.g. copy the URL. I smell some Qt bugs to report... :D On Wed, Apr 19, 2017 at 04:26:30PM +0100, Martin Tournoij wrote: > On Wed, Apr 19, 2017, at 16:08, John Lane wrote: > > Interesting article[1] on the register today about internationalised > > domain name (IDN) spoofing using Punycode[2].k > > > > I think it's quite alarming that many browsers show you what looks like > > apple.com which in reality is something entirely different. That's > > something new I've learnt today! > > > > This can be configured against in Firefox about:config by setting > > "network.IDN_show_punycode=true" > > I thought all of this was fixed years ago by normalizing various homographs to > their Latin variant. Guess not :-/ > > There are some other fixes we could do as well. If we see that punicode is > being used, we can try to do a lookup to the normalized domain name, and if it > exists, use that (possibly with a warning). That way the "Cyrillic Apple" > becomes regular ol' apple.com. > > I don't know how fool-proof unicode normalisation is, though. Unicode is > pretty large, so there may be oversights? I don't think this is a good solution. Apart from it being quite hacky to implement, if I tell the browser to go to the not-quite-apple site, I want it to go *there*, not to apple.com. I'm also not sure if normalization actually does this kind of thing. Cyrillic letters probably have some kind of sensible mapping to latin ones, but what if you happen to find, say, some Chinese or Japanese glyph which just happens to look like a "o" but has nothing to do with it? > Another, safer, way would be to improve on the Firefox setting by including a > whitelist of codepoints for common "safe" scripts, such as Arabic, Hangul, > Chinese, Kanji, and perhaps a few others. If all characters fall in that > range: show the codepoints, else show the punycode. > That particular domain from the article uses Cyrillic, so we can't add that to > the whitelist. Chromium apparently went for a blacklist[1], but I wonder what other creative lookalike glyphs you could find if you searched hard enough... [1] https://chromium.googlesource.com/chromium/src/+/08cb718ba7c3961c1006176c9faba0a5841ec792%5E%21/ Florian -- https://www.qutebrowser.org | [email protected] (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
signature.asc
Description: PGP signature
