Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Cloud fraud defense, the next evolution of reCAPTCHA

cloud.google.com

Post reply on HN
Print view View original

431–440 of 467 posts

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#431

Post by grogenaut »

AnthonyMouse wrote: post #290
grogenaut wrote: post #232

Earlier quoted context omitted.

Your idea works for generic crawlers. That doesn't work for targeted bots. A major benfit of device attestation is to stop the hordes of custom bot creators who try all sorts of ways to make a buck off of your platform such as sms toll fraud, credit card testing, ad fraud, account takeovers, stolen card laundering, gift card laundering, botting for pay for platform / ecosystem benefits, paid harassment, the list just…

> A major benfit of device attestation is to stop the hordes of custom bot creators Attestation is extremely ineffective at preventing this because it requires attackers be unable to compromise their own devices, even when they have permanent physical access to the hardware and can choose which model to buy and get devices known to be vulnerable. For example, CVE-2026-31431 is from only a week ago. It's a major local…

s/stop/reduce/

I don't consider it a panacea.

People with rooted android phones are a drop in the bucket compared to people running botnets using programming languages. I'd be super happy if I could force people to use low end rooted android phones for botting. It'd massively decrease the problem versus a EC2 instance running at full tilt.

Getting and managing a fleet of rooted phones is not a trivial task.

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#432

Post by WalterSchulz2 »

Forgeties79 wrote: post #419
handedness wrote: post #417

Earlier quoted context omitted.

The prospects for growth are better than ever. GrapheneOS by installer download stats looks to have approximately a quarter of a million users, and the new Motorola partnership should cause that to increase significantly. If nothing else, it will be a major OEM shipping a non-customer-hostile mobile OS officially for the first time in ages, and Motorola's reach is significant: https://www.androidpolice.com/motorola-r…

Graphene is still tied directly to Android and Pixel devices. It is always at risk. Good luck if Google decides they don’t like the project enough. I went through that nonsense with Canon and magic lantern years ago. Firmware 2.3 was specifically designed to break it on all DSLR’s

Hello!

This is Walter Schulz, core team member of the Magic Lantern project and been there back then when Canon introduced firmware 1.3.6 for EOS 5D3. Not sure what you mean by "Firmware 2.3". Let's clear this up: - Canon came up with 1.3.3 to 1.3.5. This disabled in-cam downgrade via Canon Menu. But it was still possible to use EOS Utility's firmware update option to install 1.1.3 or 1.2.3 (or any other version up to 1.3.5). - There were no additional locks installed. We always had the option to port ML to 1.3.3 or 1.3.5. We could but we don't wanted to and there was no need. - Other cams didn't get this treatment.

