DigiCert recently was forced to invalidate something like 50,000 of their DNS-challenge based certs because of a bug in their system, and they gave companies like mine only 24 hours to renew them before invalidating the old ones…

My employer had an EV cert for years on our primary domain. The C-suites, etc. thought it was important. Then one of our engineers who focuses on SEO demonstrated how the EV cert slowed down page loads enough that search engines like Google might take notice. Apparently EV certs trigger an additional lookup by the browser to confirm the extended validity.

Once the powers-that-be understood that the EV cert wasn’t offering any additional usefulness, and might be impacting our SEO performance (however small) they had us get rid of it and use a good old OV cert instead.

If you have ssh open to the world then it’s better to disable root logins entirely and also disable passwords, relying on ssh keys instead.

Port 22 is the default SSH port and it receives a TON of malicious traffic any time it’s open to the whole internet. 20 years ago I saw a newly installed server with a weak root password get infected by an IP address in China less than an hour after being connected to the open internet.

With all the bots out there these days it would probably take a lot less time if we ran the same experiment again.

My first reaction to this question was: hey, I was alive (not by much) when Neil Armstrong walked on the moon. I don’t remember anything about it though.

No, see, piracy is just you downloading movies for yourself. To be like OpenAI you need to download it, put it in a pretty package with a bow, then sell it over and over again. Only when it’s piracy for profit do you get to beg and plead for a pass.

My wife and I bring water bottles we can fill up after going through security, and packs of pedialyte powder to mix into it.

How about a Hunger Games variant where the worlds top 20 billionaires are pitted against each other?

My employer goes so far as to lock down what devices can connect to our network & VPN, and also locks down laptops so that removable media like USB thumb drives won’t work.

No way in hell I’d let them do things like that to my personal laptop.

Well OPSEC is the stated cause. Who knows how the person was initially identified and tracked. For all we know he was quickly identified through some sort of Tor backdoor that the feds have figured out, but they used that to watch for an unrelated OPSEC mistake they could take advantage of. That way the Tor backdoor remains protected.

Exactly. Tor was originally created so that people in repressive countries could access otherwise blocked content in a way it couldn’t be easily traced back to them.

It wasn’t designed to protect the illegal activities of people in first world countries that have teams of computer forensics experts at dozens of law enforcement agencies that have demonstrated experience in tracking down users of services like Tor, bitcoin, etc.

I’m willing to bet the vast majority of that money is changing hands among tech companies like Intel, AMD, nVidia, AWS, etc. Only a small percentage would go to salaries, etc. and I doubt those rates have changed much…

Worked in a small Unix team under a broader IT department at a university. The manager of our team was awesome in part because his attitude was “I deal with all the university politics so you can focus on your work”. Anybody who has worked at a large university knows what the politics can be like.

The VP of IT retired and the replacement was hired from an IT department at another university. The new VP’s overall policy was “We will do things this way because that’s how we did it at my old university”. Within about 6 weeks we had a round of “layoffs” that targeted our manager and one other manager that was also known to push back against the university politics. They were the only two people let go out of a department of roughly 100.

Within about a year of that happening every last member of our tight knit Unix team left for greener pastures.

I doubt it. The liability would be far too great. Ambulance chasing lawyers would salivate at the chance to represent the families of pedestrians struck and killed by buggy self driving cars. Those capitalists don’t want endless years of class action cases tying up their profits.

Not until a self driving car can safely handle all manner of edge cases thrown at it, and I don’t see that happening any time soon. The cars would need to be able to recognize situations that may not be explicitly programmed into it, and figure out a safe way to deal with it.

My wife and I just streamed a movie a few days ago. It had a ton of bloopers intermixed with the end credits.

My wife used to drive an electric Smart Car for her work. It had a range of 60 miles (less in the winter), and she called it a glorified golf cart. But it was perfect for the 20 or so miles she’d drive each day.

Oh there are definitely ways to circumvent many bot protections if you really want to work at it. Like a lot of web protection tools/systems, it’s largely about frustrating the attacker to the point that they give up and move on.

Having said that, I know Akamai can detect at least some instances where browsers are controlled as you suggested. My employer (which is an Akamai customer and why I know a bit about all this) uses tools from a company called Saucelabs for some automated testing. My understanding is that our QA teams can create tests that launch Chrome (or other browsers) and script their behavior to log into our website, navigate around, test different functionality, etc. I know that Akamai can recognize this traffic as potentially malicious because we have to configure the Akamai WAF to explicitly allow this traffic to our sites. I believe Akamai classifies this traffic as a “headless” Chrome impersonator bot.

When any browser, app, etc. makes an HTTP request, the request consists of a series of lines (headers) that define the details of the request, and what is expected in the response. For example:

GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

The thing is, many of these headers are optional, and there’s no requirement regarding their order. As a result, virtually every web browser, every programming framework, etc. sends different headers and/or orders them differently. So by looking at what headers are included in a request, the order of the headers, and in some cases the values of some headers, it’s possible to tell if a person is using Firefox or Chrome, even if you use a plug-in to spoof your User-Agent to look like you’re using Safari.

Then there’s what is known as TLS fingerprinting, which can also be used to help identify a browser/app/programming language. Since so many sites use/require HTTPS these days it provides another way to collect details of an end user. Before the HTTP request is sent, the client & server have to negotiate the encryption to use. Similar to the HTTP headers, there are a number of optional encryption protocols & ciphers that can be used. Once again, different browsers, etc. will offer different ciphers & in different orders. The TLS fingerprint for Googlebot is likely very different than the one for Firefox, or for the Java HTTP library or the Python requests package, etc.

On top of all this Akamai uses other knowledge & tricks to determine bots vs. humans, not all of which is public knowledge. One thing they know, for example, is the set of IP addresses that Google’s bots operate out of. (Google likely publishes it somewhere) So if they see a User-Agent identifying itself as Googlebot they know it’s fake if it didn’t come from one of Google’s IP’s. Akamai also occasionally injects JavaScript, cookies, etc. into a request to see how the client responds. Lots of bots don’t process JavaScript, or only support a subset of it. Some bots also ignore cookies, and others even modify cookies to try to trick servers.

It’s through a combination of all the above plus other sorts of analysis that Akamai doesn’t publicize that they can identify bot vs human traffic pretty reliably.

Exactly. The only truly effectively way I’ve ever found to block bots is to use a service like Akamai. They have an add-on called Bot Manager that identifies requests as bots in real time. They have a library of over 1000 known bots and can also identify unknown bots built on different frameworks, bots that impersonate well known bots like Googlebot, etc. This service is expensive, but effective…