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

Thanks HN: Lessons learned after Google nearly killed my site

uploader.win

Post reply on HN
Print view View original

171–180 of 296 posts

Re: Thanks HN: Lessons learned after Google nearly killed my site

#171

Post by hn_throwaway_99 »

duckfang wrote: post #45
LocalH wrote: post #26

Earlier quoted context omitted.

> On the other hand, this same sort of information can make it easier for malicious users to evade detection I never bought that excuse. That sounds like saying we should be secretive about legal charges brought against a person, lest that information help criminals evade detection.

Alas, there goes my post (currently at -3). Although I didn't elaborate about the libel, I do believe there is a strong separation between a "malicious site" and a "site that has malicious content". If someone encoded an image in an HN post encoded as base64, that could be definitely malicious content. But that would not make HN a malicious site. No reasonable person would argue that. I would argue that claiming it w…

> If someone encoded an image in an HN post encoded as base64, that could be definitely malicious content. But that would not make HN a malicious site. No reasonable person would argue that.

I don't consider myself particularly unreasonable, but I would argue that.

I see what you're getting at in that you seem to be focusing on the intent of the site owner, but I don't think that's a hair worth splitting. If you have poor security on your site such that you allow upload, and more importantly hosting and distribution of malware, you are now the owner of a malicious site.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#172

Post by stevarino »

klingon79 wrote: post #170
that_guy_iain wrote: post #86

>Now we run automated tests to monitor server uptime and check server for problems every 30 seconds. Unfortunately automated test scripts were happily getting HTTP/200 replies while people using the Chrome browser were being told this is a scam business trying to steal their bank account information. I was surprised this wasn't part of the lessons learned. But it seems the monitoring basically failed but that wasn't…

How would Google know that a site is curling another site? Why would they flag that as a phishing site? I’m just having a difficult time determining how this situation is not the fault of the site/app; we don’t even know that any of this is true and it looks more scripted than an offended rant.

The curl'ing is not necessarily bad (and can continue just fine), but rather its blind to these types of problems. A false positive in your testing framework (especially something like this) is the worst case scenario.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#173

Post by that_guy_iain »

klingon79 wrote: post #170
that_guy_iain wrote: post #86

>Now we run automated tests to monitor server uptime and check server for problems every 30 seconds. Unfortunately automated test scripts were happily getting HTTP/200 replies while people using the Chrome browser were being told this is a scam business trying to steal their bank account information. I was surprised this wasn't part of the lessons learned. But it seems the monitoring basically failed but that wasn't…

How would Google know that a site is curling another site? Why would they flag that as a phishing site? I’m just having a difficult time determining how this situation is not the fault of the site/app; we don’t even know that any of this is true and it looks more scripted than an offended rant.

Google wouldn't know that someone is curling it which their script said everything was ok. While the website was basically down because Chrome and Firefox will both block a site based on Google's safe browsing list.

They could use Google's safe browsing api to check if they're on that list as well as curl.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#174

Post by colinmhayes »

sneak wrote: post #150
imwillofficial wrote: post #147

So this sucks for the developer, but I have another story to share. I was trying to buy a school bus to make a schoolie out of, the Craigslist add directed me to a seemingly innocuous eBay motors link that looks pretty close to the real thing. I was busy and clicked, totally intending to drop $5k. I got distracted and had to come back to it later, when I did, credit card in hand, the page showed the red screen with a…

The fact that they are sometimes useful does not negate the fact that they have too much power to censor the web.

It kind of does though? Either people get scammed by broken URLs or google sometimes bans innocent sites. I would expect most chrome users prefer innocent sites occasionally banned.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#175

Post by scrollaway »

that_guy_iain wrote: post #173
klingon79 wrote: post #170

Earlier quoted context omitted.

How would Google know that a site is curling another site? Why would they flag that as a phishing site? I’m just having a difficult time determining how this situation is not the fault of the site/app; we don’t even know that any of this is true and it looks more scripted than an offended rant.

Google wouldn't know that someone is curling it which their script said everything was ok. While the website was basically down because Chrome and Firefox will both block a site based on Google's safe browsing list. They could use Google's safe browsing api to check if they're on that list as well as curl.

Frankly, Google's Safe Browsing list is one of those things which should be broken out of Google and ran by an independent entity, much like the Let's Encrypt model.

