I am sure IRC was good for some people, but I can say for me personally it was a net negative and real life was so, so much better. I wish I never used IRC.
I also personally witnessed multiple friends who dropped out of college due to IRC addiction in the early 1990s.
I am curious if anyone else has a similar memory of IRC.
QuakeNet in the 90s, I don't know what to say, thank you? It was high school for me, like, I got through high school, got into computers in high school, have great memories of that time: because of QuakeNet in the 90s. hackernews community is the closest things I've felt to that since then, but it's pretty hard to beat QuakenNet in the 90s.
Depends a lot on where you were growing up, and what kind of community surrounded you. For me IRC and the internet at large was a salvation, but the 90s in my country of origin were... interesting times. Being on the internet was much healthier and much less hazardous than most of the things real life focused people in my age group were doing back then.
There are people on IRC who I've maintained contact with for longer than anyone I can think of off the top of my head aside from family members. Many now through other channels (thanks to the Discord wrecking ball), though some still on IRC.
Hard to say how many intellectual rabbit holes I've gone down as a result.
I can say for sure life would have looked very, very different without it.
> I also personally witnessed multiple friends who dropped out of college due to IRC addiction in the early 1990s.
I think there's always a segment of any population that will get addicted to anything, to the point of dropping family, friends, school, or work. Blame it on culture, nurture, genetics, unfulfillment, or simply lack of self control, but it always happens.
Blaming IRC, which is a pretty neutral outlet, is unfair. This is specially true today, as we have things designed and constantly honed to be as addictive as possible.
Even though I really like irc because I can get answers really quickly from helpful people but it's a net negative I have felt if you linger on and listen to people conversing. IRC is good for short help needs but if you spend lot of time then it's net negative. I feel for the helpful ppl on various irc channels who are there to help out of their own goodness. They must be having a lot of net negative
It's not too bad after some (a lot of) adjustments, but I agree the problem is that the default is that notifications are on. I'm part of more than a dozen Discord servers, and only three of them have notifications enabled, and one of those are basically dead. If I joint a new one, the first thing I do is mute it, and then I'll maybe unmute it if I'm actually active in there (or if it's a large server, I'll unmute the specific channels I care about and mute everything else).
I have email notifications on, but I actually read the few newsletters I get, and I barely get any mail beyond that. Meanwhile, everybody else I see has 4000 unread emails and the vast majority are unread rubbish that they could have unsubscribed to 700 emails ago, or just never subscribed to to begin with, but I guess signing up for that shit is just the default now.
I go even further: I only use the website. If I want to add or modify something, I go to my profile and do it. I only used 2 social network apps, and they are mostly for news and to check on tech people I follow.
My wife's phone, is just full of noise. Notifications, messages, email ... some folks just want to be in front of a fire hose of crap... I don't know why.
He's not "obligated" to do anything but it's still immoral to abandon maintenence of something like that. If he can't be bothered to maintain it, then he should delete it.
I don’t know if the allegations against Jon Pretty were valid or not, but those who piled on against him can’t escape accountability for mob behavior (assuming Pretty was innocent) if it becomes embarrassing. At most they can say “I supported this but no longer do”, not expunge all traces.
> If he can't be bothered to maintain it, then he should delete it.
Not necessarily, plenty of projects have been put in an archive state because they are 'finished', superseded, forked, etc. This isn't code nor a living document, it was a one-off operation.
> He's not "obligated" to do anything but it's still immoral to abandon maintenence of something like that. If he can't be bothered to maintain it, then he should delete it.
Morality is subjective (that's why we have courts; which don't respect the individual and differing moralities of the parties involved, it has its own moral bar, for better or worse).
In this case, I feel it is more moral to record all the members of the mob. Maybe this would cause them to think twice before joining the next mob.
I mean, if we are going to have witch-hunt mobs, then the lesser evil is to not allow anonymous mobbers.
The first was that 123456 was the credentials for the admin panel.
The second was an insecure direct object reference, where the lead_id querystring parameter can be changed on an API call to retrieve another applicant's data.
> It sounds like there were two separate problems:
> The first was that 123456 was the credentials for the admin panel.
No. 123456 was the credentials for the test setup, which contained nothing. But you could use the IDOR to access data from the test setup.
If 123456 had been the credentials to the admin panel, there would have been no point in exploiting an IDOR - as an admin, you can just look at whatever you want.
Using numeric IDs on an outward facing object is, for the most part, totally fine. It's a serious tradeoff to ditch the nice properties of numerical IDs and the legibility they provide in order to cargo-cult a "we must reveal nothing" approach, as you would here via UUID. It also misses the point of the actual security lesson: no matter the identifier, you need to be applying access controls to your data. Even if your UUIDs were generated via 100% airtight cryptographically random sources, you have to, y'know, communicate with them. That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs). If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way. Don't stress about the theoretical benefits of something like an opaque identifier and then completely neglect the necessary real world access control.
Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?
> If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way.
Defense in depth is a thing, so even if you make a mistake in one place, and the attacker gets complete access - as what happened with the McApplicaton here - they won't be able to download your entire db within minutes. Even with zero authentication, non-guessable identifiers will slow down the exfiltration by several factors from dozens/hundreds of records per second to one record per $MANY_DAYS, with lots of 404s for the defenders to look at.
> That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs)
The additional friction of acquiring the UUIDs from a different channel is beneficial to defenders, compared to decrementing or incrementing IDs, which is trivial to do, and doesn't need RCE. It's the difference between "All users' data was exfiltrated" and "Only a couple/handful of accounts were affected", and this can make or break the breached company.
I think I disagree with "totally fine"... Even if that were true though, this case is definitely a point where you wouldn't want to give away information with a numeric ID. Giving away # of applications/growth of that over time is definitely business information that arguably should not be discernible.
The point is not that UUIDs are magically secure, it's that they mean nothing to whoever gains access except a single job app. The assumption is that they will get out (they're in a public URL), and that they will have no meaning when they do.
It's a defense-in-depth thing IMO -- cargo-culting this approach defends you even when you don't do the other things right. It's simple -- with a non-zero probability that the actual access control is faulty, do you want a default that protects you or doesn't. What's the intentional trade we're going for? More DB perf? Easier to type URLs? There are other ways to deal with those
> Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?
Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?
With HMAC, you can still ask for some sequential IDs
SipHash128(0, KEY) = k_0
SipHash128(1, KEY) = k_1
You get the same number of bits as a UUID.
You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.
You are both right. UUIDs, if randomly generated from a CSPRNG are impossible to guess. But not all UUIDs are generated from a secure RNG, or use randomness at all.
UUIDv4 may or may not use a cryptographically secure random number generator. Python's UUID library, for example, falls back to the insecure 'random' module. Given a handful of outputs, it's possible to predict future ones.
For python specifically, the uuid4 function does use the randomness from os.urandom, which is supposed to be cryptographically random on most platforms.
Yeah, Python went through a big shakeup around secure randomness when they put together the "secrets" library, around a decade ago. A lot of that also got backported on most OSs.
So there really shouldn't be anyone using that today, thankfully.
Gasp! I had no idea about the Python implementation. Not that I do anything where it would matter (just need a random id), but for an already slow language, I would prefer the safer default.
Yes, you are technically right -- I should have said "functionally impossible". It's not actually impossible, but close enough for the average random onlooker.
> During a cursory security review of a few hours, we identified two serious issues: the McHire administration interface for restaurant owners accepted the default credentials 123456:123456, and an insecure direct object reference (IDOR) on an internal API allowed us to access any contacts and chats we wanted. Together they allowed us and anyone else with a McHire account and access to any inbox to retrieve the personal data of more than 64 million applicants.
As an LP, I would be excited for liquidity in 10 years at this point.
It seems like even for successful companies, there isn't a clear path to an exit for many of them. Add to that the increase in late-stage investors, and there isn't much of an incentive to exit.
A bit hyperbolic but yeah. It also depends on the industry / stage. I’m always looking for creative ways to get liquidity out given the exit issues you mention.
Parent commenter helped implement async in JS, they know what they are talking about. JS has threads locked behind semantics. Web workers run on separate threads. I do a lot of heavy parallel processing that never blocks the UI with them all the time.
Web workers are great for local compute and isolation. Unfortunately it's a hassle managing sane pooling because different platforms have different worker limits.
On the other hand, the isolation guarantees are strong. There aren't really any footguns. Messaging is straightforward, works with a lot of data types and supports channels for inter-worker communication.
I also personally witnessed multiple friends who dropped out of college due to IRC addiction in the early 1990s.
I am curious if anyone else has a similar memory of IRC.