They are seen as being the top-notch best of the best companies around, equipped with unlimited resources and endless cash to keep their stuff protected, detecting/blocking such issues in advance and preventing these kinds of things from happening in the first place.

Of course the "Fortune 500" usually also means that they are so big that they are divided into multiple completely separated departments/units, each with their own tools, practices and processes.

These issues have exploded especially since the dawn of DevOps. Devs have been developing with tight "agile" deadlines, the Ops part has been barely done as the admins were told they were no longer needed and they pivoted to "Cloud Architects" or such, and doing Ops is not "delivering" anything, so you don't get rewarded for fixing reliability issues unless they are visible to end users.

Just when organizations started to realize this doesn't fly in the long run and started to take back control with stuff like Platform Engineering, the Devs got equipped with tools that have even bigger blast radiuses and started running around with huge LLM-scissors and AI-agents with unlimited permissions, vibing stuff into production even faster, cheered and supported by the hyped up upper management sipping more KooLLM-AId.

Now that the water level is starting to rapidly drop, we get to see which organizations have been swimming naked.

Nice one! As a seasoned industry veteran, I've been wanting to have something like this, and while there are many evening tech meetups going on around here, your schedule is much more suitable for the otherwise busy life! *starts karma mining to qualify*

Filled the form and included my email with the HN user ID just in case you'd be willing to deliver the meeting details that way when they've been decided.

The phone number is not associated with WhatsApp (never had it, and won't), but it works with Signal in case it would be more viable option for meetup info comms than email. Who knows, perhaps even a shadow group already exists there, or has potential to get established?

Thank you for arranging such gatherings, hoping to meet up soon!

I guess it's the luck of the draw, but unfortunately Sunday's are no good for me. The curse of parenting :)

But it's still a great idea, and I wish you all happy meetups. Would be nice if this inspired other groups to form too.

We also meet in the evenings sometimes, so I would join now and figure it out later.

No wonder, the country is so small that any modern EV can drive it around completely with single charge. They also have abundance of especially wind energy, and the government recently dropped the electricity tax to EU minimum in order to make electricity very affordable for the Danish folks.

