Their response attitude reminds me of basil from fawlty towers (paraphrasing):

I'm trying to run a business here. I can't get things done with you stupid customers bugging with me problems all the time. Go find something to do.

In the 80s and 90s customer satisfaction was important primarily in manufacturing. Today software treats customers like nyc realtors who know they have the balance of power:

that's too damn bad: the price is the price. Take it or i'll sell it to somebody else for wasting my time.

I think it matters a lot here if you can mathematically prove that it is "safe":

The only reason I'm comfortable transmitting sensitive over the internet is that we've got a bunch of proven systems like "encryption" that can guarantee my ISP, etc. doesn't learn much about my actual traffic.

Fundamentally, if you're giving an application your passwords, it is precisely so that the application can transmit those passwords, in full, to the relevant services. If you don't trust "mathematically proven safe" then it's already unsafe - and it's unsafe to a ton of third parties used to route the internet.

It's important because that means this is a harmless issue - there's a linked 3rd party mathematic proof by a credible authority on security (CloudFlare), and other password managers have similar features.

"I'd like clearer documentation" is still a reasonable request, but I don't think the OP is at all justified in acting like this is some outrageous trespass.

If you care about a harmless issue this intensely, you should be taking some responsibility to actually inspect the code. Given there was a feature flag to disable it, even a cursory scan with a cheap LLM probably would have found the "issue"

Also frenck explained how the feature works and why this is save.

On the other side Viss basically just said "trust me bro, it is not save and by the way, I'm THE expert and I'm so very smart, that I don't even need to list some facts why this could be unsafe, just fix it NOW", which I find exhausting, unhelpful and boring.

I do get the sense that you're not malicious, just that maybe you're not seeing this from the standpoint of someone that assigns a higher value to some elements of privacy. In this case, your user base expects a home automation system. They do not expect that system to scan their computer for passwords, regardless of how "safely" the home automation system were to behave.

You might have a heart of gold, and just be having an off day due to reasons, so I hope people cut you some slack, but if I were you I'd update this feature to be opt-in and conspicuous, immediately

Trust is hard won and easily lost. The entire reason I use Home Assistant is because I trust it to be the local, privacy focused home automation system. Things like this is a huge surprise that gives me pause to wonder what else it's doing that I wouldn't approve of. If I feel like I need to start setting up firewalls between HA and my internet to protect my privacy and data, I'm more likely to look towards alternatives and push my family members towards something else as well. This is the first time I've wondered if the project's ethics and culture matches what I expect out of the software.

Just my $0.02.

Hey dude, I don't get the sense you're being malicious, but you might want to consider the following...

I'm a Home Assistant user because I don't like my devices reaching out to random cloud services more than they need to. I suspect quite a number of fellow HA users feel similarly.

Although your intent was probably good, this feature certainly falls into the "more than they need to" bucket and feels hella icky. And yes, I'm very familiar with HIBP and cryptography in general. This simply isn't an opt-out feature I expect in a privacy positioned home automation product.

