Circles indeed: Opt-out of pwned secrets warnings - #161 by cogneato
And why would they know it’s Home Assistant that is doing the request?
It’s just “one” request in thousands per day
Oh man, that is a good idea. I would definitely like to know of integrations using known passwords with external services. So: A hell yes please, sign me up! 
5 Likes
Why wouldn’t they? I never had a device pitching that api in my network and suddenly it does it multiple times a day? That’s not rocket science… and most probably there is also a fingerprint in the api query, but thats just guessing.
Please sign me out 
1 Like
That just has to be HA… NO WAY it can be anything else…
There are apps and other software using the same API, maybe “you” already used their service before HA did without you knowing.
It’s not your Home Assistant password. It’s the passwords you as a user have chosen to store in cleartext in secrets.yaml. Which could be used for e.g. (but not limited to) any of the nearly 2000 services listed here: https://www.home-assistant.io/integrations/#all
Edit: This turned out to be untrue.
LOL @frenck I have always had the utmost respect for you and the other devs I have interacted with over the years here (and I still do). However, can you really tell me that if the pwned add-on had gotten a warm reception by the community, that there isn’t some part of you that wouldn’t like to see it modified to scan the secrets.yaml file (and or other *.yaml files and/or integrations) in Core? I mean, it’s really not that big of a leap code-wise to replicate the functionality.
That’s my fear and honestly, it isn’t even about passwords (hashed or otherwise) being sent out. It’s about the Home Assistant mantra that it is a privacy and local first project. Calling out to any external service without the user’s expressed permission violates that mantra regardless if it is for something beneficial like password checking. It’s also part of the reason why I don’t run Supervisor (except for dev testing of things).
8 Likes
The user-agent string would identify it. Although, I’ve actually never tested or looked at what the UA string is from Supervisor outbound. Most likely, it’s just the generic aiohttp default user-agent.
I’m more and more thinking that the scan is good.
But I would rather have a UI where I could change what passwords it should scan and do the scan manually.
If I scan today then I don’t need to do a new scan for at least a week or when I add a new password.
Only if it is configurable and able to be enabled/disabled by the user. If it can’t do those two basic things, then it doesn’t belong on my network.
Thanks! 
So, personally, I think the reception is a bit blown up. Without giving any judgement on the current implementation @ the Home Assistant Supervisor; ALL community add-ons, I’ve created, actually have had this functionality already: For 2 years!. The responses to that have been quite the opposite 
I think a disabling is a nice thing to have; don’t get me wrong and I’m pretty sure nobody would decline a contributing like that either (it seems like something is already in the works as well).
that there isn’t some part of you that wouldn’t like to see it modified to scan the
secrets.yamlfile (and or other*.yamlfiles and/or integrations) in Core
I’ve seen my response has been flagged two times by the community; and honestly that I think is sad. I really, personally, would appreciate such functionality. It was not a response to mock or stab, I really would love such functionality. That is a personal opinion. But I guess, if you don’t like my opinion, one has to report it with the moderators.
Thanks guys. Love you too.
9 Likes
They also happen to let you opt out. Which I did on all of them
ETA: I’m annoyed by the omission. But I wanted to add that I do love most of what you guys do. Thanks!
2 Likes
True, but that goes to my point. Those add-ons are installed by the user, thus they give their implicit permission for those type of functions and they always have an opt-out. AFAIK, the pwned add-on isn’t optional in Supervisor. Therefore, no implicit permission has been given and there’s no way out of it.
I don’t report or flag for differences of opinion. I appreciate a good debate and differences in opinions facilitate that.
2 Likes
They are not actually. It only disabled the abort of startup. The password are still checked and still warned for. It merely disables the requirement, as written in the documentation of each add-on as well.
Objectively, you are right. It is over blown. But I think the main reason is that this update touches a very fundamental concept of HA: control. I can’t speak for others, but I’d wager that a majority of people use HA because it allows us full control over our home automation setup. With commercial offerings going more and more towards a model where you don’t really own your own installation anymore (or at least the data it generates), fully relinquishing control to the whims of a third party, knowing that HA would always give us full control and would never do anything behind our backs was very reassuring. This update, as objectively small and well intentioned it might have been, questions this entire concept.
At least for me that is the main reason I object to it.
8 Likes
Maybe it’s because it came like a lightingball, without warning? And without clear explanation how it works, letting us guess?
Maybe just because the implementation, which is far from perfect user experience wise?
I never deny that there are persons who might find it usefull. Maybe there are valid security considerations behind it.I’m for as many features as possible. The more the better. There is aleays a chance that it fits someone’s needs.
But under a condition all of them are carefully designed and developed providing highest possible quality
This time (not the first one) the execution is at least questionable - what is proven by community reaction (intil the reaction wasn’t major goal of this development increment - which I highly doubt).
BTW there are more and more such questionable design decissions. I wonder is there any Architect/QA role ensuring the project evolves in proper direction being in compliance with guidelines. Sometimes it looks more random than should be.
Are thay nagging every minute about insecure password? I have a few addons from your garage and I don’t recall such behaviour in any of them
2 Likes
My own two thoughts:
- It’s quite a useful feature, although I share the privacy concerns about pushing passwords (even partial, or hashes) to a third party service of any sort. For me, it alerted that I left a crappy 6 digit numeric password for my alarm integration when I was first setting it up and I’ve since changed it to something better
- I wholeheartedly agree that this should be something we can disable if not wanted. This is my Home Assistant deployment and if I want to (or, indeed, for some integrations, have to) use a rubbish password, that’s my choice. You’ve warned me, I’ve accepted the risk, you don’t need to tell me again.
Job done. Leave it on by default if you must, but add a config option to disable it if we don’t want it.
5 Likes
Interesting, can you send me the log?
The community add-ons don’t nag. Instead, they don’t start.