← Back to context

Comment by frenck

3 days ago

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.

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.

    • My concern is Supervisor runs the operating system for the computer Nabu Casa sold me to run HAOS.

      In the off chance Supervisor inadvertently revealed the first 5-characters of my password hash to something else on or off my network over the years, I’m now going to spend a weekend reinstalling a fresh copy of HAOS, blocking it from Internet access until I can run the command to disable this, issuing new passwords and accounts to my household, and resetting the passwords for all my devices and integrations, then restoring all my automations.

      Better documentation will definitely help restore confidence, but good practice for me to cycle all my passwords and tighten network policies anyways.

      4 replies →

  • Security issues rarely arise from explicitly malicious behavior. It's usually careless attitudes until the holes in the swiss cheese align

    • in defense of frenck, this is actually a very secure way to perform the task. swiss cheese alignment won't happen because of this

      however

      it's also a feature transmitting information in a product that bills itself as being offline. imo it's a (minor) privacy violation, not a security violation.

      3 replies →

  • It's not just a home automation system though. People setup HA for a lot of reasons, but one of them is that they don't want other people/companies in control of what goes on in their home, spying on them, etc. The sort of people who go to the trouble to set up a server, deal with all of the integration issues, etc so that they can get something that they have control over of.

    Anyhow that sort of person might not take kindly to having a hash of their password sent to some random web server without being asked first.

  • How is a provably anonymous operation a violation of privacy?

    I value my privacy quite highly, but I don't mind harmless, anonymous use of my data

    • Even sending out a request to a third party server without any input by the user or good reason (which I wouldn’t count this as) should be counted as a privacy violation because HIBP can now infer that network is running HA.

      3 replies →

    • Depending on how it's batched, this tells HIBP (and any MITM -- even one that can only see ciphertext) roughly how many unique passwords you use. Knowing the 5-character hash prefix also cuts down brute force attacks by a factor of a million -- though in practice this is only a real issue if you use one of the compromised passwords (there's only a few hundred candidates per prefix), in which case you're kind of screwed already because they're probably in dictionaries anyway.

      I don't think these are /critical/ issues and the latter is basically just an argument against the HIBP service, but the point is that a user should opt-in to sharing their data in cases like this so they have a chance to make an informed decision. The k-anonymity design of the HIBP service has a degree of anonymity, it's not "provably anonymous" like homomorphic encryption or similar schemes would be.

      4 replies →

    • The use isn't anonymous, it sends your IP address to a third party, a personally identifying piece of information.

      This is fundamental feature of all traffic sent via IP unfortunately.

      3 replies →

    • That's not how privacy works. I don't care what you mind or consider harmless, no tool should be scanning the file system for anything without explicit consent and permission.

      Making such a behavior opt-out is malicious, intentionally or not. --pwned=false? Give me a fucking break, so you're pwned by default then. Unbelievable what some developers think they can get away with.

      7 replies →

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.

  • I've been considering home assistant, and yeah this gives me pause.

    IMHO it's just not the kind of behavior that is expected by the people that use the software.

    The fact that it didn't occur to anyone that this isn't a good idea makes me question other design decisions. When local-only isn't local-only, that's a problem.

  • Just to add to your point, I’ve deliberately avoided home-assistant since this kerfuffle where frenck was quite rude to the NixOS maintainers. https://news.ycombinator.com/item?id=27505277

    • Ouch, what a painful read.

      I avoided HA due to some technical issues published and the further development, but that quote absolutely cemented the decision in me:

      > It made me decide to request for complete removal. > I suggest you honor that request and sit on your wounds.

      What a.... colourful persona! I wonder if he was alluding to the potential and baseless C&D request or his opinion that one person's wish revokes MIT licence just because.

      But..... That's quite painful to read.

    • That's a very bad look. Both of these incidents make me happy I haven't implemented Home Assistant yet, I'll look for something else.

  • Yeah.

    Seeing this, I don't think I'm going to set up Home Assistant any time soon.

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.

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

  • That's the point right there, it feels like people who wrote that and people who added this "feature" are not the same people (any more).

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.

> Our documentation should have explained all of this, including how to turn it off. We'll get that updated.

Do you mean "how to turn it ON"? It should be off by default, just look at the replies you're getting by people that are seriously considering not using HA because of this. Is it worth it? It doesn't matter if it's secure by your standards, what matters is that it gives people the security "ick" and will then second-guess every other security decision in the rest of the software. That matters.

"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.

[flagged]

  • 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

      2 replies →

  • 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.

    • It's really not so hard to either install 1Password afresh and check, or to check the documentation.

      I would give them the benefit of the doubt but it's pretty clear from the initial response on github that privacy or security decisions of users do not matter much.

    • > It’s not a lie if the speaker believes it to be true

      I'm looking forward to that latest Elizabeth Holmes documentary.

  • 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.

  • I would consider a single byte sent to any server without my explicit permission a breach of trust.

    • If I were setting up HA it is exactly because I don't want the shenanigans of Google Home and Alexa.

      Seeing this, I don't think I'm going to touch it. Alexa might be more respectful of user data.

  • It is already enough to prove the existence of a password or that another password is not disclosed for example.

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

  • And I believe it is far less than what could be.

    Too many OSS projects die because authors are too afraid to tell demanding users in which direction they could proceed and instead burn out.

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.

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.

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?

> 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.

    • He posted a couple of replies and closed the issue, then this thread was posted and he went back and posted an apology and the fix.

      1 reply →

let me get this straight, the complaining user had "--pwned=true"? that option could be better named in my opinion.

>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?

  • Problem is not solved. Why was this turned on by default behind our backs? What else is being contacted and with what purpose behind our backs? This is a serious breach of trust from Home Assistant.