Hacker News Reader

Comment by flumpcakes | Hacker News Reader

I work in security/systems/ops/etc. and fundamentally disagree with this premise. I understand the author is saying "it's not that easy" and I agree completely with that, but I don't agree that it means you're doing your job well.

Unfortunately the vast majority of people do their jobs poorly. The entire industry is set-up to support people doing their job poorly and to make doing your job well hard.

If I deploy digital signage the only network access it should have is whitelisted to my servers' IP addresses and it should only accept updates that are signed and connections that have been established with certificate pinning.

This makes it nearly impossible for a remote attacker to mess with it. Look at the security industry that has exploded from the rise of IoT. There's signage out there (replace with any other IoT/SCADA/deployed device) with open ports and default passwords, I guarantee it.

IoT is just a computer, but it's also a computer that you neglect even more than the servers/virtual machines you're already running poorly.

People don't want to accept this, or even might be affronted by this.

There are some places doing things well - but it's the vast minorities of companies out there, because you are not incentivised to do things well.

"Best practises" or following instructions from vendors does not mean you are doing things well. It means you are doing just enough that a vendor can be bothered to support. Which in a lot of cases is unfettered network access.

View on HN

A sign connected to the internet but with IP whitelists and cryptographic checks is still CONNECTED TO THE INTERNET. Yeah, it's way safer than the same sign with ports open to the world and no authentication, but you can't treat it as "not connected to the internet." You still have to worry about networking bugs, cryptographic vulnerabilities, configuration errors, and other issues that can allow remote attackers to exploit the system. If you want to make the point, you have to give an example of something that's literally not connected to the internet, not one that's simply locked down better.

The number of people who are willing and able to build their own disconnected network is vanishingly small which is the author's point. When deploying "edge" computing like signage which demands remote administration telling your customers anything other than "get it connected to the internet and we'll handle it from there" isn't going to go over well.

"Sorry you can't deploy our signs because we haven't deployed our custom LoRa towers in your area" is just gonna get laughs.

That’s not necessarily true. Otherwise Pricer wouldn’t have a viable business.

For IoT in particular, you hit a crossroads where the embedded devs haven't really dealt with advanced security concepts so you kinda have to micromange the implementation. And, in small teams it's hard to justify the overhead of managing x509 certs and all the processes that come along with it. Just my personal experience.

Yeah you know, just roll out our MVP, let's see where the business goes with it, and then we'll fix it. Whaat? Budget of fixing it is 2x of the product itself? Hm. Let's have meetings over meetings to postpone the decision until the next one, indefinitely - we cannot really make the decision not to do it of course.

> And, in small teams it's hard to justify the overhead of managing x509 certs and all the processes that come along with it. Just my personal experience.

If you're using (say) Python in your client code, call SSLSocket.getpeercert() and check if your company's domain is in the subjectAltName:

* https://docs.python.org/3/library/ssl.html#ssl.SSLSocket.get...