Asking basically the same thing as the sibling replies, but hopefully in a less aggressive way: can you elaborate on what led you to reply like that in the first place? As someone with no horse in the race (I don't use Home Assistant), the first reply you gave genuinely does seem like it was intended in good faith, even if it was not satisfying to the user, and I can understand that angry users are not fun to interact with, but I'm struggling to wrap my head around why your second reply was "This issue is closed as won't fix" without any elaboration about why. The explanation that seems most likely to me is that you were annoyed at the user and decided not to spend any time looking into the issue, which would be unfortunate but maybe understandable if that's what you're apologizing for. Without any explanation about why you quickly dismissed and then suddenly turned around and changed your mind later though, I think you've risked the apology coming across more as damage control than genuine regret.

Hey, how many opt-out features like this violate the openhome foundation supposed privacy stance ?

https://www.openhomefoundation.org/papers/privacy/

    Cloud-optional: Any functionality that requires data or control signals to leave your home must be transparently explained, opt-in by default via a simple workflow

"You can just opt out" is the worst possible response for something the user doesn't want, and didn't know about in the first place.

why lying on your first reply? you mentioned 1Password did the same, in an attempt to make yourself "less guilty", but you failed to realize 1Password doesn't enable that option automatically without consent, and in some cases this option is periodically DISABLED automatically. address this, please, it's pretty embarrassing to lie like this just to cover y'all's ass.

Hey Frenck, longtime HA user here. I know this feature feels pretty safe but I hope you can give http://cablej.io/blog/k-anonymity/ a read on how this ultimately still puts trust in HIBP, a third party cloud service. In my opinion this might help with understanding why people are rightfully worried, especially when they thought they are running a very local and private HA instance.

As someone reading this with no dog in the fight, you came across as rude and patronizing. I'm sure you are not like that in real life, but those responses were ..ooof, not pleasant.

I'm just a rando stranger, don't mean to pile on to you. But as someone that has also launched products and talk to customers every day.. that's not a good look.

Again, no hate here, I'm sure you're great to talk to in real life, but just the way you wrote that was not pleasant at all.

It was far beyond “more dismissive than they should have been”.

Maybe consider HIBP’s offline tool as the default?

https://haveibeenpwned.com/Passwords (“Download & Integrate”)

You should fix your fabrication in the 1st response. I have deployed 1Password in my organisation, and I'm also using it personally, and the "Check for vulnerable passwords" option (under Privacy) is opt in.

By suggesting that 1Password is doing the same you're lying to water down the gross abuse of trust.

"my replies were dismissive" non-apology after the initial "This issue is closed as won't fix." show pretty clear you're simply in the damage control mode, actually either not understanding or not caring why someone caring about security or privacy would be shocked and request opt-in you flatly rejected anyway.

> Only the first 5 characters of a SHA-1 hash go to HIBP

Some would consider the first five characters being sent over the internet to be 'your secret leaving your system'.

Some would consider phoning home to a remote server to be worrisome. It's home assistant not cloud assistant.

> My apologies

You shouldn't have to apology to anyone.

> My replies there were more dismissive than they should have been. My apologies.

I’m curious what made you change your mind, perhaps seeing this getting traction on hn?

I don't understand why this is a hill to aggressively die on.

Thanks for being here. Who made the decision to enable this by default without consent and without a GUI setting to disable it?

> My replies there were more dismissive than they should have been.

What would have been an appropriate amount of dismissiveness in your view?

>As it turns out, the check can already be turned off

Problem solved!

>My replies there were more dismissive than they should have been

What about this one?

interesting that the crux of the Nix dispute was about how he wanted to self-modify the HA after install, and the crux of the current dispute is how HA should be able to scan your secrets and upload truncated hashes

It's not a good look taken together

Was thinking of setting my own assistant using Home Assistant to replace the Google Home device I got rid of. Looks like I should slow down and take a closer look at this.

As someone whose smart home need is minimal -- I just use it to turn on/off lights with voice -- I'd rather have nothing than support such behavior.

Holy shit, what a read. How do people not understand open source licensing? In every license I'm aware of, you don't get to decide whether or not someone else can use your stuff. Nothing stops you from asking, of course, but it just looks bizarre. If you want to control distribution, design a license to do so, or don't release it in the first place.

Hah, his profile sure has a lot of bullshit about being human and positivity...

Dude that is

a) five years ago

b) nothing to be ashamed of, honestly

c) dumb drama

This is bad faith. You could reference it in good faith as context, but that is not what you are doing.

I just didn’t expect my HA to be talking to any external services without me explicitly setting it up.

> we can mathematically prove we're not humiliating you

Hm, how do I put it nicely? **** off

P.S.: I have no interest in home assistant, but the privacy debate is intriguing.

P.P.S: "unasked for" => remove. The statement cannot be any clearer or simpler.

It's a SHA-1, per https://github.com/home-assistant/supervisor/blob/main/super....

Their docs link to this explanation, in which the link I give uses an example that appears to be identical to the HA implementation - https://blog.cloudflare.com/validating-leaked-passwords-with...

I might be misunderstanding, but if the first 5 digits is a unique hash in the HIBP database then an attacker can replay that request, then lookup the hash. But "When hashes are grouped together by a Hash Prefix of 5 characters, we find the median number of hashes associated with a Hash Prefix is 305." {ibid}.

If you've acquired leaked passwords as HIBP have, you then just make hash lookup tables, then you have 305 potential passwords to try, or try and whittle down. If the bucket of hashes has "hunter2" in it, for example, then that's perhaps a good one to try - https://blog.cloudflare.com/validating-leaked-passwords-with... is worth reading.

because why should my electric light scheduler be in the business of inspecting my passwords and furthermore involving third parties in inspecting my passwords?

Because free (as in freedom) software should not betray the trust of its users by adding connected integrations that they haven't asked for or consented to. I expect software like HA to be fully offline.

It's a "severe invasion of privacy" to send anything to the Internet without the user's permission, period. Privacy is about having control over what information you disclose, how much, and to whom. Developers shouldn't be allowed to make that decision on behalf of the users.

I think the main issue is that you don't expect a service to send anything related to your data without letting you know. Even if it's a ping "alive" sent to a server they own.

Imagine if your smart toilet would just send a small anonymized message to a urine sampling analysis service so it can let you you know your cholesterol levels are a bit high, totally anonymous, totally for your benefit. Maybe it's a great feature, but would anyone expect this to happen without consent / opt in?