I don't know how to help make this happen.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#176

Post by core-utility »

that_guy_iain wrote: post #86

>Now we run automated tests to monitor server uptime and check server for problems every 30 seconds. Unfortunately automated test scripts were happily getting HTTP/200 replies while people using the Chrome browser were being told this is a scam business trying to steal their bank account information. I was surprised this wasn't part of the lessons learned. But it seems the monitoring basically failed but that wasn't…

When talking about checks on the order of twice a minute, curl is probably the right approach. You can/should still do a full check, but that can be done at a lower frequency.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#177

Post by that_guy_iain »

core-utility wrote: post #176
that_guy_iain wrote: post #86

>Now we run automated tests to monitor server uptime and check server for problems every 30 seconds. Unfortunately automated test scripts were happily getting HTTP/200 replies while people using the Chrome browser were being told this is a scam business trying to steal their bank account information. I was surprised this wasn't part of the lessons learned. But it seems the monitoring basically failed but that wasn't…

When talking about checks on the order of twice a minute, curl is probably the right approach. You can/should still do a full check, but that can be done at a lower frequency.

To be fair, my page load checks aren't just is the site up and responding 200 but also page performance anomaly detection and stuff. So I want/need to see the performance minutely to be able to detectly in a quickish amount of time if the performance has degraded for the entire pageload. You could have a minute where it's slow and that is ok but if you have 5 minutes of it being slower than normal one after another then you have an issue. I feel if you're doing checks every few minutes your data won't be as good as doing it every 30 seconds. It is way more resources but honestly, I think it's the future of monitoring. Also, having multiple types of ways of calling a site via http to monitor it is way more complex.

The main offer is for order monitoring but I am in the middle of creating a just page load monitoring offer for others since I think that service by itself is super useful.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#178

Post by judge2020 »

kuschku wrote: post #155
ncann wrote: post #103

Earlier quoted context omitted.

Plus it is always a bad idea to give someone a code sent to your number. 99% of the time someone is trying to hack you and a necessary step is obtaining that code.

For me that actually ended up the only way to gain access back to an old account of mine. Luckily I was able to cooperate with the new owner of the number, and he was helpful enough to give me the code that was sent, otherwise I'd have lost a Google account with several hundred euros of purchases on it, despite having the password, control of the backup email, knowing all security questions, and knowing the exact dat…

The obvious issue with this is that the new owner of the number doesn't actually know if it's the owner of the old account trying to sign into it - it could be anyone trying to take over an account whos owner forgot to change the number for. And how do they know you're not trying to sign into their account? The text messages don't specify which account is being attempted or anything.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#179

Post by rossdavidh »

So, clearly Google has too much power over the internet, it's arbitrary and opaque, etc. I agree. However, I think it is worth pointing out that:

1) malware is often very aggressive and fast-spreading, and once it's on a user's computer it's hard to get off, therefore...

2) the system to detect it and stop access to the site has to be automated, not a human-in-the-loop system that might take hours or days to shut off access to a site which is infecting many users per minute, and...

3) the more clarity there is on how exactly that automated system works, the more certain we can be that malware will be able to evade it; it's much like how spam detection or search page rankings are opaque, because the incentives to game the system are very great

I'm not saying Google's system is perfect, but I am saying it's a very hard problem to solve in a way that doesn't give us an even worse time stopping malware spread than we already have. So while it is hard to feel sorry for a company as wealthy and powerful as Google, I think the issue is not as clear-cut as some comments on this thread seem to suggest.

Re: Thanks HN: Lessons learned after Google nearly killed my site

#180

Post by klingon79 »

that_guy_iain wrote: post #173
klingon79 wrote: post #170

Earlier quoted context omitted.

How would Google know that a site is curling another site? Why would they flag that as a phishing site? I’m just having a difficult time determining how this situation is not the fault of the site/app; we don’t even know that any of this is true and it looks more scripted than an offended rant.

Google wouldn't know that someone is curling it which their script said everything was ok. While the website was basically down because Chrome and Firefox will both block a site based on Google's safe browsing list. They could use Google's safe browsing api to check if they're on that list as well as curl.

My point is: How do we know what the sit author is saying is accurate?
Post reply on HN