They also have a typo on their description...
"AI coding creates a time span isn't long enough to do something new, and it's not short enough to be entirely negligible"
Should say "that isn't long enough" or "which isn't long enough"
Always good to see people who give a shit getting rich off the results of their work /s
Is the conclusion here not that you are asking questions when you should instead have been looking for an existing resource?
The ability to search across the massive accumulation of knowledge we have already built up is a primary skill for software development, and the tut-tut'ing is a way of letting you know that you failed in that endeavor, which should be valuable feedback in itself.
How many people drive their car daily or near daily?
How many people are good drivers?
The ratio of those two values shows, in my experience, that a lot of people are not very good at things they spend a lot of time doing, and are generally unaware of their own shortcomings
The average American spends 4.2 hours a week in the car. A typical 40 year old american has driven around 50,000 miles. For someone to continue to be bad at driving after that much experience, it must be a fundamental limitation on their capabilities for learning, thinking, or understanding. Drive to work any given day in Denver and you will see that a large number of people suffer from those fundamental limitations.
This article seems to present a world where most people the author interacts with can think critically about a complex topic, and are interested in learning or improving themselves. I wish I lived where the author lives, because I have had multiple jobs across multiple countries and never encountered an average population like the author describes.
My impression driving around Denver is that far more people are choosing to drive dangerously/poorly than are doing so because they're inherently incapable of driving. Much like the author suggests, if you ask most people specific questions about good driving they'd probably get them correct. The fact that people then choose to drive poorly has more to do with lack of care/respect for others on the road, impatience and entitlement.
I don't think I agree with the premise. Sure there are lots of car accidents in absolute terms, but given how many people drive and how error-prone driving inherently is, most people are actually pretty decent drivers
Driving is not error prone, cars rarely break in unexpected ways.
People driving and making decisions are error prone.
A simple test is to watch how people turn. Do they turn early potentially hitting the curb or cutting it too close to pedestrians. Or do they increase their radius by turning late? The latter are better drivers.
Edit: here are more tests,
- do they signal
- do they cutoff others
- do they let those who signal in
- do they drive too slow or too fast for the given road and conditions
- do they have an awareness of all cars around them
- do they block the passing lane
- do they maintain a reasonable distance behind other cars
> and are generally unaware of their own shortcomings
> it must be a fundamental limitation on their capabilities for learning, thinking, or understanding
You said it yourself. Assuming people are doing something without being mindful and purposefully trying to improve then 50k miles on mental autopilot it is not a surprise that someone wouldn't get better at driving.
Without a desire to improve and/or being involved in a process that would give feedback then there will be no growth.
Making decisions that are better for the collective group?
Or making decisions that are better for them individually?
I think most of you assume the former when you should really expect the latter. Viewed through that lens both the set of problems and solutions should be obvious.
I feel like this hinges on the definition of what it means to be "bad" at driving; by definition, I'd argue that the average driver is average at driving, and around half of people are above average at it. If you think most people are bad at driving, I feel like the conclusion is "driving is hard", because there's not any secret set of platonic ideal drivers in real life to compare them to. Trying to measure by an objective metric like how many accidents a driver gets into can be useful, but drawing conclusions from that like "most people are bad at driving" won't be very meaningful for a similar reason to the ones the article dissects; the evidence is measuring something much more specific than the broad principle you're asserting.
(For what it's worth, I'm making this argument as someone who _is_ a bad driver, and that's a large part of why I don't drive anymore!)
> and are generally unaware of their own shortcomings
You don't see your own here? Are you honestly sitting on the side of the road and intentionally evaluating drivers according to some criteria? Or are you just allowing yourself to notice that which inconveniences you?
Do you ever take time to notice how _convenienced_ you are? How cooperative other drivers can be? How often the rules get followed even though there is no one around to enforce them?
> the author interacts with can think critically about a complex topic
People can. They let their emotions get in the way and they simply choose not to. Frustratingly they never seem to notice when this happens. They remember that they _can_ make rational decisions so they assume _all_ their decisions are rational.
Bad drivers are a poor example. Driving is an inherently social activity. It involves subconsciously predicting other people's behaviors. Each region has its own definition of what is the norm. This includes things like acceptable speeding, lane switching behavior, average distance between cars, etc. When reality differs from expectations, we label them as a bad driver.
But are they a bad driver? Maybe. Or maybe they are driving according to another region's expectations. So any time you see a bad driver from another region, or you are the one in another region, stop and think is it really bad, or just unexpected?
For this reason I ignore all claims of "People from X are terrible drivers." No, they just drive differently.
The driving example is interesting, because I think there are two different groups of people assessing the 'goodness' of their driving and others' driving by two different standards. One group thinks a 'good' driver is one that is skilled at driving a car; the other group thinks that a 'good' driver is the one that does the 'nice' thing in any given situation. The 'skilled' drivers look at the 'nice' drivers and think that the 'nice' drivers are unskilled and display little interest in reaching their destination. The 'nice' drivers think the 'skilled' drivers are dangerous.
I think the 50k miles estimate is probably pretty low given the average miles insurance companies assume most people drive per year is closer to 10k. Conservatively, that would place it closer to 200k miles by age 40.
I've always assumed the reason people don't get better at driving with that much experience is the reason people don't get much better at most of the things they do: they've never pushed themselves to the limit of their capabilities. While this can be dangerous in a car, it can be even more dangerous when you're put in an unexpected circumstance with no ability to respond calmly and correctly.
Is there something here about the role of (and lack of in this case) deliberate and intentional practice?
4.2 hours a week in a car doesn't imply that any of that time is spent doing things that may make one a better driver (by whatever standard we're measuring this), it's just repetion of the minimal amount of driving skill that's enough to get you by.
If it's not possible to increase one's skill in anything without practicing things that are just on the edge of capability then no amount of regular, unsupervisied driving without any critique targeted towards improvement is going to help.
> Is there something here about the role of (and lack of in this case) deliberate and intentional practice?
Something like 50% of college graduates in the US are considered functionally illiterate, despite an enormous number of opportunities for intentional practice; and despite presumably knowing, at least somewhat, of the benefit of attaining more advanced literacy.
https://www.nbcnews.com/id/wbna10928755
When I think of poor drivers, I think their incentives to become a good driver are much higher. After all, their own lives and the lives of their loved ones are at risk.
It's 2024, PKI best practices are well known and well documented, anybody still using a self-signed certs on their mail server (or anywhere) is either lazy or stupid.
Plenty of existing applications will refuse to connect to a self-signed certificate on the belief that allowing the end-user to confirm a certificate offers basically 0 protection against malicious actors.
"This is good enough because I don't expect anyone other than me will use it" is lazy
What would happen if you connected to your mail client today and you got prompted "Trust this certificate?" showing a certificate with the same subject as the one you generated? Most people would click trust and get MITM'ed
Allowing self signed certificates significantly lowers the bar when it comes to generating a new certificate which can closely resemble an existing certificate
Beyond that, the management of multiple trusted certificates creates all sorts of room for confusion in an environment. Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA
So accept self signed on first connection with a detailed panel showing the certificate fingerprint. Then after that require a more involved process to accept a new certificate.
> do you really maintain every certificate both on it's application and on everything which needs to connect to it?
These are client certificates, and in some cases, they're actually pretty awesome.
> than signing all your PKI with an internal CA
That's a single layer of abstraction away from a self signed certificate, because, your CA _is_ a self signed certificate in this scenario. You've taken any defense in depth and thrown it right out the window.
The purpose of software is to make things possible not enforce random pedantry.
>"This is good enough because I don't expect anyone other than me will use it" is lazy
is both a mischaracterisation of the argument, and wrong. It's not lazy, it's a choice with pros and cons. Just because you don't like it does not mean it is lazy. Again, issuing your own certificates is a choice.
Allowing self signed certificates does not "significant lower the bar". Did you know that all root certificates are self signed?
The management of multiple trusted certificates is basic administration for large private networks. Yes, TLS and certificate management can be complex, but that is not a good argument for disallowing it, and the idea that managing your own certificate trust is against "best practices" is ludicrous.
Why would this oblige the client to trust any self-signed cert as opposed to trusting all certificates whose chain of trust can be established using the system's trust store? The reporter isn't asking for mail to automatically trust untrusted certificates, they have added them to the trust store.
Please keep in mind that a self-signed certificate is quite different from a certificate that is signed using a private CA.
The self-signed certificate has no link to a trust anchor. So it’s easy for Mallory to replace it with her own malicious certificate. It’s much harder for Mallory to replace a certificate that is tied to a CA.
It’s 2024, we’ve seen countless examples of sophisticated hackers getting into all kinds of systems. Anybody who makes a blanket statement that you have to trust the public PKI is either lazy or stupid.
SSH has TOFU and it works very well if you don’t want a key infrastructure.
I didn't say a "pinned self signed cert is insecure"
I said that self-signed certs are a lazy choice
I also said "allowing the end-user to confirm a certificate offers basically 0 protection"
If an average user get's prompted to trust a certificate they will do so blindly
At most, someone might look at the subject, but it's 0 effort for a malicious actor to generate a self-signed cert with the same subject, which will be sufficient to fool a decent chunk of users
Pinned certificates do relieve the above issue, but it is still a lazy choice that creates increased long term complexity in the configuration of multi-system environments
Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA
Using a CA also allows for use of CRLs or OCPS.
If you have 20 devices configured to trust a given self-signed certificate, and that certificate leaks, you now have to update all 20 devices to remove that trust. If you used a CA and implemented either a CRL or OCSP, then you only have to update the respective impelmentation and all of yoru clients will immediately stop trusting that certificate.
In Summary:
Using an internal CA offers all the potential protections of pinned certificate, with a number of additional useful security options like OCSP or CRLs
Using Self signed certificates creates more work when handling certificate leaks or certificate rotation
Using a CA is the industry standard practice, I highly doubt there is a single outward facing project by a major company using a directly self-signed certificate.
BUT
A self signed certificate is lower effort on the initial setup
You need to calm down and take a step back to realize not everyone needs to support 20 devices or even 2. What you’ve suggested is a ridiculous blanket statement assuming everyone is setting up things for a fleet of clients.
for the use case of a single user IMAP server this is all way, way, too complicated and buys you nothing in terms of security. it's completely analogous to why we dont use CAs to validate openssh host certificates.
Yes it's a analogous using CA is still a higher bar, but it would arguably be better to also use CA to validate openssh host certificates for all the reasons he listed above.
So maybe we should ask ourselves why can't we just figure out a way to improve handling of CA? Thanks to Let's Encrypt https coverage dramatically improved, now is maybe the time for more people to switch to self CA.
I agree though that promoting adoption through good tooling and pedagogy would be a nicer approach than Apple slap on the wrist.
It really only is for bad practical reasons, that all coincidentally make it harder and harder to self-host stuff locally without paying a few dollars a month or year here and there to various rent seekers.
"Just use Letsencrypt" really is the correct answer for 99% of use cases, but good luck if you find yourself with one from the 1%. You'll get an army of people mindlessly parroting "best practices" and will assume you're incompetent/lazy if you can't find a way to make them work for you.
Internal CAs and self signed certificates are different. You can still generate a CA, sign your certificates, import your own CA into your phone and have that verify your certificates. You don't need Letsencrypt. But you'll learn in time.
Thanks for the condescension, but I know how to do all of this. I've done it before. And because of that, I can first hand attest that it's way too complicated.
No non-sophisticated user is able to run their own local CA, and that's why their NAS, IoT setup etc. all run over HTTP only, which in turn has implications for available web APIs (thanks to "secure origin only" policies and no exemption for local IPs/zeroconf domains) and many other things.
It also doesn't work for at least modern Android apps, since Android no longer makes user-provided CA certificates available to (non-browser) apps anymore, I believe, unless they're compiled with a special debugging parameter. On iOS it's still possible, but I'm not sure how long it's going to stay that way.
The barrier to entry on PKI isn't that it's hard, it seems to be that people just can't be bothered, PKI is among the most google-able tech processes out there
Setting up a NAS means buying one on Amazon and plugging it in.
You're completely out of touch with the majority of the userbase of these products if you think even one in 10 NAS users will set up their own CA using OpenSSL (in a secure way that doesn't expose themselves to being MITMed even on public sites such as that of their bank down the road).
In that case the NAS company should, at a minimum, be loading their NAS with a certificate signed by a CA owned by the NAS company, where the trust chain for their NAS's certificates are easily available for users to grab and install.
In an ideal world they would load a letencrypt certificate and set up the tooling required to automatically pull down a new one when required.
A NAS company owned CA doesn't offer much of a benefit directly for the plug-n-play users, but it's still better than just a self signed cert, and for people who care about their security even a little bit it can significantly protection.
Most Plug-n-Play NAS solutions will integrate with a web api and/or an app, and it's more common than it should be that NAS'es are exposed to the internet.
Once you control both the NAS and it's clients, there's absolutely no reason not to preload a complete PKI implementation. Even just an installation app which loaded the chain onto any device you wanted to interact with the NAS would be sufficient.
If NAS'es are intended for non-technical people, then any NAS sold should be secure by default.
My point is precisely that current browsers and OSes make it impossible to ship a secure-by-default device running a local web server, NAS or otherwise.
Requiring users to install a globally trusted CA is a disaster from a security point of view (now my NAS vendor or anyone that hacks them can pose as google.com!), and for this reason doesn’t even work with modern Android apps anymore, for example.
Or is operating a local-only mailserver not connected to the larger internet? I guess that's a lazy or stupid thing too, these days...
I'm a fan of having TLS on by default for everything on the Internet, but I'm seriously annoyed by the collateral damage to local self-hosted services the implementation of that has caused.
It shouldn't be this hard to e.g. host web server on my local network that browsers grace with "trusted website APIs", but it really is. Why on earth do I need to set up Letsencrypt (and by extension at least DNS) on a local website if I want to be able to use a game pad on it, for example!? https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
We absolutely need a localhost and local domain exemption for both TLS/X.509 certificate validation and web APIs. For example, TOFU seems like a much better model for that use case than trying to bend the "public Internet" model until it fits. SSH has had considerable success in that model, for example.
You have to consider the rarity of your use case vs the use case they're defending against.
How often do you think someone tries to connect their gamepad to a local server? Not never, but the total amount of users doing it is probably high tens or low hundreds at most
Compare that to how often gamepad users try to connect to a malicious website - probably hundreds or ever thousands of times a day.
Loosening certificate validation further expose the many less than competent users to risk, and the potential impact both on the customer base and on the product's reputation are significantly higher than the risks of making it cost a couple bucks a year to allow your gamepad to connect to a local server.
For something like a computer, there is a legitimate argument for allowing the user to bypass SSL/TLS restrictions (after some resistance) because laptops are used for development.
I can almost guarantee that the gamepad developers had an options for certificate validation bypass in it's developer options, but they're not gonna expose that needlessly when it offers no benefit, but exposes their customers to additional risk. Your gamepad is likely not a development device after all
Any malicious website can access my gamepad, since it can trivially get a Letsencrypt certificate – the only requirement for getting "secure origin" API access.
What exactly is this restriction preventing me from, then? (And what does a malicious website do with my gamepad data anyway?)
> Not never, but the total amount of users doing it is probably high tens or low hundreds at most
Yes, I'm fully aware that local hosting is rare in the grand scheme of things, but I think you're vastly underestimating the potential. It's currently not even possible to do much better even as a commercial NAS provider, and these are somewhat popular.
A big part of that also seems like a chicken and egg problem: Fewer and fewer users do it because it's getting harder and harder, thanks to browser standards and OS defaults being largely driven by stakeholders that have no interest in it becoming easier.
Yes, none of this is an evil conspiracy; it's just a question of incentives and priorities in the end. I just find it so sad how willingly even a "hacker" audience here embraces the move towards more and more centralization, on more than one dimension. (Peer-to-peer vs. client-to-server, "trusted CA only" vs. trust on first use, cloud vs. self-hosting etc.)
Allowing self-signed certificates creates a higher risk for MITM attacks.
Sure you can trivially get a letsencrypt certificate once you register a DNS entry, but you can't trivially get a letsencrypt certificate which validates google.com
If you control the local network it's trivial to redirect traffic intended for elsewhere, like "google.com", and trivial to have the server it redirects to present a certificate with "google.com" in it's subject or SAN.
What would happen on a laptop is you would be hit with a certificate validation error because it was self signed, and on the laptop you have the ability to bypass it, but that ability to bypass is very dangerous. Most users will not properly check a certificate before clicking to trust it.
As far as what could be done, "this is a low value device to an attacker" is not a security measure, but beyond that I'm sure that people have bought games on a gamepad, and anything which involves financial transactions has the potential for malicious behavior with severe consequences
.local also hasn't been best practice since 2005. Current recommendation, because of Certificates is to use internal only subdomain of domain you have control over.
What? .local is the dedicated TLD for Zeroconf/Bonjour/mDNS! How is that deprecated?
And you’re just reconfirming my point: All of these recommendations are great for publicly hosted sites or corporate environments, but largely impracticable for home users that don’t know how to, or don’t want to, have a second job as sysadmins.
Cool, you don't but obviously you don't deal with a ton of normal users. They are not running NASes, they will just toss Google some cash for bigger GMail box.
Ah, that’s good – it’s been a while since I last had to work around that.
And I generally agree on local networks being insecure. So how about making them more secure instead of marginalizing them even more?
TOFU for TLS certs on .local (for Zeroconf, and maybe something else/new for local DNS) would be a huge step forward from unencrypted and unauthenticated HTTP. Such sites could even still be displayed with a broken padlock or whatever HTTP gets these days to not create any false expectations by users.
I used logic.ly for a class last semester, we used it for about a month and built up to a very basic cpu. I found it pretty easy to pick up and fun to work in. Wouldn't be surprised if a lot of online computer arch classes use this in the coming online semester.
Glad to see this go public. I am interning for one of the guys working on this project (I am not working on this however) and they seem like good guys. Best of luck in getting funding!
Congratulations on getting published. Having finished the paper I thought it was informative and well written. I just started interning for you guys today and I look forward to an exciting month!
I am currently an intern an The Immunity Project, a YC funded non-profit working on vaccinating HIV. I have been here for only a day so far but I whole heartedly agree. I have been welcomed with open arms, introduced to new and interesting people, and learned thing about the industry I never would have in a college run program. This is only my second time meeting the team, but I am excited to work with them. I will be doing interesting experiments, and legitimate lab work, something not offered in most programs. I also gain access to community between the different companies that is unique and exciting. I definitely recommend this to anyone who gets the opportunity to pursue interning for a YC company.
Always good to see people who give a shit getting rich off the results of their work /s