As somebody who has spent decades on boats I find this news particularly interesting because of the apparent suddenness and violence of the storm. I’m used to hurricanes that take days or weeks to form and move into the area, not waterspouts powerful enough to capsize a 180 foot long, 400+ gross ton super yacht with virtually no warning… It’s virtually unheard of.
There’s security camera footage that shows the yacht anchored in relatively calm water. Within about 3 minutes it turns into an incredibly violent storm. Most of the yacht is obscured by the storm but you can still see the mast light through most of it. Then suddenly the mast light is no longer there…
Certainly nowhere near 16 minutes.
I wonder how effective AC would be in many cases… I regularly see delivery vans from Amazon, UPS, USPS, etc. driving around with their doors open. In some cases it seems to be all about speeding up deliveries even by a few seconds, especially for Amazon drivers.
I suppose if they took breaks they could close up the truck and cool down, but that assumes they would have time for it…
In cases like this also contact the US Postal Inspection Service. They won’t take kindly to stolen mail, especially if it’s stolen right out of a US Post Office.
If it’s US Mail then contact the US Postal Inspection Service. They’re federal law enforcement specifically for the USPS, and they don’t fuck around.
More importantly, a recall is a legal process initiated by NHTSA that covers any sort of safety related defect. When they issue a recall there are very specific steps the manufacturers are legally mandated to perform.
“Recall” is a legal term defined by the National Highway Traffic Safety Administration. It means an issue was reported to them, they investigated it and determined that there is an unreasonable safety risk, or minimal safety standards have not been met. As part of that investigation they also work with the manufacturer to identify the range of vehicles involved. NHTSA then issues the formal recall notice, which legally requires the manufacturer to address the issue by notifying the impacted owners and either repairing or replacing the defect, or in extreme cases issuing a refund or buying back the vehicle. Again, this is all a legal process that NHTSA and the manufacturer must follow, and it makes no distinction between software and other components.
I’ve actually had a car with a rather significant software issue that I had to go to a dealer to fix. Long story short, the battery would die every few weeks and leave me needing a jump start. I replaced the battery twice and even the brand new batteries would die quite often. I eventually found two recall notices on my own that perfectly described the symptoms I was seeing. The recalls documented bugs in the firmware in the ECU that would randomly disable the alternator, preventing the battery from charging. I had to bring the car to a dealer to have them update the ECU firmware since that’s not something you can do yourself.
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.
deleted by creator
Well that’s the thing about edge cases - by definition they haven’t been explicitly taken into account by the programming in these cars. It is literally impossible to define them all, program responses for them, and test those situations in real-world situations. For a self driving car to handle real-world edge cases it needs to be able to identify when one is happening and very quickly determine a safe response to it.
These cars may already be safer than drunk/drowsy drivers in optimal situations, but even a drowsy driver will likely respond safely if they encounter an unusual situation that they’ve never seen before. At the very least they’d likely slow down or stop until they can assess the situation and figure out to proceed. Self driving cars also need to be able to recognize completely new/unexpected situations and figure out how to proceed safely. I don’t think they will be able to do that without some level of human intervention until true AI exists, and we’re still many decades away from that.
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.
Couldn’t agree more. If all driving was easily predictable then “just better than humans” would be reasonable. But in my decades of driving I’ve encountered so many edge cases I’ve had to deal with that I seriously doubt true self driving will exist until we developed true AI (not just the LLM stuff that’s currently all the rage) that can react to events that aren’t pre-programmed.
Just a few examples of things I’ve encountered:
Back in the late 90’s I worked for an internet search company, long before Google was a thing. We would regularly physically drive a dozen SCSI drives from a RAID array between two datacenters about 20 miles apart.
My grandparents had a house on Cape Cod that was right on the water. When I was maybe 8 to 10 years old I could stand on the beach and rest my elbows on the top of the seawall that separated the beach from the yard in front of the house.
20 years later when the house was sold so much sand had eroded from the beach that, as an adult, I couldn’t reach the top of the seawall while standing in the same place. So over the span of a couple decades roughly 5 vertical feet of beach had eroded away.
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…
Not to worry. I’m sure the Boeing executives golden parachutes will save them.