- Should a password manager warn me about reused passwords without sending things out without opt in? yes
- Should a password manager send even one byte of my data to any service, regardless of whether it is for a good intention and mathematically proven to be "safe" without opt in? I'd say no.
- So would any other product out there, be it a smart home manager or a toaster, send any of of my data, hashed or not to any 3rd party without opt in? even if it's just the byte "1" to a page called "donothing.com"? I say hell no.
- Should open source developers who are not Linus Torvalds be a bit nicer on a public issue?
- And should open source users should be less heated because "let us know if you plan to fix this or we will uninstall and fork it" deserves the "go ahead, this is open source, threats don't really help here"
We all can sometimes write a reply at the heat of the moment that we later regret. Frenk definitely realized it after the fact and I respect him owning it, apologizing, and keeping the old messages. He is right it's open source, and he doesn't owe anyone anything, but still, I believe a phoning home of any kind is violating The Principle of Least Astonishment.
Frenck here, I'm the one who replied on that issue.
My replies there were more dismissive than they should have been. My apologies. I've posted a follow-up on the issue.
As it turns out, the check can already be turned off after all:
ha security options --pwned=false
It has been part of the Supervisor for years and checks app options that are marked as passwords. A recent release fixed the warning that surfaces it, which is why people are noticing it now.
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
I've not seen the claim that it is scanning their computer for passwords. My understanding is the ones it checks are those that are used in HA's config (I assume, for different devices it connects to in your home).
There are a lot of problems with poor security practices devices of this type. Maybe the feature is a bit too paternalistic but it is not malicious.
I still agree its not the right default but thats quite a lot less invasive than you are making it sound.
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.
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.
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.
People accusing others of lying all the time is a major problem in current societal discourse.
It’s not a lie if the speaker believes it to be true; it’s just a mistake. A lie must have the intention to mislead behind it.
I don’t dispute that there is a lot of, perhaps way more, lying going on, especially in politics now, but let’s not both inflame opinions and cheapen the word ‘lie’ by just using it for non-deliberate falsehoods.
Not a lie, but I was wrong on that one. I'm happy to admit that.
I've used 1Password's Watchtower for so many years that I assumed the breached password check was just part of it. After your reply I looked it up and learned it's actually a setting in their privacy preferences, so my comparison was off.
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.
I can’t speak for him, but I regularly reword replies after a minute of consideration or if I manage to think to myself “is this as kind as I intend to be to others” during it’s formation.
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
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.
Nothing and no one is perfect, but Home Assistant is orders of magnitude better than any other home automation suite. The fact that there's enough transparency for this to be discovered, for this conversation to happen, and for the maintainer to publicly apologize is evidence of that.
There is nothing in that 5 year old thread that goes beyond standard issue friction between someone who created something and someone who wants to administrate something.
There is stuff to be mad about, but that does not include a dev five years ago telling the memeOS "hey can you maybe please don't do this. I am worries that it will cause more work for me if you do that"
I mean I can see the "I think your judgement is bad" could be seen as a personal insult (even though it is genuinely meant as an assessment of reality), but "multiple"?
This is not an issue if you are running Home Assistant Core in a self hosted container; the relevant "supervisor" service that does the scanning is only part of "HA OS" and "HA Supervised."
You may find this unasked for scan humiliating, but we can mathematically prove we're not humiliating you. Any feelings of discomfort or humiliation are therefore invalid and should be set aside.
Edit: I'm sure a greater good argument can be made. I just don't think they are making it in a way that justifies the invasiveness.
This feature should be opt-in, but can someone explain how this is a security concern? I don't understand how it would be an actual security risk to share the first 5 digits of the sha256 of my passwords.
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?
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.
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?
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.
It sounds like the dev's reason for rejecting the issue is that the issue was opened on the documentation repo rather than the code repo.
On the one hand, it's understandable. No amount of documentation changes will fix the issue.
On the other hand, it's a pretty abrasive response. It wouldn't have taken any more effort to be a little more helpful and direct OP to the right repo: "Sorry, this is the wrong place for this to be addressed. Please bring it up here instead [link]."
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
Giving the home assistant core developers the benefit of the doubt, I am sure there are good intentions here. But if they are interested in adding new security features, adding support for phishing-resistant multi factor authentication (passkeys) would be much more valuable. Users have been asking for it for some time, and even submitted patches, which were rejected.
That makes it even worse. A leak is still a leak even when you haven't notice it.
Personally I use HIBP but I would still be annoyed to learn a system I installed mainly for privacy was sending private data to a third party by default.
(For missing context from this bare link to an issue with no context provided by the submitter — Home Assistant apparently integrated the same Have I Been Pwned safe scanning process that many other password managers have.)
I have a great deal of sympathy for them refusing to engage; decisive software creators are far less palatable to an entitled swarm of disagreement, and that same decisiveness is what makes the best software. Perhaps in U.S. culture, refusal with a smile and a reassurance that “We’re Listening” is something folks feel entitled to, but in other areas of the world, demanding a stranger change their mind once it’s made up earns only mockery or pity. To those cultures, this GitHub is a comedy-farce, and I laughed out loud upon reading it — not because I necessarily agree with the project’s decision, but because I agree culturally with their tone and handling of what some view as blatant immaturity: a final flat refusal, closing the door, and getting back to work.
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.)
“hey, X is a dealbreaker for me, if this is not fixed please let me know so I can look for someone else”
“how dare you threaten me?”
I understand how one might feel attacked by an ultimatum, but a policy of rejecting ultimatums altogether only has the benefit of keeping pride intact, on the other hand it discourages people in your life from giving you a last chance, from communicating why they are leaving, and for letting them come back if the parting was amicable
best response is to just communicate you are not fixing X and parting ways amicably, no hard feelings. not only is it beneficial for the ultimated party, but it’s fair for the ultimating party, who is absolutely in their own right to rescind their voluntary relationship, in no way is it a threat to communicate that possibility, because a threat implies violence or damage.
Again, I did not say the threat in this case was inappropriate. It’s totally legitimate to say “this doesn’t work for me; change it or I’m out”. But it is a threat. We should be honest with what we are doing. If nothing else it makes it easier to understand (and predict) a defensive reaction when we understand and acknowledge a threat is being delivered.
there’s certainly an ambiguety in the word threat, where the main definition is about violent coercion, but it is sometimes used as a useful metaphoric shorthand.
and it’s very common for the usage to cause conflict, the exchange of “are you threatening me?” “no, i’m just telling you what I’ll do” is very common.
i personally wouldn’t use it as a shorthand when there’s no violence or punitory damage implied, unless I purposefully wanted to escalate things. it’s a word that refers to violence, so it will harsh the vibes instantly
a key element of coercion (and this is deeply studied in law so there is less subjectivity than regular language) is that the hypothetical presented cause a damage, and then the avoidance of that damage is traded for a positive action. it doesn’t really apply to a case where a person exercises their right (to leave) and it only secondarily (or not at all) causes a damage, there is no intent to harm and no manipulation of the other into acting one way to avoid that harm.
in the context of leaving a relationship, it might make some sense only if there’s a contract, or even some sense of loyalty that is expected from an extracontractual custom, we are talking marriages or (arguably) employment or religious affiliation, where bonds and codependence are formed. but invoking that treatment for strangers on an as-is warrantyless usage contract? nah
A threat can be violence but it’s not necessarily so. A threat is an expression of a negative result if something is not done. The negative could be violence, monetary loss, embarrassment, end of a relationship, or any other negative.
Definitely not delving into legal definitions of coercion because I am not a lawyer and it is not relevant here.
> and it’s very common for the usage to cause conflict, the exchange of “are you threatening me?” “no, i’m just telling you what I’ll do” is very common.
I think you mean that threats are a common cause of conflict. “Are you threatening me?” “No, I’m merely posing a negative outcome that I will inflict if you don’t do what I want. Totally not a threat. Definitely not.”
I wouldn't be surprised if that integration is outright illegal in EU due to GDPR, thus putting HIBP in trouble for ingesting PII without any legal legitimacy.
And the first reply being "It is not an invasion of privacy" just shows incompetence on privacy topics. It is never a valid answer.
Which is really concerning, for the lead developer of a home automation system that "fights for the fundamental principle of privacy" as per their mission statement.
Here we have the classic if you want something to happen in the corporate world, make it go viral on the internet. Except, humans will be humans and it played out in open source.
In this case, frenck most certainly backtracked because they realized they were on the front page of HN and did not want the heat.
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 have another tab open where I am about to buy a home assistant green and start a journey of probably-pointless automations. This is giving me pause. Not about sending hashes to haveibeenpwned, but about the response this got on github.
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.
It's pretty clear that the maintainer should've handled it better but I'd be lying if I said I never felt like telling a petulant user off. The problem is he didn't handle it professionally.
Well, I didn't check the git history so I can't confirm or deny that he implemented the feature, in any case, if you read the comment about how the passwords are anonymized it sounds pretty reasonable.
Leaving that aside, even if you diagree with it you (the user) are not entitled to anything, especially not entitled to have an attitude.
Just think about it differently, what do you think would happen if you do the same in the real world?
I'm pretty sure in the best case scenario you may be asked to leave and in the worst case scenario you may be "escorted" out of the premises.
- Should a password manager warn me about reused passwords without sending things out without opt in? yes
- Should a password manager send even one byte of my data to any service, regardless of whether it is for a good intention and mathematically proven to be "safe" without opt in? I'd say no.
- So would any other product out there, be it a smart home manager or a toaster, send any of of my data, hashed or not to any 3rd party without opt in? even if it's just the byte "1" to a page called "donothing.com"? I say hell no.
- Should open source developers who are not Linus Torvalds be a bit nicer on a public issue?
- And should open source users should be less heated because "let us know if you plan to fix this or we will uninstall and fork it" deserves the "go ahead, this is open source, threats don't really help here"
We all can sometimes write a reply at the heat of the moment that we later regret. Frenk definitely realized it after the fact and I respect him owning it, apologizing, and keeping the old messages. He is right it's open source, and he doesn't owe anyone anything, but still, I believe a phoning home of any kind is violating The Principle of Least Astonishment.
Frenck here, I'm the one who replied on that issue.
My replies there were more dismissive than they should have been. My apologies. I've posted a follow-up on the issue.
As it turns out, the check can already be turned off after all:
It has been part of the Supervisor for years and checks app options that are marked as passwords. A recent release fixed the warning that surfaces it, which is why people are noticing it now.Only the first 5 characters of a SHA-1 hash go to HIBP, and the matching happens locally: https://github.com/home-assistant/supervisor/blob/main/super...
Our documentation should have explained all of this, including how to turn it off. We'll get that updated.
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
I've not seen the claim that it is scanning their computer for passwords. My understanding is the ones it checks are those that are used in HA's config (I assume, for different devices it connects to in your home).
There are a lot of problems with poor security practices devices of this type. Maybe the feature is a bit too paternalistic but it is not malicious.
I still agree its not the right default but thats quite a lot less invasive than you are making it sound.
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.
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.
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.
From my understanding, they seem to be under a lot of stress/pressure lately.
I'm not exactly sure why, but the stuff that happens tells that story (to me at least).
Barking at frenck on a Friday at 11.30PM like this is probably not the right thing to do.
Hehe not really. I'm also just enjoying my hobby on a Saturday evening honestly :)
But you are right, it is time to head downstairs for a beer with Mrs. Frenck.
../Frenck
good bye
People accusing others of lying all the time is a major problem in current societal discourse.
It’s not a lie if the speaker believes it to be true; it’s just a mistake. A lie must have the intention to mislead behind it.
I don’t dispute that there is a lot of, perhaps way more, lying going on, especially in politics now, but let’s not both inflame opinions and cheapen the word ‘lie’ by just using it for non-deliberate falsehoods.
Not a lie, but I was wrong on that one. I'm happy to admit that.
I've used 1Password's Watchtower for so many years that I assumed the breached password check was just part of it. After your reply I looked it up and learned it's actually a setting in their privacy preferences, so my comparison was off.
../Frenck
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.
> 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 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 can’t speak for him, but I regularly reword replies after a minute of consideration or if I manage to think to myself “is this as kind as I intend to be to others” during it’s formation.
>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?
Toxic developers turned me off Home Assistant. The same developer is the star of this issue: https://github.com/NixOS/nixpkgs/pull/126326
Related discussion: https://news.ycombinator.com/item?id=27505277
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.
Nothing and no one is perfect, but Home Assistant is orders of magnitude better than any other home automation suite. The fact that there's enough transparency for this to be discovered, for this conversation to happen, and for the maintainer to publicly apologize is evidence of that.
Better, but apparently not good enough: I would have expected a bit more from a company that goes all in on "your home your data and privacy".....
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 found it helpful and informative.
Then, respectfully, your judgement is subpar.
You people are mad about the wrong things.
There is nothing in that 5 year old thread that goes beyond standard issue friction between someone who created something and someone who wants to administrate something.
There is stuff to be mad about, but that does not include a dev five years ago telling the memeOS "hey can you maybe please don't do this. I am worries that it will cause more work for me if you do that"
That isn't respectful at all. We don't have to agree with you about this.
I'm not mad about anything, but I wouldn't need your permission to be so.
I've learned from this thread that I don't want to use HA in the future.
Uh? Yes you don't have to?
Who said that you would have?
I have no skin in this game, but: friend, are you okay? You're acting like an incredibly weird jerk.
Please reconsider what you think is respectful, because that was just straight up multiple personal insults.
Uh. What? Multiple?
I mean I can see the "I think your judgement is bad" could be seen as a personal insult (even though it is genuinely meant as an assessment of reality), but "multiple"?
Do you honestly expect anyone to believe that you didn't intend "memeOS" to be an insult?
No, why?
The sentence structure implied that I would have personally insulted this HN user and did so multiple times.
That is not true though.
What you did sense instead is more of a general abrasiveness-field. That was intentional.
Hah, his profile sure has a lot of bullshit about being human and positivity...
This is not an issue if you are running Home Assistant Core in a self hosted container; the relevant "supervisor" service that does the scanning is only part of "HA OS" and "HA Supervised."
You may find this unasked for scan humiliating, but we can mathematically prove we're not humiliating you. Any feelings of discomfort or humiliation are therefore invalid and should be set aside.
Edit: I'm sure a greater good argument can be made. I just don't think they are making it in a way that justifies the invasiveness.
This feature should be opt-in, but can someone explain how this is a security concern? I don't understand how it would be an actual security risk to share the first 5 digits of the sha256 of my passwords.
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?
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.
Don't shoot the messenger....
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?
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.
It sounds like the dev's reason for rejecting the issue is that the issue was opened on the documentation repo rather than the code repo.
On the one hand, it's understandable. No amount of documentation changes will fix the issue.
On the other hand, it's a pretty abrasive response. It wouldn't have taken any more effort to be a little more helpful and direct OP to the right repo: "Sorry, this is the wrong place for this to be addressed. Please bring it up here instead [link]."
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
Yep, that reply was posted after my comment here, so it turns out the documentation really was the right place for the issue.
Giving the home assistant core developers the benefit of the doubt, I am sure there are good intentions here. But if they are interested in adding new security features, adding support for phishing-resistant multi factor authentication (passkeys) would be much more valuable. Users have been asking for it for some time, and even submitted patches, which were rejected.
This feature has been around for 5 years... https://github.com/home-assistant/home-assistant.io/blob/cur...
That makes it even worse. A leak is still a leak even when you haven't notice it. Personally I use HIBP but I would still be annoyed to learn a system I installed mainly for privacy was sending private data to a third party by default.
The feature is not the problem.
(For missing context from this bare link to an issue with no context provided by the submitter — Home Assistant apparently integrated the same Have I Been Pwned safe scanning process that many other password managers have.)
I have a great deal of sympathy for them refusing to engage; decisive software creators are far less palatable to an entitled swarm of disagreement, and that same decisiveness is what makes the best software. Perhaps in U.S. culture, refusal with a smile and a reassurance that “We’re Listening” is something folks feel entitled to, but in other areas of the world, demanding a stranger change their mind once it’s made up earns only mockery or pity. To those cultures, this GitHub is a comedy-farce, and I laughed out loud upon reading it — not because I necessarily agree with the project’s decision, but because I agree culturally with their tone and handling of what some view as blatant immaturity: a final flat refusal, closing the door, and getting back to work.
Tough one. I get the intention but this should've been opt-in.
>>please let us know so we can uninstall and fork
>Sorry, these are not statements we can work with. Doing such threats and trying to intimidate it not going to bring you anywhere. If you want to do a
just wanted to add an outsider perspective here, not trying to add wood to the fire
but i don’t think it’s inappropriate or ‘a threat’ to let the dev know the user can stop using the software.
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.)
“hey, X is a dealbreaker for me, if this is not fixed please let me know so I can look for someone else”
“how dare you threaten me?”
I understand how one might feel attacked by an ultimatum, but a policy of rejecting ultimatums altogether only has the benefit of keeping pride intact, on the other hand it discourages people in your life from giving you a last chance, from communicating why they are leaving, and for letting them come back if the parting was amicable
best response is to just communicate you are not fixing X and parting ways amicably, no hard feelings. not only is it beneficial for the ultimated party, but it’s fair for the ultimating party, who is absolutely in their own right to rescind their voluntary relationship, in no way is it a threat to communicate that possibility, because a threat implies violence or damage.
An ultimatum is a threat. That’s literally the definition. https://en.wikipedia.org/wiki/Ultimatum
Again, I did not say the threat in this case was inappropriate. It’s totally legitimate to say “this doesn’t work for me; change it or I’m out”. But it is a threat. We should be honest with what we are doing. If nothing else it makes it easier to understand (and predict) a defensive reaction when we understand and acknowledge a threat is being delivered.
there’s certainly an ambiguety in the word threat, where the main definition is about violent coercion, but it is sometimes used as a useful metaphoric shorthand.
and it’s very common for the usage to cause conflict, the exchange of “are you threatening me?” “no, i’m just telling you what I’ll do” is very common.
i personally wouldn’t use it as a shorthand when there’s no violence or punitory damage implied, unless I purposefully wanted to escalate things. it’s a word that refers to violence, so it will harsh the vibes instantly
a key element of coercion (and this is deeply studied in law so there is less subjectivity than regular language) is that the hypothetical presented cause a damage, and then the avoidance of that damage is traded for a positive action. it doesn’t really apply to a case where a person exercises their right (to leave) and it only secondarily (or not at all) causes a damage, there is no intent to harm and no manipulation of the other into acting one way to avoid that harm.
in the context of leaving a relationship, it might make some sense only if there’s a contract, or even some sense of loyalty that is expected from an extracontractual custom, we are talking marriages or (arguably) employment or religious affiliation, where bonds and codependence are formed. but invoking that treatment for strangers on an as-is warrantyless usage contract? nah
A threat can be violence but it’s not necessarily so. A threat is an expression of a negative result if something is not done. The negative could be violence, monetary loss, embarrassment, end of a relationship, or any other negative.
Definitely not delving into legal definitions of coercion because I am not a lawyer and it is not relevant here.
> and it’s very common for the usage to cause conflict, the exchange of “are you threatening me?” “no, i’m just telling you what I’ll do” is very common.
I think you mean that threats are a common cause of conflict. “Are you threatening me?” “No, I’m merely posing a negative outcome that I will inflict if you don’t do what I want. Totally not a threat. Definitely not.”
A rare occasion where the AI response was an improvement on the human-written ones.
I wouldn't be surprised if that integration is outright illegal in EU due to GDPR, thus putting HIBP in trouble for ingesting PII without any legal legitimacy.
And the first reply being "It is not an invasion of privacy" just shows incompetence on privacy topics. It is never a valid answer.
Which is really concerning, for the lead developer of a home automation system that "fights for the fundamental principle of privacy" as per their mission statement.
It's certainly an overstep, but just the hash they're sending wouldn't be PII.
The hash itself is irrelevant.
The question is what PII does HIBP collect on submission (eg IP address), and with whose consent, and for which purposes?
All that should be explained in excruciating detail in the ticket and in the documentation, to begin with.
What PII do you think is being sent to HIBP?
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.
Undoing personal information for a purpose different than the purpose for which it was collected.
So, wait, these are secrets that are already given to h-a, hashed, and just the first five characters of the hash sent up..?
Yeah, I agree with the maintainer, this strikes me as outrage theater over any actual problem, no?
poettering vibes
> If this is all reason for you to uninstall and fork... So be it, it is open source after all.
what a petty answer. "just fork it bro".
Working on a fork already: Lets spend some tokens! :)
Here we have the classic if you want something to happen in the corporate world, make it go viral on the internet. Except, humans will be humans and it played out in open source.
In this case, frenck most certainly backtracked because they realized they were on the front page of HN and did not want the heat.
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.
I have another tab open where I am about to buy a home assistant green and start a journey of probably-pointless automations. This is giving me pause. Not about sending hashes to haveibeenpwned, but about the response this got on github.
The dev comes as self-serving. Not what you’d expect to see. Calls it heated when he himself caused it with their tone deaf response… it’s next level.
The same dev doesn't even like others packaging his open source libs.
https://github.com/NixOS/nixpkgs/pull/126326
> 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.
Awfully tone deaf responses
Frenck is the worst part of Home Assistant. He shits on so many things with just a hand wave and no attempt at justification.
And that kids is a clear example of how not to interact with people online.
Yeah not a good look. This is probably the worst way to handle community feedback.
I mean, none of them behaved like an adult.
It's pretty clear that the maintainer should've handled it better but I'd be lying if I said I never felt like telling a petulant user off. The problem is he didn't handle it professionally.
Maybe he shouldn’t be accessing people’s passwords. If you start looking into someone’s wallet you can expect an abrasive response.
Well, I didn't check the git history so I can't confirm or deny that he implemented the feature, in any case, if you read the comment about how the passwords are anonymized it sounds pretty reasonable.
Leaving that aside, even if you diagree with it you (the user) are not entitled to anything, especially not entitled to have an attitude.
Just think about it differently, what do you think would happen if you do the same in the real world?
I'm pretty sure in the best case scenario you may be asked to leave and in the worst case scenario you may be "escorted" out of the premises.
A little bit of politeness goes a long way.
The developer's reply was very reasonable and measured. The user, on the other hand, was very rude.