One time I was caught out in heavy rain, and when I later tried to plug in my iPhone I got a message saying the lightning port was disabled until it could dry out. There was even an emergency override option, which I opted not to use. Seems like a nice feature to me.
A few days ago my iPhone would show the same message despite not being exposed to water. A reboot has fixed it, but that makes me wonder what is the false positive rate on that.
I had that on a Samsung phone. Eventually it got so bad I had to switch phone because it would constantly believe there was water in the USB port even though it was bone dry.
It may have been some sort of short internally, but to me it just meant a defective phone.
It doesn't need to send anything to Apple. A tech could read a log or CMOS bit or whatever at time of repair. Not saying they do that but the article seems pretty pointless. It's like they wanted to talk about a neat feature and chose the most indigent way possible.
And beyond that obvious path the author is only watching for activity while the port is not wet! Obviously it wouldn't phone home every time the port is dry. While I doubt apple is using this to void warranty claims this is about the weakest debunking of that I can imagine.
I think you meant "indignant". Besides that, I pretty much agree. Got pretty defensive about the only questioning comment on the post when I looked too. Harsh reaction to a fair point, and then contrary when somebody pointed out it was harsh. All the other comments got ordinary civility and thank yous.
Checking one process for network traffic says absolutely nothing about the actual proliferation of that data, whether from a repair tech having physical access to read the log, or the data being written elsewhere besides the log, or another process receiving it either directly or via the log and uploading it. If you want to prove everyone wrong, at least actually prove it instead of pretending to and then accusing anyone of FUD who points out the holes in your logic and methodology. I don't even give a darn that it's Apple, not like there'd be any less dubiousness if it were Microsoft or Google. This reads like someone who has an emotional axe to grind, not actual research.
HN (and other forums) are great sources of myths. It goes like this:
- Person A asks a question and proposes a suggestion
- Person B responds to the suggestion and adds more complaints
- Person C either agrees or disagrees with A and B's claims, but adds an argument which adds more detail/fills in more gaps and adds more suggestions
At no point does anyone say "hold on, do any of you have any empirical evidence of anything you've said?" Everybody just kind of accepts every premise, and then argues it as if it's a valid premise. That acceptance of the false premise is the bedrock on which invented ideas become commonly-held beliefs.
I think this is part of what makes AIs hallucinate. These conversations get ingested by the AIs and make connections between these claims, which it will see again and again as the myths are repeated from forum to forum. Later it will make correlations between the conversations and there isn't anything solid enough for it to determine which is real or not. I've seen it recently when analyzing adhesives, where it will not only quote the wrong information about an adhesive (despite it already having the TDS in its database), but also it'll make up fake adhesives that are clearly a mash-up of two real adhesives.
(See, I've just done it... completely talking out of my ass about a subject I don't know anything about, but sounds plausible)
> See, I've just done it... completely talking out of my ass about a subject I don't know anything about, but sounds plausible
Yeah but, you prefaced it with "I think".
It seems a rather unreasonable standard that all in-depth conversation about any topic must require research and citations. Sometimes people just want to chat casually about what they think, based on their personal experiences, and are not attempting to state opinion as fact. -I think- that is totally fine.
It's only because "telemetry" (i.e. spyware) has been so pervasive that the suspicions arose. Does anyone else remember the "dew sensors" in VCRs and other tape equipment? Those were around before pervasive mass surveillance, and didn't cause the same suspicion.
Attempts to connect over the network are obvious in the log
> Maybe its reports could have been embedded in other analytics data passed to Apple later, but there was absolutely no evidence that the results of liquiddetectiond went beyond the confines of my Mac.
I feel like this is plausible. Apple /could/ record any non-zero results from this daemon in some regular diagnostics package and upload it to their database of hardware UUIDs + associated Apple ID.
But at the same time, why bother? If the user brings in a laptop for service they'll find out about any liquid damage then, surely it's recorded in some unclearable diagnostic area of memory. Not beaming this data on demand seems in line with Apple's privacy etiquette, but we may never know for sure.
Apple provides a man page for every system daemon. I suppose this doesn't answer too many questions though:
NAME
liquiddetectiond – Liquid Detection and Corrosion Mitigation Daemon
DESCRIPTION
liquiddetectiond runs in the background and collects liquid detection
analytics from each USB-C port on the system.
For a company that is very careful in phrasing its public communications, that description definitely raises some red flags. If it was something more like "detects moisture and warns the user to avoid damage caused by damp USB port use" it would be perceived much better.
That's not what the daemon doing though... Firmware would be responsible for avoiding damage, this daemon is actually just collecting information about when such events happen.
The manpages of system daemons are definitely not being carefully curated in the way you are implying. They're written, often poorly and imprecisely, by engineers.
I'm not sure what you're implying. But I worked at Apple and wrote manpages for various stuff I worked on. Not once did I work with someone to "carefully phrase" them as "public communications". The idea of doing that would be silly. The people at Apple that do that careful phrasing stuff (marketing, etc.) don't even know what a manpage is.
This article criticizes supposition and assumption. It's true that there's no evidence that Apple is doing anything nefarious with the daemon. But it then goes on to just make it's own supposition and assumption - that the daemon is only used for warning the user - with essentially as much evidence.
Well Apple was for example fined for slowing down old iPhones without even telling the user. I personally do not consider them as good faith actors and it is only matter of choice for them to use it against you. There is in the end nothing more you can do than complain or sue them.
I'm not sure this is a fair take. It slowed down iPhones with weak batteries to avoid the voltage hitting a bad threshold and just rebooting. This was an engineer solving a problem and not considering about the downstream effects more than nefarious company doing evil.
>As is so often the case, the truth behind the myth is more prosaic, and doesn’t involve Apple secretly capturing data from your Mac, nor conspiring to dodge warranty repairs.
>on not one of the occasions that liquid detection was performed did that MacBook Pro try to connect to any remote site. Maybe its reports could have been embedded in other analytics data passed to Apple later
You can't have it both ways, Howard. You admit that you didn't prove that it wasn't sent, yet you then claim that couldn't have been the case.
While it has not been proven either way, given how anti-consumer Apple has become, I am not willing to give them the benefit of the doubt on this, and I'm surely not the only one.
IBM Thinkpads did. Lenovo Thinkpads are not the same quality.
I've personally spilled about the same number of drinks into one IBM Thinkpad as I've completely fried Apple laptops with; about 3-4. The Thinkpad would probably still work today.
