If Midjourney says "maybe you have cancer" but your doctor doesn't take it seriously, you might sue if you do end up with cancer. You might even win, regardless of whether "wait and see" was the right approach.
Meanwhile, if your doctor gives you an unnecessary CT scan that rules out cancer, hospital both earns $$$ and the doctor doesn't face legal consequences. Your increased chance of cancer risk from the radiation isn't something you can realistically sue over.
I love how the post is clearly written by AI. A human might've noticed all the screenshots appear to be of interactive hentai games distributed through Wallpaper Engine. And wouldn't have said:
> On the surface, this wallpaper sample (above) we uncovered in December 2025 looks completely harmless.
In reference to a screenshot of an anime woman with ripped clothes, eyes in fear, being monitored by CCTV camera.
From my knowledge, "adult entertainment" is targeted by malware because it's socially embarrassing to admit that was the attack vector. It's relevant to point that out.
Sexual arousal also tends to inhibit rational thought. I don't mean that in a snarky or sarcastic way, I mean that it is a biological process that has been well-studied and well-established [1]. This has obvious uses for scamming people and doing other things that their executive function might normally catch and prevent.
This is also why sexual imagery should generally be kept out of public spaces, not because of "puritanism" but because it just generally isn't a good idea to go around letting bad actors inhibiting people's executive function willy-nilly. That should generally be denied as a tool to bad actors like scammers.
Why would seeing sexual imagery make you less rational? That doesn't make sense.
The study you mention say the people were already in an arousal state (that they had to induce themselves). It's very different from seeing images that you may simply ignore, evaluate differently, etc.
Also, there is the bias that if people are looking for such images (because they really want them), they are probably more willing to drop recommended practices, and hence make irrational moves. So irrationality doesn't come from seeing the images at the first place, but from their willingness to find / see such images.
>This is also why sexual imagery should generally be kept out of public spaces, not because of "puritanism" but because it just generally isn't a good idea to go around letting bad actors inhibiting people's executive function willy-nilly
Okay but presumeably humans adapt to the level of "sexuality" around them to some degree (like they do nearly every other stimulus), because otherwise you could show less prude cultures having lower ability to do "rational thought".
Nudity is normal all over the world and yet people seem to function just fine. What constitutes content that justifies sexual arousal is socially constructed!
I cited my sources. You're welcome to seek out studies on the question of how it varies between societies, they probably exist somewhere. However as part of the "adaptation" you cite is precisely scammers getting better at scamming people, this isn't something we should treat casually.
It's not as if it's news or anything. "Sex sells" isn't a new phrase. But I think most people assume it's just because it's ambiently appealing, the fact that it also objectively lowers rational barriers to buying what is being sold is less well understood and changes the question from just a matter of appeal to one of psychological abusiveness.
That's how I've come to see it; that sexy chick (sexist language chosen advisedly) on the billboard isn't just a company nicely providing me a beautiful thing to look at for no reason at all, it's an attack on my executive function. It's an incredibly hostile thing to do and should be treated as such.
Note the above commenter specifically used the language "sexual imagery" and not "nudity". As you point out, what can be considered "sexual imagery" can vary somewhat based on the cultural norms of the society.
Somewhat? The variance is off the charts. Without even going to the extremes of casual nudism vs burka, there are cultures where wearing hair down is seen as sexual, and there are cultures were twerking is child appropriate.
This was the technique used by American Dad speedrunners. Unfortunately, speedrun.com banned it after years of controversy, since fast-forwarding videos doesn't count as a speedrun.
The economics solution is to legalize drugs and give addicts an unlimited supply.
Addicts do not want money, they are doing this because they have a near-perfectly inelastic demand for drugs. Satisfy the demand and they'll will get high all day + opt out of society.
That seems like a false-dichotomy between two extremes when there's all sorts of space in the middle... It's also assuming developer-to-developer tools would have the same rules and exposure as in service-to-consumer.
If I sell a physical motor (let alone plans for one) I'll have some liability for things like it Not Exploding. If someone buys a dozen of those motors to assemble a tragically unsafe "rollercoaster" of their own design and construction, I'm almost certainly not responsible for any terrifying decapitations.
In other words, most of the world already does not rely on the issuance of "Get Out Of Infinite Liability Free" cards.
Exactly this. (and it is a false dichotomy to argue infinite liability).
To Terr_'s point, if you were publishing open source you would also publish exactly the things you intended it to be used for and anything else would violate your warranty (possibly implied) that it does what the documentation says it does.
There is a huge amount of tort law that covers exactly when it becomes a problem for you the creator vs you the user in your own project. And that liability is also based on once you know something bad could happen you make an effort to notify people[1].
Software can be copied infinitely, so even $1 of liability is effectively infinite since an unlimited number of people can potentially use it and sue you when it blows up.
Nobody's going to be distributing software on the internet for free if the cost of insurance alone precludes that.
This is not how liability works, anywhere. So I write a piece of code that "makes your screen do cool things" and it causes the power supply to fail on those screens. Someone reports that bug to me and I check it out and say "Oh, shit it does break power supplies." Then I immediately put a notice on and in the code that says "WARNING: This code will break the power supply of your montitor." And I put that warning in the repo. And if there is a Discord or a mailing list I tell everyone "Hey, this is important, if you run this code it can break your monitor."
Guess what, I'm not liable for the damage. Why? Because I immediately responded once I knew that it could, I made a good effort to warn people who might already have the code of the risk, and I made it clear in the code that this risk is there.
Ever wonder why you get a booklet of warnings when you buy a product with even really stupid things like "Don't clean with gasoline" warnings? That's because once you have discharged your duty to warn you are not longer liable in what happens if someone ignores your warning.
The flip side is also true, you cannot say in your product both "Hey this product does these cool things" and "We don't warrant the product to actually do anything." This is especially true if there is money involved (like your user paid your some $ for the product.) There is always an implied warranty that the thing will do what you says it will do, which exists as long as the user has heeded all your warnings.
I broadly agree with you but TBF to the earlier comment consider what would happen if a FOSS author did something wrong and was found to be liable. How about curl for example? That sees use in car infotainment systems among other things and cars can be pretty expensive and there sure are an awful lot of them. The point is that we should be able to accommodate someone pushing a hobby project to github under a permissive license while also imposing liability against developers in instances where money changes hands or where someone's work involves interacting with the physical world.
The EU CRA handles this by putting liability on someone who integrates FOSS into a product instead of someone who wrote it. Because it doesn't make sense to put liability for unforeseen downstream uses on someone who gave away something they made in their spare time. Now, if it was a virus, you're still liable for distributing a virus.
Yes, when you're selling a product you can price the risk of lawsuits into whatever you're charging customers. You can't do that with free software without making it no longer free.
"No problem: just don't get sued" only works if legal battles are free and/or the law makes it so blatently obvious that you're not liable that nobody would bother to try.
I realize this is drifting off topic, and happy to talk more in email (address in profile), in the interest of sharing a bit more, consider this statement you paraphrase:
"a FOSS author did something wrong and was found to be liable"
In fairness, I not sure the earlier commentator really understood what they were saying, at least not as far as legal liability is concerned.
The FOSS author simply wrote some code and shared it right? That is their 'action' can you think of ways that does direct harm, which is to say they published their code, and with nothing else happening someone got harmed? One way that can cause harm is the FOSS author publishes a trade secret[1] or access credentials of a third party. In both cases they could (and would) be sued by that third party. But absent that, I'm having a hard time coming up where simply the existence of most code causes someone else harm.
So to get to harm we have to add another person, that person somehow applies the code, and in that application harms another person. Our FOSS author might be sued as being contributory because the person who caused harm might not have done so if they didn't have access to the code. To prove that, the plaintiff would have to prove that the FOSS author knew that the code could cause harm if used in this way, and encouraged or otherwise abetted the person who did harm to use it in doing the harm. That can be a hard standard to reach[2].
In your car example, it would be challenging to prove that Daniel Stenberg wrote curl so that you could use it to brick car infotainment systems. But it would be easier to prove that a manufacturer that incorporated FOSS code and didn't check their system for risks like this should be found liable.
Liability accrues first to the party that did the action. Secondary liability can reach out to suppliers[3] of things used in that action. This is also civil law rather than criminal law and so it works a bit differently in terms of evidence standards and penalties.
[1] We can make a joke here about badly formatted code, but hopefully we're in a agreement so far. A real example was the DVD decoding software that included the key for decoding encrypted DVDs.
[2] Not that people might not try, its too easy to sue. There have been cases where someone wrote some code that was later used in a weapon (and example might be Ardupilot software in drones used to kill Russians). But even in that case, the courts in the US at least have consistently found that if it is not the primary purpose of the software to do harm, then the author is not liable.
[3] Unless you're a gun company as Gun companies have managed to keep themselves from being found liable for people using their guns to do harm. But there is also lots of interesting case law there too which might help inform.
That's a really good point. Where I remain at least somewhat concerned is for example suppose that one day curl pushes a terrible bug to production that results in all sorts of nasal demons flying out of client devices. Is this free code that was picked up off the side of the road thus zero liability? Or is this a trusted product written and maintained by a professional that has stood the test of time thus there might be liability because there's an assumption that official updates will be fit for purpose?
Now if I were running a small business I might choose not worry about the tail risk of my product causing a few million dollars in harm or (more likely) I'd have insurance to cover that. But someone tossing code along the side of the road presumably doesn't have (and doesn't want to think about) insurance and meanwhile the tail risk has become nearly unbounded thanks to the effectively arbitrary number of deployed instances.
I think there's also some benefit to having a big fat NO WARRANTY clause at the top of the license file because it might give you a better chance of a summary dismissal (or even deter the other party from trying in the first place) since as we all know the process itself can be ruinous even if you eventually prevail.
Which is all to say that I share your view. Willingly negligent vendors that cut costs by omitting security while viewing the resultant mishaps as an inescapable reality ought to be held accountable. But I think it would also be a good idea to add an official exemption for software that's made available free of charge. It seems like if you pick something up off the side of the road any mishaps that follow from that should necessarily fall to you.
There's a pattern I noticed, especially on this site, where people claim various VC/ad/tech dark patterns, enshitification, privacy violations, dishonest marketing, etc MUST be allowed, otherwise open source or 'the internet' will face some sort of existential risk.
No bro - open source and the internet existed long before SV tech parasitism did and will exist long after.
I don't disagree, that pattern exists, but it is essentially true. Just not in the way the folks saying it is true understand it. If the "VC/ad/tech dark patterns, enshitification, privacy violations, dishonest marketing, Etc." wasn't allowed then their job might not exist. That can be true. What is missed is that if there is value in the thing, then it will exist.
When I reflect back to someone making this argument by saying, "So your argument is that you make your living as a pick pocket, but if pick pocketing is made to be illegal, you won't be able to make a living." Which of course would only be true if they only thing they could do was 'be a pick pocket'. Its a very common rhetorical technique to argue that the status quo cannot be changed. All the arguments that "you'll put all coal miners out of business if you require only green energy" And yet the people, the miners themselves, will likely be fine. The firms might not, but there are other firms that could exist.
This isn't a new problem, or one specific to this web site, although it does get disproportionately hit because so many technology companies saw what Google started in the 2000's and said, "Man there is soooo many ways to get money for this." rather than, "Is this a reasonable way to make money? Sure it is 'perfectly legal' but is it right? Is it moral?" The type of person who thinks that something is "Only illegal if you get caught" is neither moral nor particularly concerned about what is right. And we got a lot of that type.
"Its a very common rhetorical technique to argue that the status quo cannot be changed."
Thank you for putting this so eloquently into words. This rigid thinking is also common in topics such as working conditions, collective bargaining, on-call time, parental leave, healthcare, and effectively (unintentionally or not) shuts down conversation.
I've come to realize the objections from people who think this way all effectively boil down to 'Be grateful for what you have because any alternative would be worse.' But if you pry and ask that they expand you'll find there really isn't any there there, because it's black and white thinking. It isn't rooted in fact, it comes from fear. I sure hope we haven't collectively forgot how to even imagine a system that functions better than the one we have today.
Thanks. For me, I was in debate club in High School and that included basic rhetoric. In college I took an argumentation class as a non-engineering elective. The most useful thing this class taught (for me) is how to 'see' the argument, and as a consequence see how it is constructed. Throughout my career it has been especially useful in "political" situations at work. Not everyone argues in good faith, and being able to spot those who are not is valuable.
The United States/Canada don't have a "loser pays" rule, so this exposes me to legal fees.
Right now, any lawsuit against me can be dismissed on summary judgement because even if my software causes harm, that's not a legal wrong to the extent I've disclaimed liability.
If you adopt any fact-specific standard for liability, that needs to be adjudicated in a trial. The legal fees alone would surpass the actual liability.
That creates huge leverage for the party with more resources. That kills hobbyist open-source development, since if your project takes off but a large enterprise finds it defective, they can threaten to sue you to enforce the "warranty" you were required to give.
> That kills hobbyist open-source development, since if your project takes off but a large enterprise finds it defective, they can threaten to sue you to enforce the "warranty" you were required to give.
I think you're assuming some kind of worst-possible outcome that hasn't been proposed and is unlikely to be enacted. To quote from earlier in the thread: "Disallow disclaiming liability on software used in a product."
I don't think that changes your hobby work on a rational-math library or an MVC framework or whatever, since you aren't making a business out of it. It will affect that large enterprise if they roll out their new product "Yearning 4 Mines: Gatcha Gig-work For Kids."
Most of us install Docker just to run a project locally, and is part of a long checklist of things to install. We can't expect everyone to be an expert on the hundreds of apps/tools/packages that get installed on a machine. It's like expected people to read, and understand, all the terms of service shoved in front of us on a daily basis.
> The docker group grants root-level privileges to the user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.
No, because a malicious AI agent could just replace the sudo binary in your path with one that collects your password and uses it to execute arbitrary code as root. Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.
Once I noticed that models will treat lack of superuser access as an obstacle I moved all of the agent crap to its own machine. Watching some mid-tier offering chain together tools like its a gorilla escaping the zoo and I'm just not going to deal with that situation.
I'm more worried about my `~/.aws` and `~/.ssh` folders. People who use IDE-based AI tooling with IDEs that support dev-containers have no excuse for not leveraging dev containers, both for preventing agents losing your data and defending against secrets-harvesting supply-chain attacks
It's why all of my agent run in a vm. I refuse to have it run on my own machine. Claude code once managed to render the vm unbootable, I was back in action 5 minutes later after regenerating the vm
I recently took the risk there by having it run xattr commands to fix some MacOS bug with Tahoe that broke auto update for what seems like all software.
> Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.
Using open-source (non-proprietary) software won’t necessarily save you either. XZ is open-source and it was basically dumb luck that we weren’t all infected. Same with the myriad exploits to NPM.
Ok but in this case the problem wasn't the AI agent - the AI agent merely took advantage of this prior problem in the first place. For instance, if docker group were not superuser-like, that issue could not have happened.
> Nothing short of sandboxing everything or just never using AI agents
But the problem was not the AI agent.
Sandboxing is quite neat though; I remember on GoboLinux the idea of AlienFS to have every application run in a sandboxed manner, so it would only see other programs it needs, but never more than that. I consider it a better engineering focus to have this as minimal layer, even outside of security-related concerns.
It could just alias sudo on your ~/.bashrc. No need to replace the actual file on /usr/bin/sudo or wherever you have it. I would only need to be able to run arbitrary code as you.
Sigh. What ever happened to the principle of least privilege and why arent we applying it to AI agents. They ought to be locked in a box and not capable to act outside designated task.
rootless docker's networking (slirp4netns) is still terribly buggy and in edge cases often locks up using 100% CPU until you discover that your laptop is a lapwarmer and kill it
This but unironically. There's no way to ensure that nobody overwrote your .profile or .bashrc with a backdoored sudo that steals your password, or runs your command and then runs an evil command afterwards.
It is. That's why SELinux and AppArmor were invented.
Instead of having "root" and "user", both of these provide sets of permissions that can be granted to apps.
In this case, SELinux would've stopped this. Codex could've still relabelled the files when mounting but this can be blocked for sensitive directories like /etc.
This feels like using a computer is inherently unsafe.
On the plus side, once we outlaw them we'll shut down the ability for conspiratorial thinking to spread easily and the world will slowly heal from the last couple of decades (the previous one in particular).
Hooray! We're finally doing something about the harms of social media. Smash your computer today!
It's already here, mobile OSes are just computers with ton of guardrails and you can't do whatever you want with it, for the sake of security. I mean we almost got an Android where you can't install the APK you want.
i don't see how it's a design mistake, linux allows more footguns in general to not decrease utility. Allowing you to manually give root prompt access (with warnings!) to a non-root user is one of them.
you can also just not run docker as root and not add normal users to the docker group
That's true, the majority of people probably install software without much thinking; but it's also true that it's always better to have at least some high level understanding how the specific piece of software works. What access the given software has, will it send something over the network or work locally; that kind of stuff.
As for Docker, I would assume everyone who ever tried to bind-mount a volume for writing from inside the container (on Linux*) then were surprised to see root-owned files in their bind-mounted directory. For me personally, that was the moment I realized that containers, by default, have root access to the filesystem. No written warning serves better than the need to chown some root-owned files.
* Not on macOS. On macOS Docker basically runs in a VM, and there's no root access to the host filesystem from what I understand.
Docker relies fundamentally on the Linux kernel. Since macOS does not have a Linux kernel, you have to run Linux in a VM first and then run Docker on top of that.
So, you may get filesystem access inside the VM. Breaking out of the VM may be a different matter.
I primarily use Incus for all container stuff, not Docker. Is problematic if I want to e.g. use a docker-compose file, but I (think) it protects against these things because incus allows me to create a vm and not a container if I really need that level of isolation.
To be fair, I struggled since forever to understand this root group thing and didnt bother to add to docker group. This workaround give me a better understanding, like seeing someone cut themselves on a scissor
The very basic thing about software engineering is to know what the f you're using to build your project. You don't need to be an expert but if you're blindly installing whatever you want on your machine from a "checklist of things to install" without absolutely having no idea what the things being installed are, it is 100% on you. You don't need to be an "expert" to understand this, you need to be "somewhat competent," and that is a very low baseline tbh.
> Most of us install Docker just to run a project locally
If you're on linux can I encourage people to move to systemd?
I'll admit, systemd is a bit more annoying, but the main annoyance is that there aren't the pre-built images that you can just set and go. That same capability exists with systemd (via `importctl` and `machined`), but those configurations don't already exist. But on the plus side, I've been working with systemd since pre-LLM days and I feel that they are pretty good at dealing with these configurations[0]. Now, with that out of the way...
Systemd already is working with your OS. So you get nice things like virtual machines (`systemd-vmspawn`), containers (`systemd-nspawn`), and portables[1] (`systemd-portabled`) (not to mention `homed`!). I've found these to be fairly easy to setup and quite natural if you're already used to the linux ecosystem. I've never been great at docker, but these have felt much more natural to me. So different strokes for different folks. There's definitely a learning curve, but that's also true for docker or any other container system. Importantly, I find security easier to handle with systemd because I can use `systemd-analyze` and the control settings are almost identical across VMs, spawns, and portables. So makes for less learning and greater control.
Definitely not for everybody, but I think is also a tool that's underappreciated.
[0] And I don't feel this way about bash scripting! The advantage here is that these systemd configuration files are fairly boilerplate. Enough that I stash templates in my dotfiles and copy paste them when I build new services, timers, machines, whatever. So perfect type of LLM task. 90% of the time. But hey, we're also on HN and I'm talking to the nerds. Systemd isn't for everyone
EDIT: I very frequently will spawn a machine to run a program that's on a different base distro. Not because I can't run/don't know how to run debs or rpms on arch based distros (I do), but because frankly, it is often easier to just spawn a container after I've already made the first image (cloning images is trivial).
Look at the man pages for `machinectl` (then `systemd-nspawn`, `systemd-vmspawn`, and if you want `systemd-portabled`). This is a replacement for docker.
The problem is that the tooling for creating, importing, and managing images is not as good with systemd vs Podman/Docker. There's also no clear path to import images from the Docker ecosystem, at least as far as user experience goes. I know how to do it, but the number of extra steps involved always drives me back to Podman.
I don't really find them that bad but I'm still going to maintain my "different strokes for different folks" position. Might be bad for you and good for others. More options isn't a bad thing
The systemd suite of container tools treat containers like mini VMs and expect a full init system. They are not designed for ephemeral single-process app containers like docker containers.
There's plenty of container technologies and I'd be happy to see more of them used. Podman isn't for me, but it is a great option for others. Regardless, I think it is relatively unknown that systemd can be used for creating containers.
Good to know, I'm on Linux, switching our dev/stg/prod servers over to it partly because we had all this workaround mechanics in place so that "apt update" updating docker packages wouldn't restart services (we typically don't rotate machines out of the load for just an apt update). Podman + quadlets conversion was not terribly hard, and has eliminated this issue.
That sounds terrible! Feels like your LLM agent probably has more control over your computer than you. Can't imagine being confined to a prison like that, but I suppose there are other aspects (monetary or otherwise) of the job that make up?
Given that someone wrote this up directly as a recipe for agents to follow, and put it on the WWW where it has been scraped many times since 2025 no doubt, it's not that amazing.
This. I am running Claude in its own QEMU VM, it has git access to my project only if I explicitly unlock the ssh key for it. The other day I realized it trying to push a change, it didn't have permission, so it went looking for "workarounds" and found I had a github cli session and tried to use that, luckily the creds for that was also read scoped. But the point is, if I did not give permission and it sees I did not give permission, it should not try to find a workaround/exploit autonomously.
I dont think Claude itself needs much, its more like what you do with it. In my case it is doing some gradle builds and java tests with some postgres docker containers inside the vm so I gave it max 8G RAM with 4 cores and have no issues. I share my workspace folder (with virtiofs and also the user home so I can rebuild the vm from scratch and keep settings) because I like my tools on the host and my full creds are outside and I didnt want to keep syncing branches. I access it with ssh (with passt). So far no real issues.
Late edit, I wanted to clarify I do not share my user home, but the VM user home for backups, thats separate user that does not have my own users credentials etc
I don't really know of any distro that doesn't do that. All of Docker Inc. default installs and all of distros I know of don't automatically add you to the docker group. docker.com instructions has the infamous "linux post-install instructions" that explain and walk you though it.
The tragedy is of course that when security and usability collide, 80/20 rule will apply where 80% of people will pick usability over security. I have worked with many with the title >= "Senior Engineers" who saw that page, read the explanation, and still had no idea what the ramifications of their changes were. "Yeah sure it said any user in the docker group will be able to get root on the host, but aren't containers isolated?"
That’s the mental model that works for people, specifically those that come from VM workflow.
Ironically that’s how Docker works on every platform where it’s running a non-native OS. On macOS that’s how all images are run. Linux on Linux is the only Docker combination that is particularly problematic from a security perspective.
Virtualisation has advanced greatly since docker was introduced, if your running in local hardware that’s supports virtualisation, Docker should be running images fully virtualised. There is no good reason to use the OS kernel for most use cases as the performance impact is negligible. If you need kernel access there are better options, like systemd containers.
I agree that virtualization has seen great advances. Kata containers on k8s are almost (not quite 100%) drop in replacement. Regardless those last 10% remain a problem.
I run a personal server for few open source applications for personal use. I was thinking with all the supply chain attacks, and how carelessly I run `docker pull`s to update things I should probably consider hardening things a bit. I thought before jumping to full virtualization with Kata I can easily try gvisor/runsc first. Only to realize that DNS resolution is completely different with runsc vs runc and had to switch back.
Another sticking issue with virtualization is resource allocation. With namespace docker you can easily oversubscribe each container CPU/memory and rely on the single kernel letting individual containers burst as needed. With full virtualization this is still a big problem. Even with balloon devices and dynamic memory and CPU etc, the resource allocation is still not optimal. On a basic 8 core/16GB machine you can run 1 or 2 dozen services and things generally workout fine. Trying to run each of those in a virtualized VM you suddly can maybe run 6 or 7 maybe. There is no way to tell VM 3 kernel to drop its file system cache because VM 6 needs to load a large file in memory. Even if you script it out, now VM 3 is slow because it dropped all its cache while VM 6 finished processing 3 hours ago. These are not unsolvable problems, but despite how far virtualization has come, are still friction points.
Not to mention issues like sharing hardware devices (GPUs, disks, USB devices etc) between multiple VMs
That's not relevant. If you have access to the Docker daemon running as root, whether it's over a Unix socket or a TCP socket, you effectively have root.
Which ones are you thinking of? It feels to me like all the open source models I've seen lately are still pushed by corporate entities who don't want the legal blowback.
I can't really think of a new open source model that's "by the people, for the people" in the sense of a crowd-funded/trained model.
I attended a specialized math and science program (MaCS) in the TDSB. It was gutted by removing selective admissions in favour of a lottery, precisely because of the report you've cited.
The "levelling" is real in Canada and good private schools often manage to skip multiple grade levels.
Funnily enough, I've seen the opposite in the USA. My highly driven American friends somehow manage to get entire associate's degrees before finishing high school, which is unthinkable in Canada.
> “They decided to put ideology ahead of student achievement,” said Yu. “In reality, it's hurting everyone, including the equity deserving students that are there but [who] would not thrive in that sort of environment,” he said.
If Midjourney says "maybe you have cancer" but your doctor doesn't take it seriously, you might sue if you do end up with cancer. You might even win, regardless of whether "wait and see" was the right approach.
Meanwhile, if your doctor gives you an unnecessary CT scan that rules out cancer, hospital both earns $$$ and the doctor doesn't face legal consequences. Your increased chance of cancer risk from the radiation isn't something you can realistically sue over.
reply