If your password is normally protected by a KDF that is hard enough that 1x SHA-1 is negligible in comparison then someone attacking your securely hashed password gets at a million-fold speedup in their search from knowing 5 characters of its sha1. (I'm assuming '5 characters' is hex, if it's 5 bytes then the speedup is a trillion-fold).

Even if the SHA1 isn't totally negligible in cost, if they're attacking many users at once they can share the SHA1 work across all of them (as it's not salted) making it marginally negligible. So someone attacking a sha-1 salted password database with a million users where they have the 20 bit unsalted sha1's still gets a similar speedup, even though the 'hard' hash is just as fast as the easy one.

Security aside, -- if you use some old crap password on internet isolated IOT devices that HA can reach (as some people I know do)-- then the 5 characters is a one in a million identifier which probably uniquely identifies you. The database sees your IP address and so you've probably connected to identity (via old leaks) to your IP to them and anyone surveilling your traffic. You've also connected your old weak passwords to that IP, so someone that gets access to it would have a ready database of plaintext passwords to use to initialize a password search against any exposed endpoints.

Even just making the request at all exposes information about the software you're running, that there are devices at that IP (which otherwise might be inbound blocked), etc.

I think the privacy concern is much worse than the security one: For security you can change any exposed passwords, presuming they didn't get you hacked yet. The privacy loss is far more irreversible.

Many people use home assistant in order to avoid security and privacy violating cloud services, so this is a significant disappointment.

It's probably overzealous of HA to do this, but ultimately it isn't. The context missing from this HN thread so far is that the reporter, Viss, has been frankly not credible on security in general for a really long time, despite being a big name in the community on stuff like OSINT. A lot of people in the OSINT sphere basically believe any information being public at all is a security risk and prefer you to pay them exorbitant consulting fees to come up with numerous ways of rephrasing their circular reasoning about why.

This feature has been around for 5 years... https://github.com/home-assistant/home-assistant.io/blob/cur...

  It is not an invasion of privacy

absolutely no one but me gets to decide what is an invasion of my privacy.

What PII do you think is being sent to HIBP?

It's certainly an overstep, but just the hash they're sending wouldn't be PII.

I am curious thought that how it would be illegal according to GDPR. They are hashed after all, and the same hash is not used for authentication.

If you actually read through, the option to disable the functionality was already present… just not documented. So it seems the documentation repo was the correct place to open it

Is it inappropriate? Not really. Is it a threat? Yeah, it really is. “I’m going to stop using your software if you don’t change this” is a threat. “I’m going to fork it and ship a competing product” is a stronger threat.

It was a clear attempt to sway with intimidation. It was done politely but that doesn’t change what it was. (The dev had already closed as won’t fix, too, so they had preemptively answered.)

People here act like HA includes a script that collects every password on your computer and sends them all over plaintext HTTP. I'm disappointed to be honest.

I would like to see the write-up from the red teamer and white hat hacker that claim they could break into thousands of systems with five characters of a SHA hash of a password. Should be a fun read.

To be fair, nabu casa comms kinda leave not many other options than stuff like this happening, as the general strategy they employ could be described with the single word "tarpit".

I'm torn. And sad.

The same dev doesn't even like others packaging his open source libs.

https://github.com/NixOS/nixpkgs/pull/126326

The triage person incorrectly used the word "threat" when the user said that they were contemplating mitigating their concerns by moving away from this software, and it's technically not a threat. Dictionary.com to the rescue.

So, the triage person is misstating the circumstance, reframing it to introduce pain -- thank you dictionary.com -- pain via calling it a threat.

Speculatively, perhaps the triage person has evolved a defensiveness that includes hostility from historically being harassed directly or indirectly through their free support to the public position, and having some identity wrapped up in the software, and then feeling pain that way. That's just speculation. They do talk about going and drinking a beer, elsewhere in this chat, and alcohol use is associated with emotional dysregulation, bidirectionally.

So, to help out in this circumstance, perhaps an AI could be used to triage some of these issues.

Like, an AI that knows everything about the product in question, and says

a) this is the documentation repo, would you like me to move this issue to the main repo where we can discuss this properly, and

b) that feature already exists in the form of blah blah blah.

That would ease some of the more tedious triage workload the person doing the triage, hopefully give them space so that there are a few of these incidents deriving from this specific set of causes.

> The dev comes as self-serving

What, do you not include links to every single one of your social media accounts in every single post you make on GitHub? I think this is a very cool and normal thing, and not a concerning red flag about narcissistic tendencies at all.

This common among Dutch culture.

Working on a fork already: Lets spend some tokens! :)

In context, I think that's a valid response to:

> please let us know so we can uninstall and fork.

So he's letting them know

Yeah not a good look. This is probably the worst way to handle community feedback.

The developer's reply was very reasonable and measured. The user, on the other hand, was very rude.