Comment by eranation
3 days ago
- 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.
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.
One of my favorite tv shows of all time.
Because free open source software isn’t a business and its users aren’t paying customers.
I don't buy it. Data privacy is a customer concern that isn't going away nor will it be diminished.
Let's get a few things straight:
- I tell the supplier if I am satisfied with their service. They don't tell me.
- I decide if the cost in terms of time or dollars is worth it; they don't tell me nor may they infer I'm too stupid to know better.
- some customers are lazy or don't have a backbone. Suppliers can push them around. Btw - this happens a lot inside corporations where management explicitly or implicitly mandates internal suppliers. In some cases those internal suppliers lost bad because of their arrogance wit. migration to the cloud from on-prem. Ultimately tech+business knew they got a better tradeoffs elsewhere.
- the customer is right is not a straight jacket for suppliers; we are allowed to smartly exclude features we don't think we can compently do or are bad business.
The swarmy arrogance and laziness of the big three re: customer satisfaction cost them about 35% of the auto market in our own backyard to the Japanese they never really got back. Too many corporations are sliding into at times seeing customer feedback as a nuisance at their own peril.
Im a strong customer advocate. Know what your getting; hold the supplier to the line; be in charge of the relationship; never retreat from options.
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"
> 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.
This is about secrets in general. Those could just as well be used to encrypt local data or sign session cookies for the internal web page. And sending the secret to the service it is for is different than sending it (or at least a part of its hash) to another service the user might not trust.
Sorry, can you provide a link to where the HA application is scanning the filesystem for secrets in general? I thought this was just the passwords you hand over so it can automate things
1 reply →
No matter how you encrypt the data, transmitting it unavoidably leaks the fact that you're running software that transmits that data. There's no way to mathematically prove this is harmless, because there's no way to know how that information could be used against in the future in ways you didn't predict.
No software should ever make network requests without your consent.
Yeah except the web browser and mail client I wish the default would be no open sockets for you ever.
Unless it is a distribution policy to respect privacy by default it is just to much work to keep up with all the leaks the system might have.
> deserves the "go ahead, this is open source, threats don't really help here"
Depending on how serious you think the privacy breach is, you can report them on github, do a campaign against them on any website they don't control (HN/reddit/etc), also you can convince other participants of open source to block their software if they detect it (e.g. GNOME blocks binaries of certain hash etc).
If they run a malware/spyware or something that level, open source will make them stop or go irrelevant.
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.
Thats the thing though, it's not safe [1] and puts trust in a third party - HIBP.
To do that automatically without any notice to the user breaks the fundamental value proposition of a local home assistant which over and over again preaches keeping things local and private.
As someone who relies on home assistant every day, I'm quite disappointed to hear Frenck's response to this.
[1] http://cablej.io/blog/k-anonymity/
From the issue author: "I can give you a list as long as my arm about how I could abuse this to loot credentials from every HA install on the planet.".
From the linked article I can count 2 with following conditions:
1. relies on a malicious or compromised lookup server, linking lookups to the same user, the user checking two predictably similar passwords, both passwords being breached, the attacker having their plaintext candidates, and knowing the account identifier for account takeover
2. relies on a malicious or compromised lookup server, linking lookups to the same user, the user checking multiple predictably related passwords, sufficient computing resources to search the original password space, and knowing the account identifier for account takeover, the attack demoed seems to work if you have a weak password to starts with (10 chars alphanum).
1 reply →
Sending out even a ping without explicit user consent makes it unsafe.
How? What is you definition of unsafe?
2 replies →
They have always been like that