That already exists, it's called Common Crawl[1], and it's a huge reason why none of this happened prior to LLMs coming on the scene, back when people were crawling data for specialized search engines or academic research purposes.
The problem is that AI companies have decided that they want instant access to all data on Earth the moment that it becomes available somewhere, and have the infrastructure behind them to actually try and make that happen. So they're ignoring signals like robots.txt or even checking whether the data is actually useful to them (they're not getting anything helpful out of recrawling the same search results pagination in every possible permutation, but that won't stop them from trying, and knocking everyone's web servers offline in the process) like even the most aggressive search engine crawlers did, and are just bombarding every single publicly reachable server with requests on the off chance that some new data fragment becomes available and they can ingest it first.
This is also, coincidentally, why Anubis is working so well. Anubis kind of sucks, and in a sane world where these companies had real engineers working on the problem, they could bypass it on every website in just a few hours by precomputing tokens.[2] But...they're not. Anubis is actually working quite well at protecting the sites it's deployed on despite its relative simplicity.
It really does seem to indicate that LLM companies want to just throw endless hardware at literally any problem they encounter and brute force their way past it. They really aren't dedicating real engineering resources towards any of this stuff, because if they were, they'd be coming up with way better solutions. (Another classic example is Claude Code apparently using React to render a terminal interface. That's like using the space shuttle for a grocery run: utterly unnecessary, and completely solvable.) That's why DeepSeek was treated like an existential threat when it first dropped: they actually got some engineers working on these problems, and made serious headway with very little capital expenditure compared to the big firms. Of course they started freaking out, their whole business model is based on the idea that burning comical amounts of money on hardware is the only way we can actually make this stuff work!
The whole business model backing LLMs right now seems to be "if we burn insane amounts of money now, we can replace all labor everywhere with robots in like a decade", but if it turns out that either of those things aren't true (either the tech can be improved without burning hundreds of billions of dollars, or the tech ends up being unable to replace the vast majority of workers) all of this is going to fall apart.
Their approach to crawling is just a microcosm of the whole industry right now.
Thanks for the mention of Common Crawl. We do respect robots.txt and we publish an opt-out list, due to the large number of publishers asking to opt out recently.
So perhaps the AI companies will go bankrupt and then this madness will stop. But it would be nice if no government intervenes because they are "too big to fail".
Are you sure it's the AI companies being that incompetent, and not wannabe AI companies?
What I feel is a lot more likely is that OpenAI et al are running a pretty tight ship, whereas all the other "we will scrape the entire internet and then sell it to AI companies for a profit" businesses are not.
In the past, I've heard recommendations not to use remote Time Machine over SMB directly, but rather to create an APFS disk image on a remote server and then backup to that as if its an external hard drive.
Supposedly, doing that eliminates a lot of the flakiness specific to SMB Time Machine, and while I haven't tested it personally, I have used disk images over SMB on macOS Tahoe recently, and they actually work great (other than the normal underlying annoyances of SMB that everyone with a NAS is mostly used to at this point).
The new ASIF format for disk images added in Tahoe actually works very well for this sort of thing, and gives you the benefits of sparse bundle disk images without requiring specific support for them on the underlying file system.[1][2] As long as you're on a file system that supports sparse files (I think pretty much every currently used file system except FAT32, exFAT, and very old implementations of HFS+), you get almost native performance out of the disk image now. (Although, again, that's just fixing the disk image overhead, you still have to work around the usual SMB weirdness unless you can get another remote file system protocol working.)
I tried moving to NFS, but the level of complexity of NFS auth is just comical. I gave up after trying to set up a Kerberos server on the Synology that I was trying to access. It's too much.
Using unauthenticated NFS, even on a local network, is too dodgy imo.
iOS has had pretty decent audio format support for a few years now: even though you can't directly import FLAC files to iTunes/Music, they are supported in the OS itself since 2017 and play fine both in Files and in Safari. The other big mainstream formats (WAV, AIFF, MP3, AAC, and ALAC) have been supported for years, and even Opus finally got picked up in 2021.
About the only non-niche audio format that isn't supported natively on Apple platforms at this point is Vorbis, which was fully superseded by Opus well over a decade ago. Even then, I believe it's possible to get Vorbis support in iOS apps using various media libraries, although I'm sure Apple frowns upon it.
I'd really love to know what's causing that incompatibility.
This has been the advantage, and the drawback, of Signal's security model from the start.
Everything on Signal (at least the "original" design from a few years ago, this has started to be adjusted with the introduction of usernames and now backups and eventually syncing) is end-to-end encrypted between users, with your original phone acting as the primary communication node doing the encryption. Any other devices like desktops and tablets that get added are replicating from the original node rather than receiving new messages straight from the network.
This offers substantial privacy and security guarantees, at the cost of convenience and portability. It can be contrasted with something like iMessage, before Messages in iCloud was implemented, where every registered device is a full node that receives every new message directly, as long as they're connected at the time that it's sent.
Today's addition brings Signal to where iMessage was originally: each device is backing up their own messages, but those backups aren't syncing with one another. Based on the blog post, the goal is to eventually get Signal to where iMessage is today now that Messages in iCloud is available: all of the devices sync their own message databases with a version in the cloud, which is also end-to-end encrypted with the same guarantees as the messages themselves, but which ensures that every device ends up with the same message history regardless of whether they're connected to receive all of the messages as they come in. Then, eventually, they seem to also intend to take it one step farther and allow for arbitrary sync locations for that "primary replica" outside of their own cloud storage, which is even better and goes even further than Apple's implementation does.
If done well, I actually quite like the vision they're going for here. I'm still frustrated that they wouldn't just port the simple file backup feature from Android to the other platforms, even as just a stopgap until this is finished, but I think that the eventual completion of this feature as described will solve all of my major concerns with Signal's current storage implementation.
Okay so here's the argument I've heard: if arbitrary replacements of the lid sensor were possible, it would be feasible to create a tampered sensor that failed to detect the MacBook closing, thus preventing it from entering sleep mode.
This could then be combined with some software on the machine to turn a MacBook into a difficult to detect recording device, bypassing protections such as the microphone and camera privacy alerts, since the MacBook would be closed but not sleeping.
Additionally, since the auto-locking is also tied to triggering sleep mode, it would be possible to gain access to a powered off device, switch the sensors, wait for the user to attempt to sleep mode the device, and then steal it back, completely unlocked with full access to the drive.
Are these absolutely ridiculous, James Bond-tier threat assessments? Yes, absolutely. But they're both totally feasible (and not too far off from exploits I've heard about in real life), and both are completely negated by simply serializing the lid sensor.
Should Apple include an option, buried in recoveryOS behind authentication and disk unlock steps like the option to allow downgrades and allow kernel extensions, that enables arbitrary and "unauthorized" hardware replacements like this? Yes, they really should. If implemented correctly, it would not harm the security profile of the system while still preventing the aforementioned exploits.
There are good security reasons for a lot of what Apple does. They just tend to push a little too far beyond mitigating those security issues into doing things which start to qualify as vendor lock-in.
I really wish people would start to recognize where the line should be drawn, rather than organizing into "security of the walled garden" versus "freedom of choice" groups whenever these things get brought up. You can have both! The dichotomy itself is a fiction perpetuated to defend the status quo.
The line should be drawn by the owner of the device.
As the user and owner of the product, I should be the sole decider about my own security posture, not some company who doesn’t know my use case or needs.
It’s crazy how we’ve managed to normalize the manufacturer making these kinds of blanket decisions on our behalf.
Yes it’s wild. Imagine if we decided that people can’t be relied on to install good locks for their doors, so we gave the government responsibility for locking and unlocking your door every time you wanted to leave your house.
A lid sensor is just so peripheral. Where do the vendor lock-ins end?
A more accurate analogy, is like a lock installed on your door by a locksmith that uses proprietary parts available only through locksmiths. Which is exactly how a lot of locks work.
Proprietary technology exists in a lot of places, Apple didn't invent this.
Apple is worse than a government. They have more money and reach than many governments and unlike many government officials, the public doesn't have the power to vote the heads of apple out of office or vote for who they want as a replacement.
Apple didn't invent proprietary technology, but they leverage the shit out of it in consumer hostile ways just to take even more money from people.
Governments have a monopoly on the use of force, and they exercise it to compel their citizens to do things whether or not they want to. For example, I have to pay taxes, and if I don't, they will use force against me.
Your relationship with Apple is very different. If you don't like Apple, you can just simply not buy or use their products. You have a choice and they have no way of compelling you otherwise.
The inability to use force doesn't make corporate power any less powerful--it only makes it a different kind of power. Yes, BigTech cannot arrest me or throw me in jail, but that doesn't mean that they don't wield other kinds of enormous power over my day-to-day life.
And unlike my (technically democratically elected government), corporations do not have to answer to the people they exert their power over.
I'm not trying to say that big tech doesn't have any sort of power at all that significant, of course they do. They certainly have a lot of control over information and how it shared. But I think that is unequivocally a lesser power than being able to imprison someone or put them to death. The fact that some small number of government officials are elected might be a rationale for that power, but it doesn't decrease it in any way.
Yea, that's a much better analogy. We don't want the lock vendor to decide how and when we lock our doors and how we fix them when they break. We don't want our stove vendor to decide what food we're allowed to cook, how many burners can be running at once, and what parts we use to repair it. We don't want our car manufacturer to decide where we can drive our car and who repairs it.
Yet, somehow, when it comes to technology products, we accept the manufacturer butting in to tell us how not to use them, and how not to repair them.
My stove, my car, and my locks are all opinionated in their design and use proprietary parts. None of them were designed to my personal requirements. Many of the products that I buy do in fact, not work exactly how I want them to, nor do they facilitate my desire to change them.
I can't name a single product in my house that uses any sort of open hardware design, except for the things, I've 3D printed or built myself.
A better analogue then would be that the developer who built your house insists on a specific type of lock.
There’s a whole repairability movement going on to maintain access to third party replacement parts for cars and appliances. This is a recent design choice that is being enforced by manufacturers. Historically, people have been able to repair everything they owned. Locking everything down is bad for consumers.
Developers normally do pick the parts that come on a house when they build it.
I understand arguments for repairability, and in most cases, I agree with them. But these things aren't boolean situations where things are either repairable or they are not. There's a lot of nuance in how things are designed and how repairable they are as an inherent part of that design. Ultimately, I agree that artificial lock-in for no reason other than that lock-in is a bad thing for consumers. But not everything is really that simple.
> Historically, people have been able to repair everything they owned.
It all depends on how you define "able". Most people lack technical ability to repair most things for thousands of years. And most things that you own today you are permitted to repair to the best of your ability.
I dislike Apple's lock-in tactics, but I dislike gross fear-mongering exaggerations even more.
How'd we get to tyrannical government oversight from shitty corporate control? Sorry, I think I slipped on that slippery slope.
The better analogy would be "door lock vendor requires you to buy their door frame to make their door lock work with the security guarantees you chose to buy into."
Government should stay out of our private lives, but this kind of jumpy fear-mongering is what makes people lose focus, and when people are run by fear that's when the real psychopaths start taking advantage. Your fear mongering is creating the very government tyranny you're mongering about.
> As the user and owner of the product, I should be the sole decider about my own security posture, not some company who doesn’t know my use case or needs.
It's not so cut and dry though. The "user" and the "owner" of a product are not always the same person, but hardware security impacts the "user" more than the "owner".
How does Apple know the owner of the product has authorized the HW change?
There’s a secondary argument you could make here whereby because the replacements must be valid Apple parts that have uniform behavior and tolerances, the strength of the secondary market is stronger and Apple products have a stronger resale value as a result, because you’re not going to encounter a MacBook with an arbitrary part replaced that you as the second-hand buyer know nothing about (this is why the secondary market for cars doesn’t work without the ability to lookup the car history by VIN).
What happens when you indirectly cause the machine to fail by installing some shout 3rd party part? Are you still going to claim warranty? Walk into an Apple Store to ask for help?
Practically speaking, however, they are liable for the time to service those customers and diagnose product issues to determine that the customer was at fault. And, that extends to any future buyers of used devices. And, any resulting displeasure from customers, even though it wasn't Apple's fault.
These sorts of things are exactly the types of problems that exist in the used car market, for exactly the same reasons.
That car comparison doesn't work here. You can't be sure about the true history of a car, only what was reported.
When I replace a wheel bearing assembly in my driveway, you still can't see that by looking up my VIN. Nobody knows except myself and the person I bought the parts from.
Was it a dealer part? An OEM part? A poor quality replacement? Can't tell without looking.
This might actually support Apple's side of the argument, although I do not. I don't think we need some Carfax equivalent for MacBooks.
This might actually support Apple's side of the argument, although I do not. I don't think we need some Carfax equivalent for MacBooks.
In some ways, Apple's scheme is better than Carfax. In other ways, it's worse.
It's worse because you can't get access to the repair history of a device.
It's better because you can actually have a reasonable degree of confidence that no "driveway repairs" have taken place since Apple's scheme is not known to be broken.
I think we should stop using "driveway repairs" as a derogative term. There's nothing wrong with a car owner repairing their own car. Years ago, that was a very usual, normal thing to do. I replaced my own wheel bearings in my garage, and have been driving on them for 5 years. It's not that difficult, and doing it yourself doesn't make your car unsafe or defective.
Kind of scary how "repairing your own things yourself" has fallen so far out of fashion. We should be applauding and encouraging people to build these kind of skills, not insulting them.
I would have thought most people here are doing much more complicated work all day.
All four bearings are part of an assembly that bolts in. 8 or 12 bolts depending on position. I'm lucky that I don't even need a press.
The wheel comes off (5 bolts), the brakes come off (2 bolts), the axle/hub bolt comes out (1 bolt), and then on the front there are four bolts holding the assembly to the car. On the rear, nothing holds it on except that hub bolt.
Use a torque wrench to get them to spec. The kits came with new bolts. The axle bolts go on tight tight.
This is my biggest complaint with the strict "my device, my rules" people.
I want Apple to lock down my device to customization, repairs, etc..
I know I am never going to install an app through means other than the app store, even if I could. I know I'm never going to repair my device through anyone other than Apple, even if I could. I want to know that my device will be a $1,000 paperweight to anyone who steals it.
I want to pay Apple to ensure there are no "driveway repairs".
A number of years ago I accidentally ended up with a second hand iPhone with a shitty "fake" screen repair. I had no way of knowing it wasn't an Apple screen. But it fucked me over as soon as it started failing a couple months after I bought it.
I get tired of the people demanding that a company, with willing, paying customers, isn't allowed to protect their customers because they want something the company doesn't offer. Fuck right off with that shit and buy from a company that does offer that.
I had a similar experience myself paying for screen repair in SF and getting back a phone with a butchered display. Why wouldn’t you get mad for spending money and not having your expectations met?
If you need consumer protection laws then clearly reputation isn’t worth much. The issue with reputation is that society has grown so large and impersonal that we’re constantly facing interactions with unknown people.
I'm sorry for my candor, but your argument is so silly, it rubs me the wrong way.
Laws are how society operates.
If you need traffic rules (those are defined by laws fyi) then clearly individual's ability to drive isn't worth much. Let's abolish car ownership, make Apple operate all ground transportation and prohibit anyone else from deciding where Apple-operated cars go, what are operational hours and where the stops are.
> Let's abolish car ownership, make [car manufacturers] operate all ground transportation and prohibit anyone else from deciding where [manufacturer]-operated cars go, what are operational hours and where the stops are.
Shhhhhh! Don’t give them any more bad ideas or they might actually do it.
She is however the target of pretty much every financial scam on the planet, many of which rely on convincing folks to hand over the keys to their (digital) castle...
I'm not aware of any that this particular sensor would mitigate. I think the idea that security is only for people targeted by nation-states is not a realistic view of the modern world (and, moreover, if we decide that normal people don't need enhanced security measures, it becomes trivial to identify dissidents by the fact that they implement security measures).
My dude, an Indian is going to call your Apple-using grandmother and tell her that he works for "the Microsoft" and he needs her to give him all her banking details, or go to a bitcoin ATM, or buy a stack of $500 gift cards, and she's going to do it.
The sensor in her macbook lid does not matter! Get real.
You're wack. Do you think a locked down laptop lid sensor will stop them from spiking your tea with polonium, or shooting you with a ricin BB, or breaking into your home when you're asleep and jabbing a needle into your neck while holding a pillow over your face, or kidnapping you and breaking your bones with a sledge hammer until they've gotten their rocks off?
This laptop lid threat is fantasy. Get fucking real.
Another answer, mine, is that one grandmother flew bombers, jets, spitfires, etc. in WWII and ran a post war international logistics company after that. The other did "stuff" with math.
ie. Both capable of understanding a security posture.
How about your grannies?
You might want to ask well formed questions in future, on a site such as HN the set of all grandmothers is hardly homogeneous.
It's not that crazy when people seem to cheer for a nanny state at every turn. Specially if said nanny state bombards them with propaganda about all the dangers they'll face if they just don't "comply".
1984 references may have seen farfetched but after the suppression of rights using covid as an excuse people have little to no recourse to claim control back. Apple was always famous for their walled garden and tight control, but we have Google becoming like apple (can't install things in your device unless you go to them with your private details), ID to track your movements because "protect the children" (effectively blocking news even), chat control (very similar to installing a camera in your home and recording all your conversations).
Corps and governments are relying on each other to strengthen their control and it's not a surprise.
Keeping a victim device unlocked when the lock state is responsible for encryption key state is a totally legitimate risk.
With that being said, I don’t think Apple see this specific part as a security critical component, because the calibration is not cryptographic and just sets some end point data. Apple are usually pretty good about using cryptography where they see real security boundaries.
Don't invent reasons for Apple to continue to have a stranglehold over their monopoly of critical computing infrastructure.
Companies as big as Apple and Google that provide such immensely important platforms and devices should have their hands tied by every major government's regulatory bodies to keep the hardware open for innovation without taxation and control.
We've gone from open computing to serfdom in the last 20 years, and it's only getting worse as these companies pile on trillions after trillions of nation state equivalent market cap.
The government regulators also have an interest in knowing the laptops they buy for eg the NSA have authenticated parts to avoid supply chain attacks.
If you're selling cell phones you already spend plenty of time satisfying regulators and vendors from all over the world. The cell phone companies aren't the ones with power here. (In general tech people have no political power because none of them have any social skills.)
Supply chain attacks don't generally target the second hand market. Much more effective to upstream your attack to the vendor Apple buys parts from in China, and compromise every MacBook in one fell swoop
That's too discoverable to work. Supply chain attacks are by state actors who can interrupt specifically your order on its way to you and silently replace parts in it.
It doesn't need to be encrypted if it's one-time programmable. The calibration data is likely written into efuses which are physically burned and cannot be reset.
For the mic cut-off? My understanding is that it outputs an electrical signal that's routed to the audio codec that literally prevents the audio from getting to system memory in the same way a physical switch would. It autonomously, at an electrical level, disconnects the mic without OS or software intervention. As it cannot be programmed again, you would have to crack open the laptop and modify the PCB to override it.
Oh, I understand now - you're right, OTP sensor data does protect against a real threat model I hadn't considered before:
* A remote attacker gains whatever privilege lets them get to the sensor SPI.
* Without OTP calibration, the attacker could reprogram the sensor silently to report a different endstop, keeping the machine awake and the hard-cuts active.
* With OTP calibration, this is closed.
So perhaps it is more security-related than I initially thought.
I was more considering the counterfeit part / supply chain / evil maid scenario, where the fact that Apple's sensors are OTP is meaningless (since a replacement sensor doesn't need to be, plus, you could just put a microcontroller pretending to be a sensor in there since there's no actual protection).
Thanks, you made me think again and figure it out!
A properly gated, user-authorized override in recoveryOS or similar would give advanced users and third-party repair shops a legitimate path without blowing up the security model
If repair shops can buy the $130 calibration machine, presumably the super spy in this story (who for some reason couldn't steal the data while they were replacing the lid sensor, nor can they steal the data when the laptop's in use, but somehow can steal the data when it's idle with the lid down) can also get a calibration machine, and then deliberately set the zero point incorrectly.
“Sure, you can borrow my laptop. It’s fine. Take it home. I promise not to spy on you while the lid is closed. I promise not to record aaaaaany audio or anything! And I definitely won’t hear any conversation that contains information that I’ll use to stalk you later!”
There are a million ways that some nefarious person could spy on another, but at least this isn’t one of them.
And I am a very suspicious person, thanks to some eye opening experiences that I’ve had. When someone says that they want to do something that not a lot of people want to do, I immediately wonder how they will use that against myself or someone else. Because that has happened multiple times to me.
I also hate that I am suspicious of people who want to at least have the opportunity to fully own their devices; something that is perfectly reasonable to want, but I am. What would that additional ability do for them? What will they be capable of doing that they can’t do now? How and when will they use it to get what they want out of someone? Or out of me?
If you don’t think like this, I really envy you. For the longest time, every teacher, every supervisor, every commander, every non-familial authority figure I had until I was probably 35, used and manipulated me for the purpose of advancing themselves. Every single one. The ones in the military didn’t even attempt to hide it.
I’m so scarred because of people convincing me to help them screw me over that I no longer trust anyone who is concerned about things like laptop lid angle sensors. Because who are you trying to screw over and why does that angle sensor stand in your way?
> When someone says that they want to do something that not a lot of people want to do, I immediately wonder how they will use that against myself or someone else. Because that has happened multiple times to me.
I’m intrigued. Would you be comfortable sharing some of these real experiences here (with sensitive details fudged/removed)?
I'd rather not. They're very foggy memories now, and the ones that aren't are all attempted sexual abuse. Conmen are everywhere, and they will say things in the nicest most innocuous ways possible to sway you to do things for them. They'll do it over time, and they will very gradually ramp things up. "this is just a small change from that, what's the matter" ugh. people suck.
that is correct. my specific history pushes me in the direction where i suspect malevolence, though. yours might not. but let me tell you; people are absolutely capable of the worst things you can imagine, and if those people require your cooperation they will try the carrot long before they try the stick.
If you have access to my laptop long and deep enough to replace the hinge sensor with a fake one that prevents the lid from closing as a way to turn it into a recording device -- which of course would also require installing software on it -- instead of just putting a tiny microphone into it (or my bag), you are simultaneously a genius and dumb. And if you really are going to that level of effort, hoping that I don't notice my laptop failing to go to sleep when I close it so you might be able to steal it is crazy when you can 100% just modify the hardware in the keyboard to log my password.
Hell: what you really should do is swap my entire laptop with a fake one that merely shows me my login screen (which you can trivially clone off of mine as it happily shows it to you when you open it ;P) and asks for my password, at which point you use a cellular modem to ship it back to you. That would be infinitely easier to pull off and is effectively game over for me because, when the laptop unlocks and I don't have any of my data (bonus points if I am left staring at a gif of Nedry laughing, though if you showed an Apple logo of death you'd buy yourself multiple days of me assuming it simply broke), it will be too late: you'll have my password and can unlock my laptop legitimately.
> There are good security reasons for a lot of what Apple does.
So, no: these are clearly just excuses, sometimes used to ply users externally (such as yourself) and sometimes used to ply their own engineers internally (such as wherever you heard this), but these mitigations are simply so ridiculously besides the point of what they are supposedly actually securing that you simply can't take them seriously if you put more than a few minutes of thought into how they work... either the people peddling them are incompetent or malicious, and, even if you choose to believe the former over the latter, it doesn't make the shitty end result for the owner feel any better.
I can imagine a different attack vector: A malicious actor doing laptop repairs can absolutely replace the hinge sensor and install software on it. They could draw in people by offering cheaper prices, then steal their info or use it to setup more complex scams.
The counterpoint to this is that car body shops can also plant recording devices in your car. This is true, but the signal-to-noise ratio in terms of stealing valuable data is much lower. I don't have data to back this up, but I assume way more people use their laptops for online purchases and accessing their bank account than doing the same with phone calls in the car.
A repair worker can install software on it without replacing the sensor. Also add a tiny mic without installing the software. Or both.
I mean.. someone could replace your cars breakpads with pieces of wood or plastic, which would seemingly brake on the repair shop parking lot but fail horribly (burn and worse) when you needed them after. Somehow we still let people replace brake pads without having to program in the serial numbers.. for now.
> This could then be combined with some software on the machine to turn a MacBook into a difficult to detect recording device, bypassing protections such as the microphone and camera privacy alerts, since the MacBook would be closed but not sleeping.
Isn't this already possible if the MB is connected to a power source like a portable battery?
DESCRIPTION
caffeinate creates assertions to alter system sleep behavior. If no
assertion flags are specified, caffeinate creates an assertion to prevent
idle sleep. If a utility is specified, caffeinate creates the assertions
on the utility's behalf, and those assertions will persist for the
duration of the utility's execution. Otherwise, caffeinate creates the
assertions directly, and those assertions will persist until caffeinate
exits.
Installing software generally requires user permission. Replacing Hw can be done surreptitiously. At least that’s the strongman variant of the security argument.
As far as I know the mic is still shut off when the machine is set to clamshell mode. That's the point. You cannot use the mic when the lid is closed. It's a hardware cut-off, you cannot configure it in software. Hence my comment about the bug bounty.
How you can characterize this type of threat as a “James Bond” fantasy in 2025 is breathtaking.
The Federal government is forensically collecting phones during routine border crossings to see if you reposted Fat JD Vance memes. That’s publicly disclosed and well know.
I have no trouble believing that potential enemies of the state like the governor of California and his cabinet are bugged. If I were a person like that, I’d try to take supply chain countermeasures.
If we're talking Bond-tier assessments then Apple already sell a covert microphone: AirTags. They “have no microphone” according to product specs, but they do have a huge speaker, and a speaker and microphone are the same thing like a generator and motor are the same thing: https://in.bgu.ac.il/en/Pages/news/eaves_dropping.aspx
Just because a speaker can technically operate as a microphone doesn’t mean that AirTags would be capable of this. The speaker driver definitely doesn’t have any recording capability. The only reason the 3.5mm jack mentioned in your article is capable of this is because the jack has functionality to allow analog recording for mic/line in cases. No dedicated speaker driver would have this because it would be worthless and costly.
Hmm…do you have the in-browser DNS over HTTPS resolver enabled? I personally can't reproduce this, but I'm using DoH with 1.1.1.1.
I've noticed that both Chrome and Firefox tend to have less consistent HTTP/3 usage when using system DNS instead of the DoH resolver because a lot of times the browser is unable to fetch HTTPS DNS records consistently (or at all) via the system resolver.
Since HTTP/3 support on the server has to be advertised by either an HTTPS DNS record or a cached Alt-Svc header from a previous successful HTTP/2 or HTTP/1.1 connection, and the browsers tend to prefer recycling already open connections rather than opening new ones (even if they would be "upgraded" in that case), it's often much trickier to get HTTP/3 to be used in that case. (Alt-Svc headers also sometimes don't cache consistently, especially in Firefox in my experience.)
Also, to make matters even worse, the browsers, especially Chrome, seem to automatically disable HTTP/3 support if connections fail often enough. This happened to me when I was using my university's Wi-Fi a lot, which seems to block a large (but inconsistent) amount of UDP traffic. If Chrome enters this state, it stops using HTTP/3 entirely, and provides no reasoning in the developer tools as to why (normally, if you enable the "Protocol" column in the developer tools Network tab, you can hover over the listed protocol to get a tooltip explaining how Chrome determined the selected protocol was the best option available; this tooltip doesn't appear in this "force disabled" state). Annoyingly, Chrome also doesn't (or can't) isolate this state to just one network, and instead I suddenly stopped being able to use HTTP/3 at home, either. The only actual solution/override to this is to go into about:flags (yes, I know it's chrome://flags now, I don't care) and make sure that the option for QUIC support is manually enabled. Even if it's already indicated as "enabled by default", this doesn't actually reflect the browser's true state. Firefox also similarly gives up on HTTP/3, but its mechanism seems to be much less "sticky" than Chrome's, and I haven't had any consistent issues with it.
To debug further: I'd first try checking to see if EncryptedClientHello is working for you or not; you can check https://tls-ech.dev to test that. ECH requires HTTPS DNS record support, so if that shows as working, you can ensure that your configuration is able to parse HTTPS records (that site also only uses the HTTPS record for the ECH key and uses HTTP/1.1 for the actual site, so it's fairly isolated from other problems). Next, you can try Fastly's HTTP/3 checker at https://http3.is which has the benefit of only using Alt-Svc headers to negotiate; this means that the first load will always use HTTP/2, but you should be able to refresh the page and get a successful HTTP/3 connection. Cloudflare's test page at https://cloudflare-quic.com uses both HTTPS DNS records and an Alt-Svc header, so if you are able to get an HTTP/3 connection to it first try, then you know that you're parsing HTTPS records properly.
Let me know how those tests perform for you; it's possible there is an issue in Firefox but it isn't occurring consistently for everyone due to one of the many issues I just listed.
(If anyone from Cloudflare happens to be reading this, you should know that you have some kind of misconfiguration blocking https://cloudflare-quic.com/favicon.ico and there's also a slight page load delay on that page because you're pulling one of the images out of the Wayback Machine via
https://web.archive.org/web/20230424015350im_/https://www.cl... when you should use an "id_" link for images instead so the Internet Archive servers don't have to try and rewrite anything, which is the cause of most of the delays you typically see from the Wayback Machine. (I actually used that feature along with Cloudflare Workers to temporarily resurrect an entire site during a failed server move a couple of years back, it worked splendidly as soon as I learned about the id_ trick.) Alternatively, you could also just switch that asset back to https://www.cloudflare.com/img/nav/globe-lang-select-dark.sv... since it's still live on your main site anyway, so there's no need to pull it from the Wayback Machine.)
I've spent a lot of time experimenting with HTTP/3 and it's weird quirks over the past couple of years. It's a great protocol, it just has a lot of bizarre and weirdly specific implementation and deployment issues.
> What they're really afraid of is that people will read content using LLM inference and make all the ads and nags and "download the app for a crap experience" go away -- and never click on ads accidentally for an occasional ka-ching.
See, I don't think this is right either. Back during the original API protests, several people (including me!) pointed out that if the concern was really that third-party apps weren't contributing back to Reddit (which was a fair point: Apollo never showed ads of any kind, neither Reddit's or their own) then a good solution would be to make using third-party apps require paying for Reddit Premium. Then they wouldn't have to audit all of the apps to ensure they were displaying ads correctly and would be able to collect revenue outside of the inherent limitations of advertising.
Theoretically, this should have been a straight win for Reddit, especially given the incredibly low income that they've apparently been getting from ads anyway (I can't find the report now so the numbers might not be exact, but I remember it being reported that Reddit was pulling in something like ~$0.60 per user per month versus Twitter's slightly better ~$8 per user per month and Meta's frankly mindblowing ~$50 per user per month) but it was immediately dismissed out of hand in favor of their way more complicated proposal that app developers audit their own usage and then pay Reddit back.
My initial thoughts were either that the Reddit API was so broken that they couldn't figure out how to properly implement the rate limits or payment gating needed for the other strategy (even now the API still doesn't have proper rate limits, they just commence legal action anyone they find abusing it rather than figure out how to lock them out; the best they can really do is the sort of basic IP bans they're using here), or the Reddit higher-ups were so frustrated that Apollo had worked out a profitable business model before them that they just wanted to deploy a strategy targeted specifically at punishing them.
But it quickly became clear later that Reddit genuinely wasn't even thinking about third-party apps. They saw dollar signs from the AI boom, and realized that Reddit was one of the largest and most accessibly corpuses of generally-high-quality text on a wide variety of topics, and AI companies were going to need that. Google showing an intense dependency on Reddit during the blackout didn't hurt either (yes, at this point I genuinely believe the blackout actually hurt more than it helped by giving Reddit further leverage to use on Google, hence why they were one of the first to sign a crawler deal afterwards).
So they decided to use any method they could think of to lock down access to the platform while keeping enough people around that the Reddit platform was still mostly decent enough to be usable for AI training and pivoted much of their business to selling data. All of this while claiming, as they're still doing today with the Internet Archive move, that this is somehow a "privacy measure" meant to ensure deleted comments aren't being archived anywhere.
The same thing basically happened with Stack Exchange, except they had much less leverage over their community because the entire site was previously CC licensed and they didn't have any real authority to override that beyond making data access really annoying.
The good news is that it really does seem like "injest everything" big model AI is the least likely to survive at this point. Between ChatGPT scaling things down massively to save on costs with the GPT-5 update and the Chinese models somehow making do with less data and slower chips by just using better engineering techniques, I highly doubt these economics around AI are going to last. The bad news is that, between stuff like this and the GitHub restructuring today, I don't thing Big Tech has any plans on how they're going to continue functioning in an economy that isn't entirely based on AI hype. And that's really concerning.
The infamous Dropbox comment[0] actually didn't even cite rsync; it recommended getting a remote FTP account, using curlftpfs to mount it locally, and then using SVN or CVS to get versioning support.
The double irony of that comment is that pretty much all of those technologies listed are obsolete now while Dropbox is still going strong: FTP has been mostly replaced with SFTP and rsync due to its lack of encryption and difficult to manage network architecture, direct mounting of remote hosts still happens but it's more typical in my experience to have local copies of everything that are then synced up with the remote host to provide redundancy, and CVS and SVN have been pretty much completely replaced with Git outside of some specialist and legacy use cases.
The "evaluating new products" xkcd[1] is extremely relevant, as is the continued ultra-success of Apple: developing new technologies, and then turning around and marketing those technologies to people who aren't already in this field working on them are effectively two completely different business models.
It's also not the same thing as Dropbox was offering: that's a description of a network drive, but the key thing about Dropbox is that it's a syncing engine. It's a much harder thing to do, but with very big benefits: much faster (since it's just reading off disk) and offline access.
The desktop issue was an intentional change that happened sometime in like 2017 or so.
The original functionality of the quality selector was to throw out whatever video had been buffered and start redownloading the video in the newly selected quality. All well and good, but that causes a spinning circle until enough of the new video arrives.
The "new" functionality is to instead keep the existing quality video in the buffer and have all the new video coming in be set to the new quality. The idea is that you would have the video playing, change the quality, and it keeps playing until a few seconds later the new buffer hits and you jump up to the new quality level. Combined with the fact that YouTube only buffers a few seconds of video (a change made a few years prior to this; back in the Flash era YouTube would just keep buffering until you had the entire video loaded, but that was seen as a waste of both YouTube's bandwidth and the user's since there was always the possibility of the user clicking off the video; the adoption of better connection speeds, more efficient video codecs, and widespread and expensive mobile data caps led to that being seen as the better behavior for most people) and for most people, changing quality is a "transparent" operation that doesn't "interrupt" the video.
In general, it's a behavior that seems to come from the fairly widespread mid-2010s UX theory that it's better to degrade service or even freeze entirely than to show a loading screen of some kind. It can also be seen in Chrome sometimes on high-latency connections: in some cases, Chrome will just stop for a few moments while performing DNS resolution or opening the initial connections rather than displaying the usual "slow light gray" loading circle used on that step, seemingly because some mechanism within Chrome has decided that the requests will probably return quickly enough for it to not be an issue. YouTube Shorts on mobile also has similar behavior on slow connections: the whole video player will just freeze entirely until it can start playing the video with no loading indicator whatsoever. Another example is Gmail's old basic HTML interface versus the modern AJAX one: an article which I remember reading, but can't find now found that for pretty much every use case the basic HTML interface was statistically faster to load, but users subjectively felt that the AJAX interface was faster, seemingly just because it didn't trigger a full page load when something was clicked on.
And, I mean, they're kind of right. It's nerds like us that get annoyed when the video quality isn't updated immediately, the average consumer would much rather have the video "instantly load" rather than a guarantee that the video feed is the quality you actually selected. It's the same kind of thought process that led to the YouTube mobile app getting an unskippable splash screen animation last year; to the average person, it feels like the app loads much faster now. It doesn't, of course, it's just firing off the home page requests in the background while the locally available animation plays, but the user sees a thing rather than a blank screen while it loads, which tricks the brain into thinking it's loading faster.
This is also why Google's Lighthouse page loading speed algorithm prioritizes "Largest Contentful Paint" (how long does it take to get the biggest element on the page rendered), "Cumulative Layout Shift" (how much do things move around on the page while loading), and "Time to Interactive" (how long until the user can start clicking buttons) rather than more accurate but "nerdy" indicators like Time to First Byte (how long until the server starts sending data) or Last Request Complete (how long until all of the HTTP requests on a page are finished; for most modern sites, this value is infinity thanks to tracking scripts).
People simply prefer for things to feel faster, rather than for things to actually be faster. And, luckily for Internet companies, the former is usually much easier to achieve than the latter.
> In general, it's a behavior that seems to come from the fairly widespread mid-2010s UX theory that it's better to degrade service or even freeze entirely than to show a loading screen of some kind.
> It's the same kind of thought process that led to the YouTube mobile app getting an unskippable splash screen animation last year; to the average person, it feels like the app loads much faster now. It doesn't, of course, it's just firing off the home page requests in the background while the locally available animation plays, but the user sees a thing rather than a blank screen while it loads, which tricks the brain into thinking it's loading faster.
So they decided it's better to show lower-quality content (or not update the screen) than a loading screen, and it's the same school of thought that led to a loading screen being implemented? I agree both examples could be seen as intended to make things "feel" faster, but it seems like two different philosophies towards that.
(Also, I remember when quality changes didn't take effect immediately, but I've been seeing them take effect immediately and discard the buffer for at least the past few years-- at least when going from "Auto" that it always selects for me to the highest-available quality.)
> The idea is that [...] a few seconds later the new buffer hits and you jump up to the new quality level.
Except "a few seconds later" can become minutes. Sometimes it just keeps going at the lower quality while the UI claims to play a noticeably higher resolution than the one actually playing. To be clear, I don't care that the "automatic" quality is actually automatic, I care that the label blatantly lies about which resolution is playing. "Automatic (1080p60)" shouldn't look like a video from 2005.
> The actual scary stuff is the dilution of expertise, we contributed for a long time to share our knowledge for internet points (stack overflow, open source projects, etc), and it has been harvested by the AIs already, anyone that pays access to these services for tens of dollars a month can bootstrap really quickly and do what it might had needed years of expertise before.
What scares me more is the opposite of that: information scarcity leading to less accessible intelligence on newer topics.
I’ve completely stopped posting on Reddit since the API changes, and I was extremely prolific before[1] because I genuinely love writing about random things that interest me. I know I’m not the only one: anecdotally, the overall quality of content on Reddit has nosedived since the change and while there doesn’t seem to be a drop in traffic or activity, data seems to indicate that the vast majority of activity these days is disposable meme content[2]. This seems to be because they’re attempting desperately to stick recommendation algorithms everywhere they can, which are heavily weighted toward disposable content since people view more of it. So even if there were just as many long discussion posts like before, they’re not getting surfaced nearly as often. And discussion quality when it does happen has noticeably dipped as well: the Severance subreddit has regularly gotten posts and comments where people question things that have already been fully explained in the series itself (not like subtext kind of things, like “a character looked at the camera and blatantly said that in the episode you’re talking about having just watched” things). Those would have been heavily downvoted years ago, now they’re the norm.
But if LLMs learn from the in-depth posting that used to be prominent across the Internet, and that kind of in-depth posting is no longer present, a new problem presents itself. If, let’s say, a new framework releases tomorrow and becomes the next big thing, where is ChatGPT going to learn how that framework works? Most new products and platforms seem to centralize their discussion on Discord, and that’s not being fed into any LLMs that I’m aware of. Reddit post quality has nosedived. Stack Overflow keeps trying to replace different parts of its Q&A system with weird variants of AI because “it’s what visitors expect to see these days.” So we’re left with whatever documentation is available on the open Internet, and a few mediocre-quality forum posts and Reddit threads.
An LLM might be able to pull together some meaning out of that data combined with the existing data it has. But what about the framework after that? And the language after that? There’s less and less information available each time.
“Model collapse” doesn’t seem to have panned out: as long as you have external human raters, you can use AI-generated information in training. (IIRC the original model collapse discussions were the result of AI attempting to rate AI generated content and then feed right back in; that obviously didn’t work since the rater models aren’t typically any better than the generator models.) But what if the “data wells” dry up eventually? They can kick the can down the road for a while with existing data (for example LLMs can relate the quirks of new languages to the quirks of existing languages, or text to image models can learn about characters from newer media by using what it already knows about how similar characters look as a baseline), but eventually quality will start to deteriorate without new high-quality data inputs.
What are they gonna do then when all the discussion boards where that data would originate are either gone or optimized into algorithmic metric farms like all the other social media sites?
[2]: I can’t find it now, but there was an analysis about six months ago that showed that since the change a significant majority of the most popular posts in a given month seem to originate from /r/MadeMeSmile. Prior to the API change, this was spread over an enormous number of subreddits (albeit with a significant presence by the “defaults” just due to comparative subscriber counts). While I think the subreddit distribution has gotten better since then, it’s still mostly passive meme posts that hit the site-wide top pages since the switchover, which is indicative of broader trends.
> What are they gonna do then when all the discussion boards where that data would originate are either gone or optimized into algorithmic metric farms like all the other social media sites?
As people are using AI more and more for coding and problems solving providing company can keep records and train on them. I.e. if person 1 solved the problem of doing 2 on product 3 then when 4 is trying to do the same it can be either already trained into the model or model can lookup similar problems and solutions. This way the knowledge isn't gone or isolated, it's being saved and reused. Ideally it requires permission from the user, but price cuts can be motivating. Like all main players today have free versions which can collect interaction data. With millions of users it's much more than online forums have.
The problem is that AI companies have decided that they want instant access to all data on Earth the moment that it becomes available somewhere, and have the infrastructure behind them to actually try and make that happen. So they're ignoring signals like robots.txt or even checking whether the data is actually useful to them (they're not getting anything helpful out of recrawling the same search results pagination in every possible permutation, but that won't stop them from trying, and knocking everyone's web servers offline in the process) like even the most aggressive search engine crawlers did, and are just bombarding every single publicly reachable server with requests on the off chance that some new data fragment becomes available and they can ingest it first.
This is also, coincidentally, why Anubis is working so well. Anubis kind of sucks, and in a sane world where these companies had real engineers working on the problem, they could bypass it on every website in just a few hours by precomputing tokens.[2] But...they're not. Anubis is actually working quite well at protecting the sites it's deployed on despite its relative simplicity.
It really does seem to indicate that LLM companies want to just throw endless hardware at literally any problem they encounter and brute force their way past it. They really aren't dedicating real engineering resources towards any of this stuff, because if they were, they'd be coming up with way better solutions. (Another classic example is Claude Code apparently using React to render a terminal interface. That's like using the space shuttle for a grocery run: utterly unnecessary, and completely solvable.) That's why DeepSeek was treated like an existential threat when it first dropped: they actually got some engineers working on these problems, and made serious headway with very little capital expenditure compared to the big firms. Of course they started freaking out, their whole business model is based on the idea that burning comical amounts of money on hardware is the only way we can actually make this stuff work!
The whole business model backing LLMs right now seems to be "if we burn insane amounts of money now, we can replace all labor everywhere with robots in like a decade", but if it turns out that either of those things aren't true (either the tech can be improved without burning hundreds of billions of dollars, or the tech ends up being unable to replace the vast majority of workers) all of this is going to fall apart.
Their approach to crawling is just a microcosm of the whole industry right now.
[1]: https://en.wikipedia.org/wiki/Common_Crawl
[2]: https://fxgn.dev/blog/anubis/ and related HN discussion https://news.ycombinator.com/item?id=45787775