There's a difference between accelerating to a similar speed as the traffic you're joining and accelerating so that you wheel-spin past a single vehicle. It would take a bit of algorithm tuning to get it right, but I imagine that certain sections of road (especially junctions) require quick acceleration. There's also sections of road that you don't want to be accelerating ferociously e.g. before blind corners.

On average, drivers don't crash. Therefore the average speed must be reasonable for the road conditions, otherwise you'd get people having acrash on most journeys.

If you're going to be using "science", then a good first step would be investigating the correlation of accidents and speed. Speed by itself is not a reliable indicator of the recklessness of the driver.

I'd prefer more intelligent sensors/cameras that penalise aggressive acceleration (i.e. sudden rate of change of speed in close proximity of other road users) or can detect lack of awareness of the driver.

And also true (as far as we can tell).

As it's stateless UDP, there's not much of a connection to the proper server. All you need to do is send the appropriate source and destination ports and IP address and you're good. It would involve waiting for an outgoing request and then sending spoofed packets that look like they are a reply. The one with the right ports will be allowed through the firewall as it looks like a reply.

I'd always thought they were expensive, specialist devices, but it looks like you can get pci express cards for laptops quite cheaply. I'd imagine you'd want to position the aerial outside of a server room though.

Thanks for your translation, it's most helpful. I don't see why you need to seize control of a server to spoof a response as spoofing implies that you're faking the response so it looks like it's come from the respective server.

I believe this is made easier as NTPd sends from port 123 whereas openNTP uses a random port.

That's reassuring, but I wonder why Apple have rushed out this update. How many OSX users run a public NTP server?

Okay, not an open port, but if you request a time update wouldn't an attacker be able to respond with a spoofed malicious packet? By sending out a request, the (stateful) firewall will usually allow a response back. I'm not an expert, so I'd be interested to see if someone more knowledgeable could explain that in more detail.

Yes, but often the easiest way to set up a time server is to sync with a time server on the internet (e.g. ntp.pool org). As far as I can tell, a big reason for people to use NTP is that they don't have a reliable atomic clock of their own, so they sync with other people who do.

I hadn't spotted the "restrict ... noquery" mitigation (which luckily I already had in place), but wouldn't servers still be susceptible to spoofed packets from one of the trusted servers?

Really, what's one of those?

If you close all your NTP ports you're not going to be able to sync with a time source on the internet. Once you allow responses to your NTP queries, then you can be spoofed and compromised.

This is a major bug in NTPd, so if you're using it on Linux, you'll want to patch it too (or switch to openNTP which isn't affected). The big problem is that it can be exploited with a single (specially crafted) UDP packet, so it's easy for malicious actors to probe lots of machines with very little overhead.

This is a major bug in NTPd, so if you're using it on Linux, you'll want to patch it too (or switch to openNTP which isn't affected). The big problem is that it can be exploited with a single (specially crafted) UDP packet, so it's easy for malicious actors to probe lots of machines with very little overhead.