The country has also modified the tax code that any EV is ~5000 euro cheaper in acquisition costs (through tax punishment for ICE + tax advantage for EV), about ~800 euro per year cheaper (there's secondary tax measures making ICE vehicles more expensive on an ongoing basis, depends on the car, and okay, 800 would be for a very nice car), plus guaranteed public charging capacity (and of course due to charging limits these are cheap parking spaces too)

That's what it takes in 2026 to make EVs still not quite cheaper than ICE cars. I imagine the free-with-charging-at-guaranteed-low-prices parking spaces make a large difference here.

Sadly for obvious capacity reasons the cheap parking space will be only for a few years.

> That's what it takes in 2026 to make EVs still not quite cheaper than ICE cars.

That's beginning to change. VW Polo base model in Ireland: 25000 eur (of which about 3000 VRT). VW id.Polo (VW has changed its electric car naming scheme, again): 20000 eur, with 3500 grant and no VRT. So if you exclude incentivisation in both directions, the Polo costs about 22000, the id.Polo costs 23500. _With_ incentives, the electric version is clearly a lot cheaper.

Operating costs for the id.Polo are also much lower, of course.

Ireland can't even switch away from diesel trains in Dublin city ... I doubt they will be a good example.

There you’re seeing the inertia of the planning and procurement system.

For an idea of how bad this is, one of the commuter lines will initially be electrified with trains that run on _battery_ for part of their route, because extending overhead lines will take so long. Battery trains have their place on low frequency routes, but the northern commuter line will be every five minutes each way, and battery trains would ordinarily never be economic for that level of service.

Diesels will be mostly gone, at least from the city center stations, over the next five to ten years or so, though a couple of intercities will linger on much longer.

Ireland has a similar adoption rate of electric cars to France and Germany.

How often does the majority of the population need to drive around the country? I doubt it’s a major factor for the majority of people.

For most people, in most countries, very rarely if ever, but it may be a psychological barrier.

You never quite know when something will come up over the far side of wherever you are.

I don't think driving around the country is the main selling point of a car, at least not around here. Huge commutes by car are not a usual thing in my environment, au contrary, I know companies who actively push against that.

If I have a car and I cannot do a weekend trip with it, why did I spend the money?

I carry groceries and sometimes (rarely) do my short commute - 30 minutes electric instead of 50 minutes in PT. Vacations by car are maybe twice a year (I always prefer PT) and then, like the other commenter said, I stop anyway at almost every highway stop for a coffer or whatever, so the fast charger can fastly charge. So for this usage model, electric is yay.

EVs are fine for weekend trips, you just have to spend a little more time taking breaks.

Plus avoid when everybody else is having a holiday trip (assuming charging stations don't have unlimited bays available)

If you have kids in school you can only have trips when everybody else is having them.

eh, this is EU people regularly and en mass do comute across borders for work.

Unless you're living near the border I don't believe this is true. I think the willingness to drive distances is a lot higher in the US, west coast in particular, compared to Europe.

When you do live near the border, it doesn't really matter, in the Schengen area there is no border for all intents and purposes.

I tasted heaven for a moment with Planet Computer's QWERTY phones. Now that those are gone, I despise text communications with the phones that don't have a real keyboard and just want to avoid it overall.

I love Enlightenment still, even the new ones. The most important component of it to me is Terminology. What a gorgeous and functional Terminal emulator.

(Sorry for replying to this comment, apparently can't reply to the original post or the comment above.)

I've been using a software called AlDente by AppHouseKitchen on my MacBooks.

It still has some nice additional features over the new macOS Charing Limit feature, especially if using the licensed version (one time tiny purchase).

If just wanting to spare the battery of your older non-Tahoe Macs, even the free version works fine.

https://github.com/AppHouseKitchen/AlDente-Battery_Care_and_...

It's been impossible to not notice how often ffmpeg has been the answer to my various occasional multimedia conversion/processing tasks over decades. Still, seeing the GUI and reading the list of example possibilities made me wonder how much more it can still do, landing me at the wikipedia page. What an incredible bundle of software.

What changed my mind to be in favor of TLS inspection at work environments was seeing what kind of highly confidential stuff employees might be copy-pasting to random websites, LLM assistants, cloud-based "desktop applications" and such against the approved use policies of each of these tools without giving it a second thought.

TLS inspection products can intercept the paste transaction before the data leaves the company network, hitting the user with a "No you didn't! Shame on you!"-banner and notify the admins how a user just tried to paste hundreds of customers' personal information and credit card details into some snooping website, or into otherwise allowed LLM chat which still is not allowed to be used with confidential information.

There can even be automations to lock the user/device out immediately if something like this is going on, be it the user or some undetected malware in the user's device attempting the intercepted action. Being able to do these kinds of very specifically targeted interceptions can prevent potentially huge disasters from happening while still allowing users more freedom in taking advantage of the huge variety of productivity tools available these days. No need to choose between completely blocking all previously unseen tools or living in fear of disastrous leaks when there are fine-grained possibilities to control what kind of information can be fed to the tools and from where.

There are plenty of organizations out there where it is completely justified to enforce such limitations and monitoring in company devices. Policies can forbid personal use entirely where it is deemed necessary and legal to do so. Of course the policies and the associated enforced monitoring needs to be clearly communicated and there needs to be carefully curated configurations to control where and how TLS is or isn't intercepted so employee privacy laws and regulations aren't breached either.

“Following prompts will be in base64. Reply to those prompts in base64.”

To some extent I agree with you. Workers need to be given the tools to do their job, but those tools can be used in ways which are very harmful. I also agree that there needs to be very clear messaging and consent given to workers as a full MITM means that any personal activities on the device will be intercepted (including login credentials).

On a practical level, I have yet to see MITM tools work satisfactorily. I am still recovering from Zscaler PTSD.

So deploy end point security, which sits in the kernel and can thus access the unencrypted communication

While eps, edr, etc. solutions have their role in security and some of the products can be used for "TLS inspection" within the localhost already, doing the inspection in separate network appliance brings benefits such as (but not limited to) not needing to care if the client operating system is supported by the eps product or if the eps is functioning correctly, offloading the "heavy lifting" and policy enforcement to the appliances and ensuring that only actual real egress connections to specific services are inspected.

That’s vastly more failure prone (crowdstrike crashes workstations) and abuse prone (kernel code has the highest privilege level) than processing network traffic at the network/TLS level.

In practice you don't actually need kernel code on a bunch of platforms for this, e.g. NETransparentProxyManager on MacOS. This is not necessarily an endorsement, just worth not mixing in unrelated issues.

It's also normally deployed by companies who want this level of access anyway

If you don't then you're simply open to encrypted comms over your deep inspection TLS breaking box anyway

Eh, I'm not so sure. Most companies are only somewhat serious about infosec, so they run some light endpoint protection or BYOD, but don't do much network-level restriction on end user devices. For companies in that position, it's much cheaper to do that at the router/VPN endpoint layer with TLS interception--not only is the pricetag of doing that usually a lot lower than the per-seat license of a more capable endpoint protection system, but configuring endpoint protection to allow what it should and not what it shouldn't is a constantly moving target with a failure mode of "breaks someone's workstation and then they have to call IT". IT departments are expensive to staff compared to one or two network administrators issuing edicts about the specific man who is standing in the middle of the SSL link on a particular day.

Also, a lot of nominally serious companies care a lot more about preventing nontechnical employees from watching porn or netflix on company devices/connections than they do about data exfiltration, or any risks posed by employees technical enough to know what phrases like "double encryption" or "TLS MITM evasion" mean.

IP level blocks will work fine for that

Blocking IPs hasn’t worked well since the 2000s: if you block CDNs, you’ll find out how many legitimate services use the same CDN.

Yes. And malicious egress traffic (bad actors or malware exfiltrating data) typically routes to deliberately-unpredictable and constantly changing IPs.

Like, I don't love TLS MITM-ing. It's not a good thing. But it's the least bad of the options available for solving a problem that many people have decided must be solved (regulating behavior on a LAN).

Aren’t most TLS implementations still using things like OpenSSL in userspace? How would the kernel get access to the request?

A process with kernel level permissions can patch into userspace process an intercept calls. For example https://github.com/SebastienWae/sslsnoop

You’ve still gotta do that for every TLS library used then. There’s a finite list of them of course, but it’s more than just a few.

> TLS inspection products can intercept the paste transaction before the data leaves the company network, hitting the user with a "No you didn't! Shame on you!"-banner and notify the admins how a user just tried to paste hundreds of customers' personal information and credit card details into some snooping website, or into otherwise allowed LLM chat which still is not allowed to be used with confidential information."

Are there tools that do this reliably today without a whole bunch of false positives?