As the CA/Browser forum said in their response to this, they feel automation is the key. Protocols like ACME do exist, but really only exist for web servers.

People forget that it's more than websites that exist on the internet that use PKI infrastructure. Your printer sitting on your desk -- that's got embedded certs. Have a phone? Yup, that has certs loaded into it as well to do encrypted phone calls. LDAP servers, directory servers, mail servers, API servers, game servers, etc. Hell, that IoT lightbulb has a cert it in, I bet (or you hope it does, if it exposes https). I know I do TLS encrypted between my phone system and my carrier -- it works well but when certs change, stuff breaks because that stuff is hyper-sensitive to MiTM attacks where you need to trust an individual cert for a period of time.

This is going to leave all those devices that aren't traditional apache/nginx/IIS web servers to have a few options:
  - Issue private, unsigned certs that have longer validity. Expect users to directly trust those certs (or instruct them to click through errors). This is a huge step backwards and teaches our users to ignore earning when things are wrong.
  - Issue certs from a private CA that allows you to control the validity. You then have to teach your users to import the root cert onto every device they plan to use (this is /really/ hard on mobile devices). This works until you need to hit those resources with a web browser, and Safari/Google start to block certs that have validity that is longer than 45 days (and we've seen this in the past when certs went from 3 years down to 1 year).
  - Hope that /every/ manufacture puts in cert and key rotation into all their products in the next two years. Even then, how do you validate all those certs for these smaller devices that aren't or shouldn't be publicly accessible on the internet.

Auto-detecting oncoming cars is already a feature in higher-end cars in the US. It's also highly inaccurate as designed (it will detect oncoming cars most of the time -- assuming there are no hills, ice, snow, rain, etc), and does not help with pedestrians, cyclists, motorcyclists and other road users.

I've got a co-worker who drives around with the high-beams on all the time. Their new Buick uses the front-facing sensors to determine if a car is coming or if they are following a car. It auto-drops them when it detects a car, so they so it as 'auto mode'.

It does not detect pedestrians, cyclists or any other road users. It detects other cars most of the time. They don't care -- they bought the feature.

In the Valley, drinking was normalized. Hell, even at the eBay/PayPal complex (which was one of the more straight-laced places in San Jose), beer taps turned on at 5pm and people would regularly grab a few and head back to their desks. At Adobe, it wasn't uncommon for all the managers to have bourbon or whisky at their desks. At Intel, there wasn't a ton of booze out there in the open, but all the engineers I knew in the early 2000's had at least two drinks at lunch before they came back to the office.

That's what this change is about -- you have to go through a ton of extra steps to run your own binaries now -- unless you turn off all the Gatekeeper stuff -- which re-appears after every update and upgrade -- OR you can get the developer account to get valid cert signing.

That 'ordinary user' would need to sign up, and pay for an apple developer account to get access to certs that are signed by apple. This is a yearly charge.

They would then be able to compile, and sign, anything they want.

Fun. How many times did you go over the speed limit. I'm talking 46 in a 45 zone or faster than 25 in a residential neighborhood? 1 over is breaking the law.
How many times do you roll a stop sign? Stopping means /completely/ stopped, not just slowed down.
How many times do you right-on-red without completely stopping? Block a cross walk? Run a yellow or red light (I know... it changed quick).

Studies show that cyclists break traffic laws much less than motorists do. It's just that the types of laws that motorists break are seen as normal. If you actually go below the speed limit you will be the significant outlier.

I kinda hate this thought. If you've ever used Photoshop for anything more than cropping images, the Gimp does not compare one bit. Lack of bit depth, spot color work, adjustment layers are non-fancy things that have been in Photoshop for 20+ years and are /still/ missing from Gimp.

Now, there are paid-for tools that are serious competitors for Photoshop -- like Afinity that are growing in popularity. And they don't require subscription to use either...

Yeah, except it's not the hotel's DHCP server that would need to be attacked -- it would have to be the place where your VPN tunnel terminates. The VPN server, in most implementations, hands out IP address (and other configuration data) via DHCP. The theory is that if the DHCP server is hijacked within your company's network that hosts the VPN server, that they could have some traffic (like www.amazon.com) NOT go through the VPN. This would also then require somebody on the untrusted network (your hotel network) to then sniff your packets to see the traffic -- if it was unencrypted.

The routes from your local DHCP server (hotel network) would be ignored in MOST vpn setups, besides the encrypted VPN traffic itself.

Paired with a poisoned DNS server and a shady SSL cert, you can MIM sites with still having the client think things are good.

Very few enterprise VPN servers use DHCP servers on the network (Cisco, Juniper, F5, PaloAlto, etc.) -- but rather use their own DHCP pools that they manage internally to hand out addresses and scopes. I believe Microsoft's uses the DHCP server from Active Directory, but I can't think of any of the larger VPN concentrators that do. This attack seems to be extremely nuanced.

By the way, there is a LOT of security professionals that still setup their VPN's so they only transport traffic that is destine to their inside or DMZ networks. They send out routes so that just their inside IPs get routed over the VPN. The running theory is that "bad traffic" will go out the public network and protect their inside network a bit more, and it also helps offload consumer traffic like youtube and netflix from going across their VPN. Most people have no idea that this is an option and assume that if they are on their corporate VPN they are completely protected.

But look at how /confident/ it is with the answers it gave! With that confidence you know it's a sure thing.

I mean... it's a good product and all, but can you integrate AI into it? Then it would check ALL the boxes.

Safety of drivers and passengers of vehicles has gone up. Deaths in those categories have gone down.

BUT the safety of everybody outside the vehicle has gone down. Deaths are up, injuries are up. Damage to vehicles, infrastructure, stuff along the side of the road and everything else has gone through the roof.

As we've made cars feel safer, they've become extremely dangerous for everybody but the driver. The driver will feel safe and will do more and risker driving.

Stringray and the SS7 protocol provide hooks in very different ways and different places.

As you mentioned the Stingray is essentially a MIM attack. Unfortunately, it's become much less useful recently as cell vendors are making their cells smaller and smaller and with a ton more available. Also, with VoLTE/5G it's become even less useful since these are all encrypted VoIP conversations anymore. You could still, in theory capture unencrypted IP traffic across the link, but there isn't a ton of that anymore. And in the last 5-10 years, you have to get closer and closer to your target to capture their data (and you better hope that their cell isn't talking to other towers, or it will certainly raise flags with the carrier that something is going on.) Rather than Stringray equipment, spooks have been using in-building DAS systems to capture the data. Within buildings a lot of companies (and public entities) have been installing antennas systems to provide cell service where there wasn't any. This means they can lower the protocol to older 3G or "4G" that still has the voice B channel for calls and capture calls that way. They can also make sure that the target's "real" cell service won't get connected either.

The issues with SS7 was that it trusted anybody connected to it. Back when it was only AT&T that owned the network within the United States and we didn't have LNP this wasn't as much of a problem because they could tightly control who interconnected with it. However, since they opened up their core network to CLECs and other RBOCs to directly participate in the network (including mobile carriers), they don't have that tight control. 1,000ft view, the protocol does all the control aspects of the phone network -- mostly setting up calls, doing special features with calls, clearing channels and billing records. The protocol itself allows for setting up calls with any caller-id or bill-to number (spoofing), for mobile carriers it allows anybody to "reside" a number -- meaning I could temporarily route calls or text messages to my node versus the ones that they actually are on, and a bunch more.. Re-routing calls or setting up are traceable (unlike Stingrays which were pretty much transparent man-in-the-middle), but they could be done from anywhere in the country -- as long as you had a connection to the network.