Then came 1.3.6 which disabled the EOS Utility option, too. Now it looked like Canon forced our hand and we were forced to port ML to 1.3.6.! Meh! But no additional locks either. Porting ML to 1.3.6 essentially was the same as for 1.2.3. Some users got 1.3.6 installed during maintainance because Canon Support installed this version without asking. Some (singel one or more, don't remember) went back and asked for downgrade in order to use ML again. And Canon Support did that. Not exactly the action you expect from a company with the intention to block ML, right? ;-)

It didn't take long and user Apollo7 came up with a method to bypass this downgrade lock. Which came handy because of a publicity stunt by someone: https://research.checkpoint.com/2019/say-cheese-ransomware-i... "Strange" attack vector for sure. Well, it made news and Canon reacted by patching several camera firmwares for ML-enabled cams (but not all of them!).

But again: There was no lock making ML development for patched firmware more difficult or even disabling it! It would still be possible to port ML to any new firmware. We just wanted to avoid the load of unwanted work. Porting is no joke and may result in headache. Lot of work.

But today Canon upped their game. They learnt how to use real security features and newer cams won't allow our old methods to work. True.

So ... can you please stop the nonsense "was specifally designed to break it on all DSLRs", please?

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#433

Post by gib444 »

ProllyInfamous wrote: post #422
gib444 wrote: post #409

Earlier quoted context omitted.

Good on you Curious about email though - do you mean you don't use it for signups/logins etc or you don't use it in any capacity? You send a lot of letters I guess? Sounds like one of those things which sounds impossible to give up but it isn't really

>don't use it in any capacity? Nope. >You send a lot of letters I guess? [checks own profile] mostly, typewritten. ---- My stockbroker hates my chosen distance. So does my lawyer. So does most family. For most, letters suffice. In my neighborhood I am well respected and known. Everybody else can come visit... or else fuck off . ---- There should be an email/phone platform where you have to pay to contact — and then t…

Love it. You go man. You and I would get on LOL

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#434

Post by handedness »

WalterSchulz2 wrote: post #432
Forgeties79 wrote: post #419

Earlier quoted context omitted.

Graphene is still tied directly to Android and Pixel devices. It is always at risk. Good luck if Google decides they don’t like the project enough. I went through that nonsense with Canon and magic lantern years ago. Firmware 2.3 was specifically designed to break it on all DSLR’s

Hello! This is Walter Schulz, core team member of the Magic Lantern project and been there back then when Canon introduced firmware 1.3.6 for EOS 5D3. Not sure what you mean by "Firmware 2.3". Let's clear this up: - Canon came up with 1.3.3 to 1.3.5. This disabled in-cam downgrade via Canon Menu. But it was still possible to use EOS Utility's firmware update option to install 1.1.3 or 1.2.3 (or any other version up t…

Excellent information, thank you!

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#436

Post by jeroenhd »

adrian_b wrote: post #332
jeroenhd wrote: post #292

Earlier quoted context omitted.

> And you must be signed in. I don't see any mention of that? Google Play services work fine without an account (although if you're the kind of person who doesn't sign in to a Google account on their Android phone, you're probably running a custom ROM or something)

Until now, I have never run "a custom ROM or something", but just the Android that came from the phone vendors and its updates. Nevertheless, I do not have a Google account and I do not intend to have such an account. Of course, this means that I cannot install any app from the official Google store, even if it is a free app. The requirement to login into your Google account should have existed only for payments, not…

Google Play Services is not Google Play Store.

Google Play services is an automatically updated API that Google distributes through the Play Store. It also encompasses some security updates, such as updates to the Bluetooth stack.

You do not need a Google account to update those. In fact, chances are you already got the update weeks ago without noticing.

You can also update pre-installed apps through the Play Store without an account (hold the Google Play icon and select "My apps").

You do not need to install an app. You do not need to make an account. All you need is a QR code scanner and an Android phone that had Google's stuff preinstalled.

I have plenty of issues with the Google Play Store as well, but they don't apply to this topic.

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#437

Post by jeroenhd »

Velocifyer wrote: post #362
jeroenhd wrote: post #296

Earlier quoted context omitted.

That doesn't really help if the same Huawei bot keeps re-requesting a bunch of 600 KiB JPEG from 120 rotating IP addresses with random crap at the end of the URL, like what happened to one of my servers. Efficiency doesn't really matter if you're getting hammered by bots. I ended up aggressively IP blocking all of China, Singapore, and a few other East-Asian countries once I noticed that blocking server IP addresses…

Try using anubis. It uses a PoW challenge to make it not make economic sense to scrape websites.

Anubis won't work now that scrapers just allocate more CPU time to beat Anubis challenges. The default configuration also permits all bots, only catching bots pretending to be browsers.

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#438

Post by jeroenhd »

alfanick wrote: post #388
jeroenhd wrote: post #300

Earlier quoted context omitted.

Right! Let me check the URL before clicking the "confirm your account" link! https://rt434.mjt.lu/lnk/GN2PVLyAIiUHuMqkGcjHkjkcRBtF/zJfB7p... Oh wait, never mind. I guess I won't be signing up for electricity, then? Also, the vast majority of people don't know that google.com and loginto-google.com aren't the same website, or that google.com.securesigning.net isn't real Google. If your device gets busted by opening a…

> Oh wait, never mind. I guess I won't be signing up for electricity, then? You ~~will~~ should be picking up your phone and calling the electrical company to confirm and to tell them their links are nonsense. Couldn't bother with AI agent on phone, or 60 min waiting queue to a human? Fuck it, don't pay the bill, figure it out later.

Their customer support people don't know what I mean and they especially don't have any power to change this.

The problem isn't paying the bills (I can't recall the last time I ever needed to do that manually), the problem is that pretty much every service uses trackers and shorteners. The only way to opt out is to opt out of society.

Maybe I should, but this "read the link before you click" advice isn't just geared towards hardcore privacy advocates. It hasn't worked in ages. It also doesn't help that companies like Outlook rewrite links to make them redirect through their malware scanners as well.

Re: Google Cloud fraud defense, the next evolution of reCAPTCHA

#439

Post by jeroenhd »

olyjohn wrote: post #415
jeroenhd wrote: post #300

Earlier quoted context omitted.

Right! Let me check the URL before clicking the "confirm your account" link! https://rt434.mjt.lu/lnk/GN2PVLyAIiUHuMqkGcjHkjkcRBtF/zJfB7p... Oh wait, never mind. I guess I won't be signing up for electricity, then? Also, the vast majority of people don't know that google.com and loginto-google.com aren't the same website, or that google.com.securesigning.net isn't real Google. If your device gets busted by opening a…

What's the point of confirmation or user interaction, when nobody knows how to read a URL, and they just click the goddamn accept button?

The user doesn't need to know the exact URL to confirm an interaction they've just started.

The point of the confirmation is 10% account creation and 90% confirming that the user knows their own email address and can type it in correctly. That's actually more challenging to the wider audience than you might think.

Post reply on HN