Rendered at 14:25:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
eranation 16 hours 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.
scrubs 13 hours ago [-]
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.
bmacho 2 hours ago [-]
> 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.
handoflixue 14 hours ago [-]
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"
echoangle 14 hours ago [-]
> 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.
handoflixue 11 hours ago [-]
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
echoangle 5 hours ago [-]
I agree that it only applies to HA secrets but HA also has a web interface. Secret doesn’t mean only password
mrob 7 hours ago [-]
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.
ahofmann 14 hours ago [-]
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.
kevinsundar 10 hours ago [-]
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.
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).
rcxdude 4 hours ago [-]
Yeah, I think the situation is that if your password is already weak/known to a level that it should already be considered compromised, a malicious HIPB could surface that compromise a lot more reliably/quickly.
atmanactive 6 hours ago [-]
Sending out even a ping without explicit user consent makes it unsafe.
ahofmann 3 hours ago [-]
How? What is you definition of unsafe?
monster_truck 13 hours ago [-]
They have always been like that
frenck 17 hours 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.
Our documentation should have explained all of this, including how to turn it off. We'll get that updated.
infinite_spin 17 hours ago [-]
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
jeremyjh 16 hours ago [-]
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.
sippingabonedry 15 hours ago [-]
Security issues rarely arise from explicitly malicious behavior. It's usually careless attitudes until the holes in the swiss cheese align
karlgkk 11 hours ago [-]
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.
jeremyjh 52 minutes ago [-]
> swiss cheese alignment won't happen because of this
This is the problem. You do not know what you do not know. There have already been papers written about the problems with HIBP. You don't have to understand the threat model for it to exist.
atmanactive 6 hours ago [-]
It's a trust violation.
cameldrv 9 hours ago [-]
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.
handoflixue 14 hours ago [-]
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
cyphar 12 hours ago [-]
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.
handoflixue 11 hours ago [-]
Does it actually batch them in an identifying way?
Is there any realistic value to knowing "how many unique passwords you use"? If you already have one of my passwords compromised, you'd presumably try it on the rest of my accounts regardless?
My browser fingerprint leaks, what, thousands of times more information than that - surely fixing applications like Chrome to have sensible privacy-preserving opt-in-only behavior is vastly more important than nagging some obscure open source software about an edge case that can barely be exploited?
cyphar 11 hours ago [-]
By "batching" I was referring to whether they deduplicate requests -- if they do one HTTP request for every password then you get some extra information about how passwords are shared that you would have to infer otherwise.
If you know someone with N logins has N passwords it's a decent indication they use a password manager and so passwords are unlikely to be weak, if they have 1 password it's probably shared elsewhere and weak.
I also wasn't responding to a question asking about practical exploits, I was responding to a question that claimed the k-anonymity model is "provably anonymous" and "harmless". Since it clearly leaks some information it's definitely not the former and one could argue it's not the later though the "harm" is minimal.
> My browser fingerprint leaks, what, thousands of times more information than that - surely fixing applications like Chrome ...
I fail to see how the privacy nightmare of modern browsers is relevant to a discussion on whether opt-out signalling to third-party services is a reasonable stance for an open source project? By that metric no privacy bug is worth reporting because Chrome continues to exist. If only there was a term for this kind of non-sequitur...
handoflixue 7 hours ago [-]
If you want to claim something is harmful, you have to actually demonstrate that harm. Otherwise your claim is merely that it could be harmful, which is by default true of basically everything, and thus not a very interesting point.
"Leaks information" is perfectly compatible with "provably anonymous"
You have to prove that the leak is enough to actually de-anonymize someone to disprove anonymity.
I'm not saying it can't be done, but you're jumping ahead and skipping a very important step.
2 hours ago [-]
echoangle 14 hours ago [-]
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.
handoflixue 11 hours ago [-]
Wait, how? It's not like it's the only app doing this, and I would assume it's not signing it's requests?
atmanactive 6 hours ago [-]
By a virtue of the fact that each and every server logs all packets 24/7 nowadays. For example, if you run a port scanner over a million different IP addresses, and one of them happens to be mine, then in my logs there is your IP now.
gpm 11 hours ago [-]
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.
handoflixue 11 hours ago [-]
Okay, but (a) it's a well known, trusted service and (b) yeah, my browser does that every time I visit a site but no one seems to freak out about that. Like... an IP address by itself is useless, and it's being handed to a trusted party anyway...
mrob 6 hours ago [-]
>my browser does that every time I visit a site
The purpose of a browser is to make network requests. If I use a browser, I am implicitly giving it consent to make the network requests necessary for the web browsing I do.
This implied consent does not cover unnecessary requests, e.g. the adverts Firefox displays on new tabs by default are unacceptable, because I did not consent to them being downloaded. It also does not cover the network requests made by opening the "Extensions and Themes" menu, because merely looking at a configuration menu does not imply consent to make network requests.
But that fact that modern web browsers are a privacy disaster does not excuse bad behavior from other software.
8 hours ago [-]
lioeters 12 hours ago [-]
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.
handoflixue 11 hours ago [-]
Did it scan the file system? Or did users hand over the passwords as part of the application? Because everything else makes it sound like the latter.
The site is called "Have I Been Pwned", thus the cutesy name of the flag...
lioeters 11 hours ago [-]
Perhaps it scans a database and not the file system, but either way, if I see an application gathering passwords and sending remote requests to an unauthorized third party "pwnedpasswords.com" (literally) without my explicit command to do so, then it is acting maliciously by design.
handoflixue 7 hours ago [-]
It's a password management system - it's not "gathering" passwords, it is being explicitly given passwords by the user. This is a very important difference! The entire point of the application is that you give it your passwords and it keeps them secure.
The designer felt that "secure" included "is this password already published, online, in a known database breach", which is not an unreasonable interpretation.
The documentation has been clarified. There was a a feature flag. Calling this malicious is just absurd flame-bait.
lioeters 7 hours ago [-]
I understand you're OK with a password managing application making remote requests to a third party without your permission or consent. For me it's unacceptable and unforgivable. We have differing opinions.
unsnap_biceps 16 hours ago [-]
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.
fg137 6 minutes ago [-]
Yeah.
Seeing this, I'm not going to set up Home Assistant any time soon.
spl757 13 hours ago [-]
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.
bspammer 15 hours ago [-]
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
subscribed 12 hours ago [-]
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.
5 hours ago [-]
mrshadowgoose 13 hours ago [-]
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.
slazaro 5 hours ago [-]
> 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.
secondary_op 9 hours ago [-]
Hey, how many opt-out features like this violate the openhome foundation supposed privacy stance ?
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
atmanactive 5 hours ago [-]
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).
saghm 17 hours ago [-]
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.
13 hours ago [-]
drum55 13 hours ago [-]
"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.
5kyl4b 17 hours ago [-]
[flagged]
hypfer 17 hours ago [-]
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.
frenck 17 hours ago [-]
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
threecheese 15 hours ago [-]
Cheers. Same. (well, not with mrs frenck- that'd be scandalous!)
tejtm 16 hours ago [-]
good bye
jrmg 16 hours ago [-]
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.
subscribed 14 hours ago [-]
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.
iAMkenough 15 hours ago [-]
> It’s not a lie if the speaker believes it to be true
I'm looking forward to that latest Elizabeth Holmes documentary.
rc5150 15 hours ago [-]
"It's not a lie if you believe it."
-George Costanza
frenck 17 hours ago [-]
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
aagadg 16 hours ago [-]
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.
kevinsundar 10 hours ago [-]
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.
ectospheno 15 hours ago [-]
It was far beyond “more dismissive than they should have been”.
flaunf221 15 hours ago [-]
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.
13 hours ago [-]
subscribed 14 hours ago [-]
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.
philipwhiuk 17 hours ago [-]
> 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.
atmanactive 14 hours ago [-]
I would consider a single byte sent to any server without my explicit permission a breach of trust.
fg137 4 minutes ago [-]
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.
greatgib 14 hours ago [-]
It is already enough to prove the existence of a password or that another password is not disclosed for example.
spease 12 hours ago [-]
Maybe consider HIBP’s offline tool as the default?
> 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?
Modified3019 16 hours ago [-]
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.
omega3 8 hours ago [-]
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.
cuu508 8 hours ago [-]
Where's the fix?
iAMkenough 15 hours ago [-]
Thanks for being here. Who made the decision to enable this by default without consent and without a GUI setting to disable it?
Henchman21 15 hours ago [-]
> My replies there were more dismissive than they should have been.
What would have been an appropriate amount of dismissiveness in your view?
ies7 10 hours ago [-]
> My apologies
You shouldn't have to apology to anyone.
idiotsecant 14 hours ago [-]
I don't understand why this is a hill to aggressively die on.
14 hours ago [-]
doobiedowner 17 hours ago [-]
>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?
atmanactive 14 hours ago [-]
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.
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
kaashif 13 hours ago [-]
I doubt the guy is malicious, but it should really be obvious why people are nervous about this stuff. If I put a password into a home automation tool, is my default expectation that it's going to phone home and send any information (even if it's just a bit of information about a hash) about my passwords?
Which option will minimize the feelings of betrayal and violation: making this feature opt-in or opt-out?
Any level of understanding of humans will produce the right answer.
fg137 17 hours ago [-]
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.
overtone1000 16 hours ago [-]
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.
jeremyjh 1 hours ago [-]
He hasn't apologized for the feature existing, or acknowledged that it is a security problem (information leak). He apologized for being an asshole. He hasn't acknowledged that its the wrong default.
His judgement is so poor we simply can't trust him to make correct decisions about the software he is building, there are doubtless other security issues.
flapperdeflip 16 hours ago [-]
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".....
overtone1000 15 hours ago [-]
It does seem that this is an unforgivable offense for many HN commenters, which makes me wonder what kind of Home automation those folks are running. Google Home? Amazon Alexa? Samsung SmartThings? Apple Homekit?
wtallis 15 hours ago [-]
The answer is obvious: we would rather have no home automation than have home automation that can't be trusted.
fg137 15 hours ago [-]
What is unforgivable?
Is there anything wrong with (not) going with a solution based on your personal belief?
You are free to make your own decision.
13 hours ago [-]
15 hours ago [-]
sgarland 15 hours ago [-]
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.
mook 12 hours ago [-]
Odd; the first comment I see from them explicitly mentions that he can't actually stop it due to the license, and it's just a request; per GitHub, that text existed in the first revision of that comment.
> As the author of the package that is being re-packaged here. I'm against it being repacked into here.
> While licensing wise I cannot stop you, I do hope you can honor my request.
sgarland 11 hours ago [-]
Yes, I understand that. My point was that’s not how it works; if you want to be able to control distribution, don’t use an OSS license, because it’s just weird to ask someone to not do something you implicitly granted them permission to do.
jeremyjh 1 hours ago [-]
Its possible to believe both that what he asked for is not reasonable, but also that he has every right to ask for it.
Maintainers have to make decisions about how to handle support burden, and these decisions are completely outside the scope or purview of any license. People who have never been in that position may have a hard time understanding it, but the NixOS maintainers absolutely do understand and that is demonstrated in that thread.
netsharc 17 hours ago [-]
Hah, his profile sure has a lot of bullshit about being human and positivity...
hypfer 17 hours ago [-]
[flagged]
fg137 15 hours ago [-]
My experience is that people don't typically change their behavior. Even if they do, I don't see any issue with bringing up this GitHub issue on HN which is a very suitable place to discuss technical topics (and others)
pschastain 13 hours ago [-]
> My experience is that people don't typically change their behavior.
Probably a good thing that you aren't in the therapy business
jeremyjh 17 hours ago [-]
I found it helpful and informative.
hypfer 16 hours ago [-]
[flagged]
jeremyjh 16 hours ago [-]
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.
16 hours ago [-]
hypfer 16 hours ago [-]
Uh? Yes you don't have to?
Who said that you would have?
chaps 15 hours ago [-]
I have no skin in this game, but: friend, are you okay? You're acting like an incredibly weird jerk.
hypfer 15 hours ago [-]
[flagged]
chaps 15 hours ago [-]
ok
hypfer 15 hours ago [-]
Btw, in case you might find that interesting:
My overarching point is that the outrage here is about Home assistant essentially not being "pure enough".
And I get that. I share those views.
But the people complaining about it, for the most part, actually can't handle what it would be if it was as "pure" as they say it should be.
Because that's then the role I have been playing here, and as you can see, that pisses people off even more than HA's friendly corporate diversions.
So, essentially, my point is that people actually want things to be exactly the way they are, because it is less dangerous to the ego.
Meaning that this is all just a charade. And a bad one at that that could not be further from the ideals, this platform wants to pursue.
Intellectual curiosity and all.
Good night!
Modified3019 16 hours ago [-]
Please reconsider what you think is respectful, because that was just straight up multiple personal insults.
hypfer 16 hours ago [-]
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"?
wtallis 15 hours ago [-]
Do you honestly expect anyone to believe that you didn't intend "memeOS" to be an insult?
hypfer 15 hours ago [-]
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 probably sense instead is more of a general abrasiveness-field. That was intentional (and obvious, for that matter).
wtallis 15 hours ago [-]
So do you believe that it's acceptable for your comments here to be laced with insults throughout, as long as they aren't intentionally and specifically targeted at the author of the comment you're replying to? Because I definitely don't think it's appropriate behavior to be denigrating an entire Linux distro and anyone whose values align with the purpose of that distro as merely participating in a meme.
hypfer 15 hours ago [-]
Yes, I do believe that nixOS (especially nixOS 5 years ago) was not to be taken seriously.
It was (and is) a never-ending drama faucet, because most people are in it for the identity and not for the utility. Or rather the utility primarily is the identity granted by using it.
14 hours ago [-]
robby_w_g 13 hours ago [-]
Nothing to be ashamed of? The behavior in that issue is petulant and embarrassing.
And it’s not bad faith to call out bad behavior. That’s some twisted logic.
jackpepsi 17 hours ago [-]
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.
subscribed 6 hours ago [-]
Are you representing the project?
Where did you get your public relations skills? In the school for ants?
Why don't you just ask someone who understands the _whole_ of the original issue instead of _mathematically proving_ we're just stupid?
If you're talking for HA - you guys are undoing _a lot_ of goodwill under this one post and it's interesting you either don't see it or don't care.
cbsks 13 hours ago [-]
I just didn’t expect my HA to be talking to any external services without me explicitly setting it up.
It is absolutely not OK to participate in this scheme on a users behalf without their affirmative consent. You simply cant know the context of people's situations.
Even the information that there likely ARE some hits from my IP is a huge signal leak, to me.
Iv been using HA for a very long time and it feels like a betrayal of trust to me.
jeremyjh 57 minutes ago [-]
The arrogance of developers who think that they have to understand every threat model before they can address a problem is responsible for so many exploited vulnerabilities.
Please if you develop software, acknowledge that you do not know what you do not know, and take every opportunity to reduce attack surface area and potential information leaks. This is what computer security experts do.
csoghoian 17 hours ago [-]
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.
flapperdeflip 17 hours ago [-]
The feature is not the problem.
gcommer 16 hours ago [-]
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."
Arcuru 16 hours ago [-]
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.
according to that sharing a part of the hash is a risk. it could for example end up in logged urls somewhere. it's a pity that the argument revolves around absolutes ("this is bad", "no, it's not") instead of actually investigating and explaining why they see a problem here.
someguydave 16 hours ago [-]
because why should my electric light scheduler be in the business of inspecting my passwords and furthermore involving third parties in inspecting my passwords?
atmanactive 14 hours ago [-]
Absolutely. Couldn't agree more.
14 hours ago [-]
drnick1 11 hours ago [-]
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.
AlienRobot 16 hours ago [-]
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.
eranation 16 hours ago [-]
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?
easterncalculus 16 hours ago [-]
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.
flapperdeflip 16 hours ago [-]
Don't shoot the messenger....
easterncalculus 14 hours ago [-]
Viss is trying to claim there is a security risk here when there isn't one. It's totally fair game to mention that.
jwitthuhn 13 hours ago [-]
As implemented it leaks information to HIBP. Whether or not that is a risk depends on your threat model. Leaking information about your local environment is a fact regardless of your threat model.
joejoejoe2 6 hours ago [-]
It should have remained a privacy matter, the security claims are just confusing .
As he said: "This mechanism could be abused by a malicious threat actor with access to the home assistant github repos in a variety of ways." -> If you get access to write to the Github repo, yes in fact you can for sure do much more damage without ever touching this feature.
Also "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." -> Waiting for it.
nullc 11 hours ago [-]
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.
ziiinq 11 hours ago [-]
[dead]
altairprime 17 hours ago [-]
(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.
It'll be interesting to see whether that gets accepted or not.
Rygian 17 hours ago [-]
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.
n42 15 hours ago [-]
It is not an invasion of privacy
this rubbed me the wrong way.
absolutely no one but me gets to decide what is an invasion of my privacy.
deadbunny 17 hours ago [-]
What PII do you think is being sent to HIBP?
jwitthuhn 13 hours ago [-]
The user's IP address.
Matticus_Rex 17 hours ago [-]
It's certainly an overstep, but just the hash they're sending wouldn't be PII.
Rygian 16 hours ago [-]
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.
nicce 17 hours ago [-]
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.
Rygian 17 hours ago [-]
Undoing personal information for a purpose different than the purpose for which it was collected.
TavsiE9s 18 hours ago [-]
Tough one. I get the intention but this should've been opt-in.
Klaus23 13 hours ago [-]
I think it's reasonable to argue that this should be an opt-in feature. The HIBP k-anonymity method is rather limited. It's not like homomorphic encryption, which perfectly shields information as long as the encryption is not broken. If an attacker wants to brute-force a password on a server, they have the advantage of only having to try one in a million passwords.
interf4ce 17 hours ago [-]
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]."
mcmcmc 17 hours ago [-]
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
interf4ce 15 hours ago [-]
Yep, that reply was posted after my comment here, so it turns out the documentation really was the right place for the issue.
speerer 16 hours ago [-]
A rare occasion where the AI response was an improvement on the human-written ones.
TZubiri 17 hours ago [-]
>>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.
dpark 17 hours ago [-]
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.)
subscribed 5 hours ago [-]
How is "_I really like your software but I the way X is solved bothers me, so I'm going to modify it thanks to your prior permission_" a threat?
"a competing product", perhaps for these pissed with the deb's human skills or those who want to use it in the unique environment he refuses them to adapt them to, contrary to his own licence?
No, seriously, intimidation? "Your position is untenable for us, we'll find another way forward" is a "let's agree to disagree", not more.
echoangle 14 hours ago [-]
Is “I won’t buy this car if you don’t give me a discount” a threat too?
ncr100 14 hours ago [-]
It is not a threat to pass along an intention of performing a non-harmful action.
Let me add some more double negatives in there.... It's not not a threat to not keep quiet about intention to not not cause pain to another person.
dpark 14 hours ago [-]
Sure. The threat here is the loss of the sale.
I don’t really care though. Call it whatever you want.
subscribed 5 hours ago [-]
The benefit of giving a discount is actually _getting a sale_
The way I read your response is "you must buy my X, otherwise you're negatively impacting me already" and it's something turned on its head.
ncr100 14 hours ago [-]
It is not a threat.
Threatening is expressing an intention to cause pain or harm.
This is not that.
dpark 13 hours ago [-]
Posting the same narrow definition 6 times doesn’t make it true. In one of your many replies you cite dictionary.com. This is the top definition on dictionary.com when I load it:
a declaration of an intention or determination to inflict punishment, injury, etc., in retaliation for, or conditionally upon, some action or course.
But you do you.
ncr100 9 hours ago [-]
<3 thanks!
16 hours ago [-]
TZubiri 16 hours ago [-]
“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.
ncr100 14 hours ago [-]
A threat is not an ultimatum.
A threat is an intention to cause harm.
TZubiri 16 hours ago [-]
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
dpark 16 hours ago [-]
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.”
subscribed 5 hours ago [-]
>a negative outcome that I will inflict
So if you're a developer of OSS and released something that _already has inflicted_ a measurable negative outcome for me -- that's okay.
But if I in response say "I don't like, I'm going to fork and use that software without that feature" -- that's a threat to the dev?
I'd say it's very much double standards, especially since in that case the negative action in the original software has already happened and is already negatively impacting the people considering the fork.
And you're saying that them, by wanting to cease it, are the bad guys.
nklow 15 hours ago [-]
>a negative outcome that I will inflict
And what exactly is the negative outcome being inflicted by someone not using the software? What is the injury or harm, and to who?
dpark 15 hours ago [-]
That was pretty clear from the comment, no?
1. The software will have one less user. (Implication was potentially many fewer given “we” would uninstall.)
2. The software will have one more competing product (forked from their own work).
Most people willing to put their time and energy into building software for others would consider losing users to be a moderate negative and having their work potentially forked and having to compete with a derivative a strong negative.
“We will fork” is a strong threat. It is basically a statement that “we” will fight the maintainer for the effective future of the project. Many open source projects have been eclipsed by their own forks.
nklow 15 hours ago [-]
>1. The software will have one less user. (Implication was potentially many fewer given “we” would uninstall.)
And what is the injury or harm of that? The developer said they wouldn't action the change and indirectly suggested the user to fork it - "it is open source after all".
>2. The software will have one more competing product (forked from their own work).
This is the very nature of open-source software. Labeling it a "competing product" makes many assumptions that aren't earned. We're talking about a user saying an opt-out feature should be opt-in. If I forked LibreOffice because it contained features I did not like, am I now making a competing product? Am I harming or injuring the repo I forked? Am I fighting the LibreOffice developers?
>Most people willing to put their time and energy into building software for others would consider losing users to be a moderate negative and having their work potentially forked and having to compete with a derivative a strong negative.
The developer didn't seem to consider it a moderate negative.
>“We will fork” is a strong threat. It is basically a statement that “we” will fight the maintainer for the effective future of the project.
You're expanding the scope of what was said. Saying "I will fork your open source software" [to make an opt-out feature, opt-in] is not "fighting" the maintainer for the "future of the project" - it's a core element of open-source software.
dpark 14 hours ago [-]
> And what is the injury or harm of that?
Sure. If you don’t care about whether your open source software has users, then there is no harm. People who maintain open source software for free usually do it out if a sense of pride and accomplishment that is tied to how many people use it, though.
> The developer said they wouldn't action the change and indirectly suggested the user to fork it - "it is open source after all".
They said that after the user already threatened to do so. You’re reversing the order. It was not “I recommend this” but “If you’re gonna do it I can’t stop you”.
> If I forked LibreOffice
If all you are doing is cloning the repo in GitHub then sure, you aren’t competing. But LibreOffice is a great example because it is specifically a fork that intended to and succeeded in replacing its parent project.
If someone says “we’re going to fork this because we disagree with your maintenance of the project”, they probably don’t mean “I’m gonna click ‘fork’ on GitHub.”
nklow 14 hours ago [-]
>Sure. If you don’t care about whether your open source software has users, then there is no harm. People who maintain open source software for free usually do it out if a sense of pride and accomplishment that is tied to how many people use it, though.
Specifically in this case, it seems the developer isn't doing it for free - their work is at least somewhat sponsored and looking at their site it seems to be their full-time work. I'm not diminishing their time and effort, but this isn't someone working late nights that is hoping their software gets its first 100 users.
>They said that after the user already threatened to do so.
There's a button on every public GitHub repo to fork it. If I say "I'm going to hit that button" (even in a particularly rude way) - is that really a threat? It is functionality built into not only the site, but also the culture and code licensing that underpins any open-source project. I struggle to see how anyone could threaten open-source code by saying they'll fork it. Go ahead - that was specifically designed into the license for any reason. It's so prevalent that it has its own button.
>If someone says “we’re going to fork this because we disagree with your maintenance of the project”, they probably don’t mean “I’m gonna click ‘fork’ on GitHub.”
What then is your expectation for what it means? By saying "we're going to fork this software" are they now starting a competing company? Making hardware products using it? Monetizing the pre-existing work? Selling subscriptions?
These are all examples that I read your comment as implying that aren't actually enumerated or described anywhere.
My expectation for someone saying "I don't like how you're running this project and will fork it" is _exactly_ that they'll hit the fork button and make their own project. That's why it's open-source, that's how open-source software works - that's what the button is for. Even if they then went and built an entirely competing business, around one minor change I specifically chose not to make - then what is the issue? The license allows it - and I chose the license.
dpark 13 hours ago [-]
We’re arguing hypotheticals about what the commenter meant when they said they would fork. I have no evidence they specifically meant that they would create a competitor and you have no evidence that they meant they would quietly fork and change the one thing they cared about. Fork has more than one meaning in this context. (LibreOffice project was forked from OpenOffice.org, while LibreOffice core repo has 983 forks on GitHub.)
I think we can agree to disagree because our assumptions are at odds and we have no data to bridge that gap.
flaunf221 15 hours ago [-]
> best response is to just communicate you are not fixing X
You mean the response that was already written in a previous message and the response user decided to ignore so they can pester more?
jollymonATX 14 hours ago [-]
Seriously they did not need to handle this like this and it should be privacy first by default.
codedokode 11 hours ago [-]
The rule for a decent software should be, not a single packet sent without user authorization. I wonder if such software even exists.
15 hours ago [-]
Cameri 17 hours ago [-]
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.
deadbunny 17 hours ago [-]
The same dev doesn't even like others packaging his open source libs.
His reasoning is sound. See the infamous Xscreensaver saga for just one of many examples, or the abuse Stenberg receives for merely making curl available.
ncr100 13 hours ago [-]
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.
csnover 17 hours ago [-]
> 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.
rrvsh 14 hours ago [-]
../Frenck
CountGeek 13 hours ago [-]
This common among Dutch culture.
15 hours ago [-]
onionisafruit 18 hours ago [-]
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.
subscribed 4 hours ago [-]
Read the NixOS drama for another datapoint.
16 hours ago [-]
abletonlive 17 hours ago [-]
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.
hypfer 16 hours ago [-]
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.
geerlingguy 11 hours ago [-]
This should definitely be opt-in.
thunderfork 17 hours ago [-]
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?
jeroenhd 15 hours ago [-]
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.
secabeen 11 hours ago [-]
Yeah. The use of the word "scan" in the original article and the title is misleading. It doesn't scan your system looking for passwords and testing them. It appears to take the password you give to HA (either as your HA Password to login to HA, or for an integration) and check those. That is a much smaller impact than is being assumed by many here.
jocular 17 hours ago [-]
Frenck is the worst part of Home Assistant. He shits on so many things with just a hand wave and no attempt at justification.
flanz_10 18 hours ago [-]
> 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".
flapperdeflip 17 hours ago [-]
Working on a fork already: Lets spend some tokens! :)
ThatPlayer 13 hours ago [-]
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
eur0pa 18 hours ago [-]
Awfully tone deaf responses
l-albertovich 18 hours ago [-]
And that kids is a clear example of how not to interact with people online.
zephyreon 18 hours ago [-]
Yeah not a good look. This is probably the worst way to handle community feedback.
l-albertovich 17 hours ago [-]
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.
gvfsa 17 hours ago [-]
Maybe he shouldn’t be accessing people’s passwords. If you start looking into someone’s wallet you can expect an abrasive response.
l-albertovich 17 hours ago [-]
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.
ragall 17 hours ago [-]
The developer's reply was very reasonable and measured. The user, on the other hand, was very rude.
- 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.
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.
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.
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"
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.
No software should ever make network requests without your consent.
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.
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 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).
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.
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
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.
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.
This is the problem. You do not know what you do not know. There have already been papers written about the problems with HIBP. You don't have to understand the threat model for it to exist.
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.
I value my privacy quite highly, but I don't mind harmless, anonymous use of my data
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.
Is there any realistic value to knowing "how many unique passwords you use"? If you already have one of my passwords compromised, you'd presumably try it on the rest of my accounts regardless?
My browser fingerprint leaks, what, thousands of times more information than that - surely fixing applications like Chrome to have sensible privacy-preserving opt-in-only behavior is vastly more important than nagging some obscure open source software about an edge case that can barely be exploited?
If you know someone with N logins has N passwords it's a decent indication they use a password manager and so passwords are unlikely to be weak, if they have 1 password it's probably shared elsewhere and weak.
I also wasn't responding to a question asking about practical exploits, I was responding to a question that claimed the k-anonymity model is "provably anonymous" and "harmless". Since it clearly leaks some information it's definitely not the former and one could argue it's not the later though the "harm" is minimal.
> My browser fingerprint leaks, what, thousands of times more information than that - surely fixing applications like Chrome ...
I fail to see how the privacy nightmare of modern browsers is relevant to a discussion on whether opt-out signalling to third-party services is a reasonable stance for an open source project? By that metric no privacy bug is worth reporting because Chrome continues to exist. If only there was a term for this kind of non-sequitur...
"Leaks information" is perfectly compatible with "provably anonymous"
You have to prove that the leak is enough to actually de-anonymize someone to disprove anonymity.
I'm not saying it can't be done, but you're jumping ahead and skipping a very important step.
This is fundamental feature of all traffic sent via IP unfortunately.
The purpose of a browser is to make network requests. If I use a browser, I am implicitly giving it consent to make the network requests necessary for the web browsing I do.
This implied consent does not cover unnecessary requests, e.g. the adverts Firefox displays on new tabs by default are unacceptable, because I did not consent to them being downloaded. It also does not cover the network requests made by opening the "Extensions and Themes" menu, because merely looking at a configuration menu does not imply consent to make network requests.
But that fact that modern web browsers are a privacy disaster does not excuse bad behavior from other software.
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.
The site is called "Have I Been Pwned", thus the cutesy name of the flag...
The designer felt that "secure" included "is this password already published, online, in a known database breach", which is not an unreasonable interpretation.
The documentation has been clarified. There was a a feature flag. Calling this malicious is just absurd flame-bait.
Just my $0.02.
Seeing this, I'm not going to set up Home Assistant any time soon.
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.
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.
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.
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.
https://www.openhomefoundation.org/papers/privacy/
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.
But you are right, it is time to head downstairs for a beer with Mrs. Frenck.
../Frenck
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.
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.
I'm looking forward to that latest Elizabeth Holmes documentary.
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
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.
Too many OSS projects die because authors are too afraid to tell demanding users in which direction they could proceed and instead burn out.
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.
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.
Seeing this, I don't think I'm going to touch it. Alexa might be more respectful of user data.
https://haveibeenpwned.com/Passwords (“Download & Integrate”)
I’m curious what made you change your mind, perhaps seeing this getting traction on hn?
What would have been an appropriate amount of dismissiveness in your view?
You shouldn't have to apology to anyone.
Problem solved!
>My replies there were more dismissive than they should have been
What about this one?
Related discussion: https://news.ycombinator.com/item?id=27505277
It's not a good look taken together
Which option will minimize the feelings of betrayal and violation: making this feature opt-in or opt-out?
Any level of understanding of humans will produce the right answer.
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.
His judgement is so poor we simply can't trust him to make correct decisions about the software he is building, there are doubtless other security issues.
Is there anything wrong with (not) going with a solution based on your personal belief?
You are free to make your own decision.
> As the author of the package that is being re-packaged here. I'm against it being repacked into here. > While licensing wise I cannot stop you, I do hope you can honor my request.
Maintainers have to make decisions about how to handle support burden, and these decisions are completely outside the scope or purview of any license. People who have never been in that position may have a hard time understanding it, but the NixOS maintainers absolutely do understand and that is demonstrated in that thread.
Probably a good thing that you aren't in the therapy business
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.
Who said that you would have?
My overarching point is that the outrage here is about Home assistant essentially not being "pure enough".
And I get that. I share those views.
But the people complaining about it, for the most part, actually can't handle what it would be if it was as "pure" as they say it should be.
Because that's then the role I have been playing here, and as you can see, that pisses people off even more than HA's friendly corporate diversions.
So, essentially, my point is that people actually want things to be exactly the way they are, because it is less dangerous to the ego.
Meaning that this is all just a charade. And a bad one at that that could not be further from the ideals, this platform wants to pursue.
Intellectual curiosity and all.
Good night!
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"?
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 probably sense instead is more of a general abrasiveness-field. That was intentional (and obvious, for that matter).
It was (and is) a never-ending drama faucet, because most people are in it for the identity and not for the utility. Or rather the utility primarily is the identity granted by using it.
And it’s not bad faith to call out bad behavior. That’s some twisted logic.
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.
Where did you get your public relations skills? In the school for ants?
Why don't you just ask someone who understands the _whole_ of the original issue instead of _mathematically proving_ we're just stupid?
If you're talking for HA - you guys are undoing _a lot_ of goodwill under this one post and it's interesting you either don't see it or don't care.
It is absolutely not OK to participate in this scheme on a users behalf without their affirmative consent. You simply cant know the context of people's situations.
Even the information that there likely ARE some hits from my IP is a huge signal leak, to me.
Iv been using HA for a very long time and it feels like a betrayal of trust to me.
Please if you develop software, acknowledge that you do not know what you do not know, and take every opportunity to reduce attack surface area and potential information leaks. This is what computer security experts do.
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.
according to that sharing a part of the hash is a risk. it could for example end up in logged urls somewhere. it's a pity that the argument revolves around absolutes ("this is bad", "no, it's not") instead of actually investigating and explaining why they see a problem here.
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?
As he said: "This mechanism could be abused by a malicious threat actor with access to the home assistant github repos in a variety of ways." -> If you get access to write to the Github repo, yes in fact you can for sure do much more damage without ever touching this feature.
Also "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." -> Waiting for it.
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.
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.
It'll be interesting to see whether that gets accepted or not.
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.
absolutely no one but me gets to decide what is an invasion of my privacy.
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.
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]."
>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.
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.)
"a competing product", perhaps for these pissed with the deb's human skills or those who want to use it in the unique environment he refuses them to adapt them to, contrary to his own licence?
No, seriously, intimidation? "Your position is untenable for us, we'll find another way forward" is a "let's agree to disagree", not more.
Let me add some more double negatives in there.... It's not not a threat to not keep quiet about intention to not not cause pain to another person.
I don’t really care though. Call it whatever you want.
The way I read your response is "you must buy my X, otherwise you're negatively impacting me already" and it's something turned on its head.
Threatening is expressing an intention to cause pain or harm.
This is not that.
a declaration of an intention or determination to inflict punishment, injury, etc., in retaliation for, or conditionally upon, some action or course.
But you do you.
“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.
A threat is an intention to cause harm.
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
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.”
So if you're a developer of OSS and released something that _already has inflicted_ a measurable negative outcome for me -- that's okay.
But if I in response say "I don't like, I'm going to fork and use that software without that feature" -- that's a threat to the dev?
I'd say it's very much double standards, especially since in that case the negative action in the original software has already happened and is already negatively impacting the people considering the fork.
And you're saying that them, by wanting to cease it, are the bad guys.
And what exactly is the negative outcome being inflicted by someone not using the software? What is the injury or harm, and to who?
1. The software will have one less user. (Implication was potentially many fewer given “we” would uninstall.)
2. The software will have one more competing product (forked from their own work).
Most people willing to put their time and energy into building software for others would consider losing users to be a moderate negative and having their work potentially forked and having to compete with a derivative a strong negative.
“We will fork” is a strong threat. It is basically a statement that “we” will fight the maintainer for the effective future of the project. Many open source projects have been eclipsed by their own forks.
And what is the injury or harm of that? The developer said they wouldn't action the change and indirectly suggested the user to fork it - "it is open source after all".
>2. The software will have one more competing product (forked from their own work).
This is the very nature of open-source software. Labeling it a "competing product" makes many assumptions that aren't earned. We're talking about a user saying an opt-out feature should be opt-in. If I forked LibreOffice because it contained features I did not like, am I now making a competing product? Am I harming or injuring the repo I forked? Am I fighting the LibreOffice developers?
>Most people willing to put their time and energy into building software for others would consider losing users to be a moderate negative and having their work potentially forked and having to compete with a derivative a strong negative.
The developer didn't seem to consider it a moderate negative.
>“We will fork” is a strong threat. It is basically a statement that “we” will fight the maintainer for the effective future of the project.
You're expanding the scope of what was said. Saying "I will fork your open source software" [to make an opt-out feature, opt-in] is not "fighting" the maintainer for the "future of the project" - it's a core element of open-source software.
Sure. If you don’t care about whether your open source software has users, then there is no harm. People who maintain open source software for free usually do it out if a sense of pride and accomplishment that is tied to how many people use it, though.
> The developer said they wouldn't action the change and indirectly suggested the user to fork it - "it is open source after all".
They said that after the user already threatened to do so. You’re reversing the order. It was not “I recommend this” but “If you’re gonna do it I can’t stop you”.
> If I forked LibreOffice
If all you are doing is cloning the repo in GitHub then sure, you aren’t competing. But LibreOffice is a great example because it is specifically a fork that intended to and succeeded in replacing its parent project.
If someone says “we’re going to fork this because we disagree with your maintenance of the project”, they probably don’t mean “I’m gonna click ‘fork’ on GitHub.”
Specifically in this case, it seems the developer isn't doing it for free - their work is at least somewhat sponsored and looking at their site it seems to be their full-time work. I'm not diminishing their time and effort, but this isn't someone working late nights that is hoping their software gets its first 100 users.
>They said that after the user already threatened to do so.
There's a button on every public GitHub repo to fork it. If I say "I'm going to hit that button" (even in a particularly rude way) - is that really a threat? It is functionality built into not only the site, but also the culture and code licensing that underpins any open-source project. I struggle to see how anyone could threaten open-source code by saying they'll fork it. Go ahead - that was specifically designed into the license for any reason. It's so prevalent that it has its own button.
>If someone says “we’re going to fork this because we disagree with your maintenance of the project”, they probably don’t mean “I’m gonna click ‘fork’ on GitHub.”
What then is your expectation for what it means? By saying "we're going to fork this software" are they now starting a competing company? Making hardware products using it? Monetizing the pre-existing work? Selling subscriptions?
These are all examples that I read your comment as implying that aren't actually enumerated or described anywhere.
My expectation for someone saying "I don't like how you're running this project and will fork it" is _exactly_ that they'll hit the fork button and make their own project. That's why it's open-source, that's how open-source software works - that's what the button is for. Even if they then went and built an entirely competing business, around one minor change I specifically chose not to make - then what is the issue? The license allows it - and I chose the license.
I think we can agree to disagree because our assumptions are at odds and we have no data to bridge that gap.
You mean the response that was already written in a previous message and the response user decided to ignore so they can pester more?
https://github.com/NixOS/nixpkgs/pull/126326
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.
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.
In this case, frenck most certainly backtracked because they realized they were on the front page of HN and did not want the heat.
I'm torn. And sad.
Yeah, I agree with the maintainer, this strikes me as outrage theater over any actual problem, no?
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.
what a petty answer. "just fork it bro".
> please let us know so we can uninstall and fork.
So he's letting them know
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.
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.