Live data from Hacker News

Google-hosted malvertising leads to fake Keepass site that looks genuine

arstechnica.com

191–197 of 197 posts

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#191
post #188

Earlier quoted context omitted.

It still sounds like an improvement: while they might still fall for malicious URLs in their own language, they would not for other scripts. But as someone said, tiny, valid differences are easy to miss anyway, and original URL attacks were replacing similar-looking ASCII graphemes (eg. l for 1), so this will all continue.

> while they might still fall for malicious URLs in their own language, they would not for other scripts. That's totally backwards. If the assumption is that users of language X will legitimately visit sites of language Y with sufficient frequency, then all that language-specific filtering makes no sense.

If a browser implements single language decode-punycode, they could also support user specifying multiple languages (like they do for Accept-Language).

And seeing punycode in URL bar does not mean a site does not work, it's only a suboptimal experience.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#192
post #139

Earlier quoted context omitted.

I did so too. Only that often, that I'm no longer able to report any ads at all.

If you can, you should escalate with google support. Thats pretty bullshit that they expect users to report ads, but penalize them for doing so. I pay, and if they cut me off for helping do their job, I'd be livid. Maybe being a paying customer is the reason they haven't blocked me yet

I think the various dubious ads are worth more than I am.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#193

"The ads were paid for by an outfit called Digital Eagle, which the transparency page says is an advertiser whose identity has been verified by Google." OF COURSE they were verified by Google. Google verifies identity by accepting money. Give them money, and you're verified. "Google representatives didn’t immediately respond to an email" Are there real humans at Google who actually answer email? I haven't seen a resp…

Are there real humans at Google who actually answer email? Google's strategy has always been to focus on the things that scale. Having a human answer a phone or a mail doesn't scale, so no customer service for the users. I think this is also the reason why these ads get through: to detect them they rely for a large part on crowd-sourcing: that "report a problem" link is IMHO one of their main mechanisms to deal with…

For Google one and enterprise customers, I do believe there is a support line where you speak to an actual human

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#194

Earlier quoted context omitted.

It's be funny if there was baby shaving cream—like baby shampoo but shaving cream and for babies (as advertised on bottle)

There is. Goes with a plastic razor that won't cut anything. I've seen it before, it might or might not still be in the toy section of your local WalMart.

Vaguely remember the Hulk shaving kit. If I ever had a son, he would totes be receiving one like immediately for the bath aha

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#195

Earlier quoted context omitted.

There is. Goes with a plastic razor that won't cut anything. I've seen it before, it might or might not still be in the toy section of your local WalMart.

Vaguely remember the Hulk shaving kit. If I ever had a son, he would totes be receiving one like immediately for the bath aha

There's something so adorable and poignant about your "little man" emulating Hulk for your woman

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#196
post #184
post #115

Earlier quoted context omitted.

As a german I wouldn't go to göogle.com. If my native language didn't include ö? Then that might be a speck of dust to me as well. A safer approach would be to only ever show a user the characters they expect to see (and are familiar with), e.g. based on their language setting. Assuming that every language has a finite list of characters used in its written form such a whitelist approach should be possible and much b…

> Assuming that every language Oof. Take for example, both 糉 and 糭 are valid characters in Chinese. One is a variant of the other. Which one is "canonical" depends on who (i.e. which authority, of which there are many) you ask. And FWIW the language and regional settings don't necessarily give an answer to the canonical representation. Those characters mean the same thing with or without the specks of dust. So, what'…

What you mention here does not contradict my assumption that there is a finite set of valid characters in every language, unless there is a rule in chinese that lets you assemble an infinite set of meaningful characters/symbols (unicode could still represent only a finite subset of those, though).

Either one or both of the characters you mention are probably part of the script of the users language setting in chinese; if the character is then it should be rendered as unicode and if not as punycode. If the users language has this kind of ambiguity then they are the only ones to judge if the domain name is correct or not, but at least they are familiar with the language and do not see characters they might have never encountered before and/or need to deal with an ambiguity that they shouldn't even have to expect to begin with.

The idea I proposed would still protect someone with a chinese language setting from being tricked by e.g. a cyrillic character in an otherwise ASCII domain name. I don't see how that is euro-centric (apart from ASCII being inherently english-centric), it is an overall improvement over the status quo no matter where you live and what language you speak.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#197
post #188

Earlier quoted context omitted.

It still sounds like an improvement: while they might still fall for malicious URLs in their own language, they would not for other scripts. But as someone said, tiny, valid differences are easy to miss anyway, and original URL attacks were replacing similar-looking ASCII graphemes (eg. l for 1), so this will all continue.

> while they might still fall for malicious URLs in their own language, they would not for other scripts. That's totally backwards. If the assumption is that users of language X will legitimately visit sites of language Y with sufficient frequency, then all that language-specific filtering makes no sense.

Why wouldn't it make sense? If a chinese user e.g. specifies that they speak chinese and, say, french, all characters in those two language would show up as unicode and everything else as punycode. A malicious domain using e.g. cyrillic characters to create a domain that looks just like another french (or just plain-ASCII) one would show up as punycode. Sounds like a net improvement over what we have now.
Post reply on HN