Live data from Hacker News

Google begins requiring JavaScript for Google Search

techcrunch.com

101–110 of 158 posts

Re: Google begins requiring JavaScript for Google Search

#102

To be fair, if my search engine is anything to go on, about 0.5-1% of the requests I get are from human sources. The rest are from bots, and not like people who haven't found I have an API, but bots that are attempting to poison Google or Bing's query suggestions (even though I'm not backed by either). From what I've heard from other people running search engines, it looks the same everywhere. I don't know what Googl…

I run a semi-popular website hosting user-generated content, although it's not a search engine; the attacks on it have surprised me, and I've eventually had to put in the same kinds of restrictions on it. I was initially very hesitant to restrict any kind of traffic, relying on ratelimiting IPs on critical endpoints that needed low friction, and captchas on the higher friction with higher intents, such as signup and…

20000 RPS is very little — a web app / database running on an ordinary desktop computer can process up to 10000 RPS on a bare-metal configuration after some basic optimization. If that is half of your total average load, a single co-located server should be enough to eat entire "attack" without flinching. If you have "competitors" and I assume, that this is some kind of commercial product (including running profitable advertising-based business), you should probably have multiple geographically distributed servers and some kind of BGP-based DDoS protection.

Regarding Tor nodes — there is nothing wrong with locking them out, especially if your website isn't geo-blocked by any governments and there are no privacy concerns related to accessing it.

If, like Google, you lock out EVERYONE, even your logged in users, whose identities and payment details you have already confirmed, then... yes you are "enshittifying" or have ulterior motives.

> they were using real Gmail accounts to sign up

Using Gmail should be a red flag on its own. Google accounts can be purchased by millions, and immediately get resold after being blocked by target website. Same for phones. Only your own accounts / captchas / site rep can be treated as basis of trust. Confirmation e-mail is a mere formality to have some way of contacting your human users. By the time Reddit was created it was already useless as security measure.

Re: Google begins requiring JavaScript for Google Search

#103

Earlier quoted context omitted.

HN is usable w/o JavaScript. It doesn't block my access because I choose not to allow it to execute arbitrary code on my computer.

* execute arbitrary code in one of the best studied sandboxes on the planet, which happens to be running on your computer.

… and is an extension of the largest surveillance apparatus ever built by mankind.

Re: Google begins requiring JavaScript for Google Search

#104
post #82

Earlier quoted context omitted.

If it's such a common issue, I would've thought Google already ignored searches from clients that do not enable JavaScript when computing results? Besides, you already got auto-blocked when using it in a slightly unusual way. Google hasn't worked on Tor since forever, and recently I also got blocked a few times just for using it through my text browser that uses libcurl for its network stack. So I imagine a botnet us…

"Why didn't they do it earlier?" is a fallacious argument. If we accepted it, there would basically only be a single point in time where a change like this could be legitimately made. If the change is made before there is a large enough problem, you'll argue the change was unnecessary. If it's made after, you'll argue the change should have been made sooner. "They've already done something else" isn't quite as logica…

> "Why didn't they do it earlier?" is a fallacious argument.

I never said that, but admittedly I could have worded my argument better: "In my opinion, shadow banning non-JS clients from result computation would be similarly (if not more) effective at preventing SEO bots from poisoning results, and I would be surprised if they hadn't already done that."

Naturally, this doesn't fix the problem of having to spend resources on serving unsuccessful SEO bots that the existing blocking mechanisms (which I think are based on IP-address rate limiting and the UA's HTTPS fingerprint) failed to filter out.

> Yes, that kind of thing is very easy to just assert. But just think about it for like two seconds. How much more revenue are you going to make per user? None. Users without JS are still shown ads. JS is not necessary for ad targeting either.

Is JS necessary for ads? No. Does JS make it easier to control what the user is seeing? Sure it does.

If you've been following the developments on YouTube concerning ad-blockers, you should understand my suspicion that Search is going in a similar direction. Of course, it's all speculation; maybe they really just want to make sure we all get to experience the JS-based enhancements they have been working on :)

Re: Google begins requiring JavaScript for Google Search

#106

Honestly I wouldn't be surprised that if Google requires some Proof-of-work done on browser's host's CPU/GPU to validate search results and make it infeasible for bots therefore.