You can ensure it is a valid cert from a valid public CA (like Let's Encrypt) instead of doing your own private CA (which you would specify with SSLContext.load_verify_locations()).

I think parent refers to the infrastructure that is required to (automatically?) sign certificates by an internal CA and managing the distribution of those certificates. I don't think verification is the issue.

This is correct. You have to consider every step from when the device is manufactured to when something goes catastrophically wrong in the field. All the internal documentation and tools so Joe from support can help customers and Bob in manufacturing can provision devices on his own all while maintaining controls around that process so nothing is getting leaked or abused.

Surely white lists and certificate pinning are not advanced security concepts?

Yes, they are.

Perhaps not in a practical or educational sense but in the real world, of people with non-cryptographic or security related jobs, a certificate is a PITA that goes beyond the functional requirements.

I have seen many insecure building automation systems that are maintained by reclassified HVAC technicians. The movies about hackers taking over an elevator are entirely accurate.

The hassles of cert pinning, etc. should not be laid at the feet of the customer/integrator/whatever. Regardless of whether that person is an HVAC tech who learned about serial ports & busybox yesterday or is a seasoned expert with Ghidra & Wireshark & binwalk.

Companies are being incredibly lazy (at our expense), and the author states this obliquely:

>virtually the entire software landscape has been designed with the assumption of internet connectivity

The issue is the alternative does not scale.

It's not that companies are being lazy at our expense; it's that nobody wants to pick up the bill. If you write something to work against an online system, the fact it is online implies it adheres to some standard that you can work with, so solving the problem for one online client creates an artifact that is likely applicable to many clients.

Air-gapped systems drift. They get bespoke. They get very out of date. So you have the two practical problems of labor: (a) the product created solves the problem here, today, but nobody else benefits from repurposing that solution and (b) the developer isn't gaining as many transferrable skills for the next gig, and they know it, and so the developers who are willing to do the air-gapped work are harder to find and more expensive.

(I believe this is also the reason you see air-gap a lot more often in government security and banks: they can afford to retain talent past the current project with the certitude there will be more projects in the future).

The issue is the alternative does not scale.

That's a feature, not a bug.

Almost the entire downfall of the modern tech industry can be attributed to two things: greed, and the fetishization of "scale."

Not everything has to scale. Not everything should scale. Scale is too often used as an excuse to pinch pennies. If you business model only works at massive scale, then your business model might be broken. (Not always, but more often than most people think.)

how isn't b) a contradiction? You're stating the demand is there, but the developer is not seeing it? Did you mean to say the opportunity to remain in the same kind of gig is not as profitable/career advancing?

Basically. I mean the demand is there, but the developer recognizes a small island of architecture is a risk for long-term skill dev and wants compensation for that risk. For a developer to take the kind of gig that requires working bespoke air-gapped tech that sees few updates, they're going to want to be paid X+N over the median salary X (or have some guarantee of / expectation of job security).

It's a sucker's play to take the gig at price X, work on it for a year or two, and then get tossed to the curb when the project wraps with the only skills growth to show for it a combination of those ineffable fundamentals ("everything Turing-complete is fundamentally equivalent") that are useful forever (but can be picked up on any job) and some knowledge of Bob's House of Air-Gapped Machine's circa-1997 Flash install that their in-house kiosk infrastructure ran on.

There are jobs that'll pay for that Flash experience, but they're a lot harder to find than if Bob's House had been using some modern web architecture and you'd picked up, say, AWS experience.

Hey, that's the problem with global homogenous culture too!

Embedded devs can come from a variety of backgrounds (e.g. Electrical engineering) that don't necessarily concern themselves with software security. They're not dumb, it just isn't something they (typically) are knowledgeable in.

Then they need to learn it. Otherwise they’re being unprofessional and bad at their job.

They were hired by a company which is bad at its job of delivering secure or securable products. The products were purchased by someone bad at their job of selecting secure products. They were deployed by someone who was told that having the signs working ASAP is more important than anything else, so the management is bad at their job of securing the company.

But I won't say that the designing engineer was bad at their job, I would say that the product manager was bad at their job... but probably got promoted, because the company made a bigger profit and delivered faster because security didn't get any attention.

And that's why we need regulation, because "this product is secure" is not easily and cheaply verifiable and carries no penalties for being incorrect. The market can't tell, so everything is a lemon.

Sounds like not taking responsibility to me.

And don’t get me wrong: I’ve had managers that made it impossible to do the actual development job well. But it’s still my responsibility to do my job well so I escalated that. Most times I caused changes to improve things. If not I quit the job.

Personal accountability doesn’t just evaporate when someone else passes on bad orders. It’s not a fun position to be in but I think if engineers in general actually take responsibility for their own work, and confront management if that’s the source of issues, then that would improve things.

If you let yourself be pushed around into doing subpar work for deadlines you’re just signalling that it’s ok.

The makers of PC BIOSes are arguably the firmware developers who are closest to being normal PC programmers. They've been at it for 40+ years, and they have long provided network-connected features like network boot and remote management.

And yet over 200 motherboards and laptops have their secure boot root of trust key set to a log-ago-leaked example key from a development kit, named "DO NOT TRUST - AMI Test PK" [1]

The firmware industry at large just ain't good at this stuff.

(Of course from the perspective of the firmware industry, they can make a non-internet-connected heating timer or a washing machine control board that will work fine and reliably with no software updates, for 25+ years - while us PC software cowboys make software so bad crashes are just a fact of life, and bug fix/security updates are a daily occurrence. So the firmware industry isn't all bad - only when they start putting things onto the internet.)

[1] https://news.ycombinator.com/item?id=41071708

Well, they used be able to do that. They seem to be starting to assume connectivity and getting as sloppy as everybody else at basic functionality. I have a new Bosch cooktop that has WiFi and has downloaded at least one software update. The accompanying oven (also Bosch) had a timer that wouldn’t count down past 1:01, but doesn’t have WiFi, so it got its update by a tech coming out and replacing the entire controller board.

BTW, I looked at the board and noted that Bosch doesn’t even make the controller. They get it from Diehl Controls, an OEM who only makes appliance controllers.

OK, that's fine. Not everyone has to know everything.

So why aren't their employers investing in educating their devs & PMs about security? (rhetorical - we all know why)

Sure, for “small teams”. Does that apply to the companies with huge impact from this issue? Is Delta Airlines IT run by a small team? I hope not.

> I understand the author is saying "it's not that easy" and I agree completely with that, but I don't agree that it means you're doing your job well.

Could you elaborate what you mean by this? It seems to me that your comment just highlights another set of problems that should (in theory) motivate people to think more clearly about the ways their system communicates with the internet.

I don't see where you disagree with the blog author. Or are you saying that it's fundamentally impossible to improve security in internet-connected systems because people are not equipped to do so?

There's no reason for digital signage inside an airport to be connected to the internet (or running enterprise security software either). The author seemingly doesn't agree with this. Hospital computers should not be connected to the internet. If you are receiving real-time updates directly from a vendor, you are connected to the internet.

Ideally updates should come from a central source internally to the organisation that has been vetted and approved by the organisation itself. Clearly CrowdStrike knows this and that's why they offer N, N-1, N-2 updates for their falcon sensor.

It's easier to remote into a box and just pull updates from the internet though.

Granted I have not had dozens of jobs, but the only place I have worked where security was treated as the first class issue that it is, (and this type of CrowdStrike incident probably wouldn't have happened), is at one of the largest financial services companies in the world. And it did not hamper development, it actually improved it because you couldn't make stupid mistakes like relying on externally hosted CDN content for your backend app. But for people that don't do their job well, it's a pain. "Hey why doesn't my docker image build on a prod machine, why can't I download from docker hub?"

Just to add to this: Apart from the security aspect of hosting your software dependencies internally, it also gives you the added benefit of better availability and performance.

As you mentioned in your other comment however, this presumes a certain mindset in people where they are willing to plan upfront and are mindful of the dependencies their software needs. As you say, just pulling whatever from Docker hub is certainly easier.

Internally hosted repositories also allow you to pull and install updates at your own pace, possibly days after they have been released upstream. So if a patch is borked you won't be affected.

I hate to be that guy but 'back in my day', that was called "testing/production" deployments.

I don't really think you're speaking from a spot that's actually considered the requirements of the system.

Ex - you say this:

> Hospital computers should not be connected to the internet.

But then you immediately jump onwards, as though what you've said is obvious common sense - but I don't think it is.

Can you explain to me why you believe hospital computers shouldn't be connected to the internet, and then discuss and weigh the downsides of NOT connecting them?

Because there I think that comment exposes the exact mindset that the author was discussing... no obvious appreciation or understanding of the situation, just an ill-informed off-the-cuff remark.

Can you tell me how you plan to implement cross facility dosage tracking for patients?

Can you let me know how you're going to send CT scans or x-rays to correct expert?

Can you tell me how that patient's records are going to be updated, how billing is going to be generated, or how their personal doctor is going to be notified of their condition?

I can think of a LOT of reasons that hospital computers really should be connected to a network. Maybe not every computer, maybe not every network, but even that distinction appears to be far beyond the thought you put into it before immediately saying "Hospital computers should be connected to the internet".

You're basically making the author's point for him here.

The answer is simple: security. Attacker needs a way into the machine to control it. Granted, there are some obscure vectors of attack that don't need network connectivity (Stuxnet), however the game becomes much harder for the attacker when they have no direct connection to the target system.

Many countries solve this by having a separate network for hospitals, but it is not the only way.

In general, it is a trade-off between security and convenience. Yes, you can't send an e-mail without an Internet connection (well... not easily). But do you need to? From the computer that controls the MRI machine? Or is it just easier to say "we need Internet because updates"?

>you can't send an e-mail without an Internet connection

Of course you can.

To an external recepient? And you misquoted me by removing end of the sentence in parenthesis.

Of course. You send your email to an internal MTA that relays it (it likely has internet access). Segregation of access from terminals is a good thing, why would you want the terminal to be able to relay to an internet MTA itself?

> I can think of a LOT of reasons that hospital computers really should be connected to a network.

Connected to network ≠ connected to Internet.

There's only one other network that connects all healthcare providers, POTS. Which is why fax was/is popular in the healthcare space for the longest time.

If you're suggesting that the hundreds of thousands of healthcare providers just in the US all get together and lease some dark fiber -- there's zero chance that happens.

Besides, doctors routinely use resources on the public internet.

> If you're suggesting that the hundreds of thousands of healthcare providers just in the US all get together and lease some dark fiber -- there's zero chance that happens.

I am suggesting that not all computers in a hospital need to have an Internet-accessible connection.

Nor even all applications on a PC need to be Internet-accessible: if you're using Windows you can have an application icon that does not launch a program locally, but rather initiates an RDP session to a terminal server (TS) and runs the program there, while the app window is displayed locally (like X11 forwarding). The (TS) server is dual-homed so the app that runs there can (e.g.) connect to patient records network, but the local PC that is just being used as a display is not on that sensitive network.

Ah, well, this is already done in many places. It doesn't prevent malware from spreading, though. The latest malware is good at moving horizontally.

For all practical purposes, yes it does. Unless you are expecting hospitals and doctor's offices everywhere to develop their own parallel internet-like network. Which seems a bit unreasonable to expect of everyone.

Certainly it's doable: other commenters point out that Sweden and Poland have systems like this. But they are also relatively small countries, and presumably their governments have decided to foot the bill for most or all of it. The idea of the US doing something like that is unfortunately laughable, and you can be sure healthcare institutions aren't going to pay for it.

> Unless you are expecting hospitals and doctor's offices everywhere to develop their own parallel internet-like network.

I am expecting (health) IT staff to make an assessment on whether a system needs to (a) have Internet access at all, or (b) have Internet access perhaps through a filter/proxy.

There are entire classes of devices that should not / do not need to be able to reach www.google.com or 1.1.1.1. While my DC HVAC & PDU and IPMI networks have network connectivity, but they do not have Internet connectivity.

> You're basically making the author's point for him here.

And this is were I fundamentally disagree with the author. Nothing you've listed requires access to the internet - it requires access to a network.

It's a lot easier to just deploy everything and set the firewall to any-any and go home because it's working.

Like the author says, it's hard and difficult to find the right level, but to scoff at the simplest of advice of "it shouldn't be on the internet" is giving up.

> it's hard and difficult to find the right level

There are some pretty solid documentation on this and has been for some time, the knowledge simply has been lost or discarded because this kind of knowledge was considered 'arcane' or 'restrictive'.

There were times when infrastructure had devel/testing/production environments with staged rollouts and deployment.

Production had only only the minimal access, with admin config routable only to a private network, hidden behind the frontend cluster. Things were hard for admins and hackers alike.

There was at one point gated networks and the idea of militarized and demilitarized zones, router level firewalls, outgoing connection limiting. Centralized logging (nah, don't do that, just run your apps on a POD and forget your security, forensic recover of your app is dead by the next deployment (probably twice over today) already) and many many more things.

We bought the newthink of 'web security' as how we should build our infra as the the true way. When we see it fall apart on a blue friday afternoon do we look back to see the bigger picture ? No, we can't take responsibility for the weakness because any suggestion of personal responsibility that requires work is out of the question.

> And this is were I fundamentally disagree with the author. Nothing you've listed requires access to the internet - it requires access to a network.

Ok - now what? I don't understand the disagreement you seem to think you have.

That network inevitably requires a connection to the outside world or those exact same features I listed above stop working. So you're just shifting blame without an answer...

So continue with your path - now I have an X-Ray machine that's connected to a network. The router on that network still has to connect to the internet to facilitate functional use of the machine, so let's assume crowdstrike is running there - tell me how your advice of "Don't connect it to the internet" is meaningful here?

I have an expert radiologist who I want to confer with on my patients x-ray, he's in a different state - what is your advice? How is my problem solved with a banal "Just don't connect it!"?

Many countries have dedicated network for medical services.

If you don't you could use dark fibre, MPLS, etc.

Connecting to an network should not automatically get you routable access to the internet. A lot of headaches from cyber attacks would go away with this was the principle. But for a lot of people connecting to the "network" means unfettered "Internet" connectivity.

I've worked at places that have used dark fibre and MPLS and had no security problems, as that's not an easy attack vector. Moving to 'SDN WAN' means now sites are connected to the _Internet_ and a simple DDOS can take your branch down.

This may or may not be important to you, but the general advice of keeping off the Internet as much as possible unless you need it is good advice (and a vendor not offering central deployment of updates is a pretty poor excuse).

Most of your questions can be answered with these two weird old tricks: site-to-site VPNs && VLANs

Why has everyone seemingly discarded these ideas or forgotten? Yes, it is a pain to manage. Industry could reduce this pain, but investing in good security isn't profitable.

Blame the profit incentive. Blame the VCs (especially the people who own this website)

* Because they don't really work. It's better to assume the network is adversarial and work from there than to separate the world into the trustworthy network and untrustworthy network.

* It's much much easier to secure a network when you completely disallow client-to-client communication and block all communication to clients not initiated by them.

* Trusting the client that attackers can physically access is a recipe for disaster.

* Because VPNs are just an application on the internet.

> * It's much much easier to secure a network when you completely disallow client-to-client communication and block all communication to clients not initiated by them.

VPNs and VLANs are a technology that allow this. I think 'Zero Trust Architecture' wonks have done a disservice to industry. If your 'zero trust' app has a bug then your device is exposed (probably) directly to the internet, naked.

If you layer your security - starting with the bare minimum of VLANs, VPNs, network segregation, etc. then you can layer on top zero trust technologies.

What ends up happening is that people build their own pseudo-VPN with user space applications that network together a bunch of machines existing over the internet, potentially exposing dozens of new internal networks to malware vectors.

> Hospital computers should not be connected to the internet.

But then how will doctors google the patients' symptoms?

If your answer is "they should already know all that is required to do their job without looking it up online", then consider whether you hold yourself to the same standard. I don't.

It is hard to make assumptions about what parent means by that statement, given that there are degrees in which a system can be "connected to the internet". For example, every request coming in or going out, as well as SSH access, could go through a proxy. I would still call that being "connected to the internet", but it's different from giving your server a public IP address.

They could have designated internet connected computers and other computers for admin tasks and processing x-rays etc.

Having the hospital admin and some machines connected outwards seems like a recipe for killing patients.

If the admin computers aren't connected to the internet, how do patients interact with the administrative staff, for things like appointments, referrals, etc.? If the x-ray processing isn't connected to the internet, how do the x-rays & the radiologist's evaluation end up in the patient's record, or in a place where the patient can download their imaging results?

This information (looking up symptoms) would be better served by a curated internal wiki that all practitioners have access to. Not google.

What about medical reference service like uptodate.com

Medical care is so bad now I have had the doctors and nurse practitioners look up webmd while I’m in the room with them.

Doctors and nurses have always had large reference tomes that they refered to.

List of medication side effects, dosing guidelines and so forth have been common throughout the industry almost since it's very inception. Indeed, there are books going back thousands of years across multiple cultures around the world that are just referenced guides for medical practitioners.

doctor: heart arythmia

google ai: remove heart

doctor: ok lets schedule the operation!

Mobile device, second network, vlan etc. Lots of options.

> Hospital computers should not be connected to the internet.

Scheduling an urgent care appointment is connected to my account at the hospital network. When I step into the hospital and get tests done, everything is automatically uploaded to a web portal where I can view it and doctors can easily forward my test results to other facilities. Lot of the imaging work is actually done at third party facilities but they still show up in my medical records , presumably having been forwarded.

When my appointment begins my doctor can look up any comments I left when scheduling the appointment so she knows why I'm there.

Is it possible all the different buildings and facilities that are part of the hospital Network I belong to which extends across multiple counties across my state could all be running on their own private isolated network that is air gapped with medical records manually transferred over to the web portal via sneaker net?

Sure, but no one is going to do that.

When my appointment begins my doctor can look up any comments I left when scheduling the appointment so she knows why I'm there.

Or, you could… you know… talk to her.

I work for a healthcare company that runs several hospitals and primary care clinics. When you become a patient, you're given a little notebook and a branded pen so that inbetween appointments, the patient writes down every little health question and problem they have. When the patient shows up for the appointment, the little notebook is reviewed by the doctor.

Convenience should not always trump security.

That sounds like an absolute nightmare. I'd lose the pen and paper within 30 seconds. I much prefer being able to send a quick message to a healthcare provider on my phone and have them get back to me same or next day. Especially for the "should I come in for this rash?" types of questions. (I got MRSA at the gym one time!)

At my child's pediatrician I can upload images through the web portal and have a nurse call me back anytime of the day or night. If there's any follow-up questions at my child's next appointment, his doctor has full access to all communications that happened through both text message and the web portal.

This kind of 24-hour digitally connected healthcare access with a huge boon as a first-time parent and made life a lot easier, especially when incidents like when my son woke up at 3:00 in the morning screaming and then projectile vomited 6 ft across his room (which by the way, was nothing to worry about and apparently completely normal... So long as it just happened once.)

I'd lose the pen and paper within 30 seconds.

We should reduce the security of the entire healthcare system because you can't adult?

I much prefer being able to send a quick message to a healthcare provider on my phone and have them get back to me same or next day.

Goalposts moved.

This kind of 24-hour digitally connected healthcare access with a huge boon as a first-time parent and made life a lot easier

Your moved goalposts pretend that we don't also offer a 24-hour medical hotline.

> We should reduce the security of the entire healthcare system because you can't adult?

I commented that my hospital network has the ability for me to see test results, communicate with medical providers asynchronously, and lets healthcare providers communicate what I said to them with each other.

Your counter proposal was a notepad and a pen.

Those two things have very different feature sets.

A site not directly hooked up to the main hospital system where I can add notes of things I want to talk to during my next visit, sure, maybe that is a decent proposal to trade off security vs convenience.

> We should reduce the security of the entire healthcare system because you can't adult?

Do you expect patients dealing with depression or anxiety to be able to keep track of that notepad? How about patients who don't have secure housing, or who live with an abusive partner?

Or anyone who is elderly and just forgets things now and then.

Or anyone who is not neurotypical and has issues with memory?

That sounds awful. If I went to a doctor that did that, I would immediately find a different doctor.

> Or are you saying that it's fundamentally impossible to improve security in internet-connected systems because people are not equipped to do so?

Yes - but I don't think think it's that hard. There's 90% easy work to be more secure than most out there. It just requires expertise and for people to change how they work.

Instead people spend $bn on cyber security when you can get 97% of the way there by following good standards and knowing your systems.

I am by no means perfect, I spent all day Friday fixing hundreds of machines manually that had BSOD'd from CrowdStrike. In this case the vendor had made it impossible to do my job well because they offered zero control on how these updates are rolled out - there is no option to put them through QA first. Unlike the sensor itself, which we do roll out gradually after it has been proofed in QA.

I agree with you. Unfortunately my place of work has a habit of buying snake-oil security appliances as well which seems to magically absolve everyone from actually thinking about security deeply themselves.

Rather ironically said appliance (that basically acts as a man-in-the-middle in remote access) prevents me from going the last mile in securely configuring my systems. I would not be surprised if the appliance self-updates, but I'm not sure.

Regardless you could make the case that practices like these do not improve overall security, but instead just cost a large amount of money that you could hire three security-minded engineers from.

I interpreted it as "Software is crap, and it's hard to make crap work offline. The problem is not the offline, it's the crap."

The question is where to lay the blame for the crap, and how to change that.

I would love to see the author's "lists" turned into a table of sorts, and then any given piece of software could be rated by how many situations on each list it works in without modification, works in with trivial config tweaks, works in with more elaborate measures, or cannot work in. Turn the whole table green and your software is more attractive to certain environments.

I don't think it's always the software that is to blame. Sure there is software that wants to self-update and only accepts one upstream update source run by the vendor, instead of allowing users to run their own mirror and control update distribution to some extent.

But there are also cases where the software could be perfectly run in air-gapped systems but people are unwilling to put in the work (for some reason or another). For example everyone could run their own Docker image mirror that only contains images that are actually needed and pulls them from upstream with some delay. Docker allows you to pull images from your own registry. But not veryone is willing to operate their own registry.

There is some legislation with actual teeth getting implemented to help force vendors to incorporate decent security standards in all these edge deveices: https://www.withersworldwide.com/en-gb/insight/read/new-uk-l...

Reply on news.ycombinator.com