That brings up an interesting conundrum. If PoW were implemented, could known-valid (i.e. goodstanding for over a decade) accounts be switched over to PoS instead? Or paying accounts? PoW could be written into infrequent pages such as the registration page and reset password page. It could run while the user fills in the form. I might implement this on some sites that get attacked.

This gives me an idea: thanks to anti-spam mechanisms residential proxies + headless browsers provide a better experiences than regular browsing on real devices.

Instead of PoW, maybe just make the clients prove they are capable of proxying browser sessions?

Re: Google begins requiring JavaScript for Google Search

#107
post #100

Earlier quoted context omitted.

I've been experimenting with creating single-site browsers[1] for all websites I routinely visit, effectively removing navigational queries from search engines; between that and Claude being able to answer technical questions, it's remarkable how rarely I even use browsers for day-to-day tasks anymore (as in web views with tabs and url bars). We've been using the web (as in documents interconnected with links between…

> I've been experimenting with creating single-site browsers[1] for all websites I routinely visit, effectively removing navigational queries from search engines Surely it would make more sense to use bookmarks?

The bookmark interface on modern browsers is pretty awkward to access. It's a bigger upfront effort to set up an SSB, but they significantly streamline the user experience once they're set up in a way that aligns with what you want to do.

Web Browsers have a sort of inner platform tendency where they roll their own window management, and it just gets very messy and integrates incredibly poorly with the window management of the operating system.

You can open CI in your browser to see how your build is progressing, and in the same window, with a few keypresses, check your private email and then go buy new tires for your car, file your taxes, and after that go watch some porn.

Web browsers are streamlining an undesirable type of context switching: These are all tasks from separate domains, and I don't understand why it would be desirable that all of these things are easily accessible from the same window at the same time.

Having dedicated launchers opening specialized windows allows for a sort of workspace mise-en-place that makes interacting with the computer much more focused and deliberate. Each tool has its place and function.

Re: Google begins requiring JavaScript for Google Search

#108
post #56

Earlier quoted context omitted.

I run a semi-popular website hosting user-generated content, although it's not a search engine; the attacks on it have surprised me, and I've eventually had to put in the same kinds of restrictions on it. I was initially very hesitant to restrict any kind of traffic, relying on ratelimiting IPs on critical endpoints that needed low friction, and captchas on the higher friction with higher intents, such as signup and…

There's a certain relatively tiny audience that has congregated on HN for whom hating ads is a kind of religion and google is the great satan. Threads like this are where they come to affirm their beliefs with fellow adherents. Comments like yours, those that imply there might be some valid reason for a move like this (even with degrees of separation) are simply heretical. I think these people cling to an internet ci…

[dead]

Re: Google begins requiring JavaScript for Google Search

#109

To be fair, if my search engine is anything to go on, about 0.5-1% of the requests I get are from human sources. The rest are from bots, and not like people who haven't found I have an API, but bots that are attempting to poison Google or Bing's query suggestions (even though I'm not backed by either). From what I've heard from other people running search engines, it looks the same everywhere. I don't know what Googl…

> bots that are attempting to poison Google or Bing's query suggestions

This seems like yet another example of Google and friends inviting the problem they're objecting to.

Re: Google begins requiring JavaScript for Google Search

#110

Earlier quoted context omitted.

I run a semi-popular website hosting user-generated content, although it's not a search engine; the attacks on it have surprised me, and I've eventually had to put in the same kinds of restrictions on it. I was initially very hesitant to restrict any kind of traffic, relying on ratelimiting IPs on critical endpoints that needed low friction, and captchas on the higher friction with higher intents, such as signup and…

20000 RPS is very little — a web app / database running on an ordinary desktop computer can process up to 10000 RPS on a bare-metal configuration after some basic optimization. If that is half of your total average load, a single co-located server should be enough to eat entire "attack" without flinching. If you have "competitors" and I assume, that this is some kind of commercial product (including running profitabl…

RPS is a bad measure. 20k RPS is a little if you're serving static files, a raspberry pi could probably do that. It's a lot if you're mutating a large database table with each request, which depending on the service, isn't unheard of.
Post reply on HN