unRAID "Phone Home" discussion

[sparklyballs]

Other than generating a bunch of extra non-core development time for Limetech, would this solution appease the pitchfork wielders?

 

Maybe Limetech could eventually change things up a bit with the online requirement in the beta/rc, maybe have the server generate a challenge code if it couldn't directly reach the internet that you could enter into their website using another device, and it would generate a response code that would allow the server to start. Valid only for a limited time window ~24 hours, and non-repeating. Challenge codes generated with wrong date would generate a date error and tell the user to fix the time on the server and refresh another code. Codes from blacklisted versions or serial numbers could also flagged. Code entry on the website would probably need to be captcha'd and rate limited to prevent abuse.

 

 

Since when is disagreeing with something, and in the arena of computers especially, having concerns over possible security issues from data retention (we don't know if any data is being held, but until we are categorically told either way, the concern is there) "wielding a pitchfork" ?

[rick.p]

Honestly I'd expect this from a big name vendor but not from LT. This is horrible idea and, in my humble opinion, should be removed immediately.

 

If you are running under a TRIAL key I can see it, if you have a PAID LICENSE KEY, then it should be OPTIONAL (ie. "oh tried to check in but couldn't, but since you have a paid key, I'll run but put a big "INTERNET VALIDATION FAILED" in glowing red letters on the banner of the WebGui)

 

You paid for the latest stable. Not the beta/rc

 

The stables don't have that.

 

And once again, it is NOT activation or license validation. It is a safety measure only intended for beta and rc releases. Please read the beta/rc announcement messages to find out why internet connection is required before grabbing your pitchfork

 

Part of an RC process is running in Real World conditions. That may mean in no net connectivity situations. Compromise, Mandatory in BETA, Optional (as I put above) in RC.

[navvy]

You do realise this only applies to Betas and RC's right?

 

You do realise something similar also applies to trial keys right?  So the step from 'only Betas and RCs' for 'safety' has already been stretched to include full version, stable, SAFE but unlicensed users.  Seems like a bit of a contradiction to me already.

 

Who's to say tomorrow they decide we've designed this great licensing system and now we're going to use it for everyone.  It's only one more step!

 

I think the announcement and implementation of this 'safety feature' was ballsed up from day one.  It was handled poorly.  If they're serious about implementing this, more information needs to be given especially about what is being sent and stored by the activation server.  And list all the reasons for implementing, not just the 'happy friendly we're the good guys' ones.

[CHBMB]

You do realise this only applies to Betas and RC's right?

 

You do realise something similar also applies to trial keys right?  So the step from 'only Betas and RCs' for 'safety' has already been stretched to include full version, stable, SAFE but unlicensed users.  Seems like a bit of a contradiction to me already.

 

Who's to say tomorrow they decide we've designed this great licensing system and now we're going to use it for everyone.  It's only one more step!

 

I think the announcement and implementation of this 'safety feature' was ballsed up from day one.  It was handled poorly.  If they're serious about implementing this, more information needs to be given especially about what is being sent and stored by the activation server.  And list all the reasons for implementing, not just the 'happy friendly we're the good guys' ones.

 

OK, fair enough more info on what's being sent and stored.  But to be fair to LT they have given a reasonable justification for their choice, and stated explicitly it won't be in the final release.  The fact that some people don't believe them or disagree with their reasoning, doesn't make it wrong.  Maybe the reason really is what they've stated multiple times it is.  Over the years LimeTech has earned my trust, I don't necessarily agree with all their decisions, but until I see concrete proof to the contrary I do believe what they've said on the matter.

 

It's only one step for them to implement a mechanism to rm -rf all our data, but does anyone seriously believe they would?

 

 

[NAS]

I am not sure it is as clear cut as beta/RC. The last time this was asked LT "reserved the right" to keep it in the live product. (Too busy to find the quote).

 

My gut is that this was hedging bets but at the same time it adds even more confusion.

 

Better this is all out in the open, debated and decided once and for all. The current stance is confusing, the information security implications are real and it only leads to this very debate.

[jbartlett]

Concerning the kill switch on beta/RC, one of the late 6.0 betas did have some big issues show up in betas far down the line

 

6.0b7&8 had a chance of silently corrupting your data drives (ReiserFS bug) - this one could have easily made it into an RC

6.0b13 had a chance of causing the cache drives to show up as unformatted

 

This is the reason for the kill switch. It is to lesson the chance of totally hosing YOU up in the event a bug like this misses testing (even upstream from LimeTech).

[PeterB]

I am not sure it is as clear cut as beta/RC. The last time this was asked LT "reserved the right" to keep it in the live product. (Too busy to find the quote).

This is what you were referring to:

Quote

 

    Will this requirement for Internet still be present in 'Final'?  If so, I will, regrettably, have to remain on v6.1.9 or investigate alternative storage solutions.

 

As of today I can say "no", but we have to reserve the right to change things it it makes business sense.  But you can be assured of this: we will never screw over our existing customers.

[BRiT]

I don't see how 1 check at startup time helps to recall bad or dangerous code in the majority of situations. My array stays started and running for months at a time and I'm sure others are the same. If there was a nasty issue many could still be running the nasty code months later. The only issue this solves for certain is on new installs which can be controlled by removing the files from the download server.

[mostlydave]

You do realise this only applies to Betas and RC's right?

 

You do realise something similar also applies to trial keys right?  So the step from 'only Betas and RCs' for 'safety' has already been stretched to include full version, stable, SAFE but unlicensed users.  Seems like a bit of a contradiction to me already.

 

Who's to say tomorrow they decide we've designed this great licensing system and now we're going to use it for everyone.  It's only one more step!

 

I think the announcement and implementation of this 'safety feature' was ballsed up from day one.  It was handled poorly.  If they're serious about implementing this, more information needs to be given especially about what is being sent and stored by the activation server.  And list all the reasons for implementing, not just the 'happy friendly we're the good guys' ones.

 

This pretty much sums up how I feel about it, just written way better than I did. "Safety Feature" seems like a real stretch to me. I don't know about anyone else running the betas but I pay attention to the release threads while I have them installed just in case something were to happen.

[mostlydave]

I don't see how 1 check at startup time helps to recall bad or dangerous code in the majority of situations. My array stays started and running for months at a time and I'm sure others are the same. If there was a nasty issue many could still be running the nasty code months later. The only issue this solves for certain is on new installs which can be controlled by removing the files from the download server.

 

This is exactly what I'm thinking, how is a forced phone home better than pulling a bad release?

[ryoko227]

 

IMPORTANT

[*]Your server must have access to the Internet to use the unRAID 6.2 rc.

[*]Posts in this thread should be to report bugs and comment on features ONLY.

 

 

Whether or not you agree with the policy of having the phone-home kill switch feature as part of an RC or not is a moot point (and per the OP should be argued/discussed elsewhere). That being said, the fact that it IS part of the RCs could not possibly be more clearly stated in the OP. The few people who have had an issue with not being able to start their arrays have fully acknowledged that they themselves made "boo boos" and despite their frustration/annoyance with it, understand that this feature was part of the RC and that their mistakes (or simple inability to reach an internet connection) are their own responsibility. Some have said that "our data is our responsibility, so LT should give us the option to shoot ourselves in the foot" (paraphrased for brevity). I would like to argue that some have already done this, they have 0 access to their data, it was their responsibility to ensure that they could properly use the product as stated, and they failed (or are unable) to do so. Now some of you are up in a rage about this... why? Drop down to 6.19 stable (No internet required), use a tethered hotspot to get your array started, or any of the other good solutions provided by your fellow unRAID users. There ARE solutions to your issues.

 

It's so frustrating to read PAGES of people complaining about this when it couldn't be more clearly stated. If some of you are all uppity about this, I can't imagine what it would be like it there was an actual massive error that caused terabytes of valuable data to be lost. Because of <= that scenario, LT is doing what it thinks is best to protect the integrity of the product, by implementing a measure that can kill a bad release and try to ensure that end users can't use potentially harmful code, keeping you from destroying your rigs. Is it perfect, NO, is it far better than putting out a forum announcement stating "Don't use this version, it'll blow up your data", YES. It would only take one screw up, one person to install a "bad version" to damage the brand and destroy consumer confidence. If you don't agree with LT's choice to implement this, then do not use the betas, do not use the RCs. They are unstable, they are works in progress, and most importantly; they are voluntary. Again, LT chose this, they made it abundantly clear in the OP of each release. Don't agree, don't use the unstable versions, period.

[trurl]

If you're clever enough to use a beta/RC, you should be clever enough to revert to stable if necessary. And with unRAID that is much easier and quicker than trying to downgrade Windows for example.

[navvy]

I was affected by the Reiserfs bug and lost/couldn't trust terabytes of storage which I restored from backups.  My issue isn't what LimeTech are trying to do.  It is with how they've done it.  Citing safety as the reason for the checkin, then forcing it on trial users using stable versions is a direct contradiction.  This itself erodes trust in a brand I personally have supported, both financially and through recommendations to others.  And shows the already existing ability to enable this for all users.

 

Regardless, I don't think it is unreasonable to expect disclosure on what data is being sent and/or stored on the LimeTech servers using this new feature.

[BRiT]

 

IMPORTANT

[*]Your server must have access to the Internet to use the unRAID 6.2 rc.

[*]Posts in this thread should be to report bugs and comment on features ONLY.

 

 

Whether or not you agree with the policy of having the phone-home kill switch feature as part of an RC or not is a moot point (and per the OP should be argued/discussed elsewhere).

 

I disagree. I consider the phone-home a "feature" and hence the discussion about it is entirely on point and allowed.

[ljm42]

Could we possibly move this discussion about the phone home requirement to a new thread so this release thread can focus on issues specific to rc4?

[trurl]

This didn't really seem to fit anywhere else so I have put it here in Feature Requests.

[danioj]

The "Phone Home" discussion has been moved to Feature Requests.

 

[iurl=https://lime-technology.com/forum/index.php?topic=51379.0]https://lime-technology.com/forum/index.php?topic=51379.0[/iurl]

 

If you wish to continue go there. This thread is specifically for rc4 discussion.

 

trurl, I am very disappointed with your approach to this. While some of the comments might have detracted somewhat from what my post was about, it was discussion - and constructive discussion too. There was a time when that was encouraged on this forum. That being said while moving the broader discussion was perhaps a move I (as a Mod of old) would have taken, you have also removed my security/data question.

 

Therefore I am re-posting. The question below is direct and relates to a feature of RC4. The question is NOT a Feature Request. As this question relates to an exisiting feature I feel it is very much on point and as such should be allowed to remain in this forum.

 

I have had some further thought on this. I did some quick research on the topic and have found limited information.

 

So therefore, a direct question:

 

@Limetech @eschultz @jonp

 

Can you please describe the data that is captured and transmitted in your call-home (and any other communication between my servers - both ways - and LT servers), explain exactly why each peice of that data is required and if any part or all of it is stored?

 

Based on your answer to the above question I may have follow-ups.

 

I do not do this to be combative or generate more broader discussion. Please respect what is clearly a valid question about an exisiting feature and allow it to remain in the most appropriate forum.

[ironicbadger]

 

IMPORTANT

[*]Your server must have access to the Internet to use the unRAID 6.2 rc.

[*]Posts in this thread should be to report bugs and comment on features ONLY.

 

 

Whether or not you agree with the policy of having the phone-home kill switch feature as part of an RC or not is a moot point (and per the OP should be argued/discussed elsewhere). That being said, the fact that it IS part of the RCs could not possibly be more clearly stated in the OP. The few people who have had an issue with not being able to start their arrays have fully acknowledged that they themselves made "boo boos" and despite their frustration/annoyance with it, understand that this feature was part of the RC and that their mistakes (or simple inability to reach an internet connection) are their own responsibility. Some have said that "our data is our responsibility, so LT should give us the option to shoot ourselves in the foot" (paraphrased for brevity). I would like to argue that some have already done this, they have 0 access to their data, it was their responsibility to ensure that they could properly use the product as stated, and they failed (or are unable) to do so. Now some of you are up in a rage about this... why? Drop down to 6.19 stable (No internet required), use a tethered hotspot to get your array started, or any of the other good solutions provided by your fellow unRAID users. There ARE solutions to your issues.

 

It's so frustrating to read PAGES of people complaining about this when it couldn't be more clearly stated. If some of you are all uppity about this, I can't imagine what it would be like it there was an actual massive error that caused terabytes of valuable data to be lost. Because of <= that scenario, LT is doing what it thinks is best to protect the integrity of the product, by implementing a measure that can kill a bad release and try to ensure that end users can't use potentially harmful code, keeping you from destroying your rigs. Is it perfect, NO, is it far better than putting out a forum announcement stating "Don't use this version, it'll blow up your data", YES. It would only take one screw up, one person to install a "bad version" to damage the brand and destroy consumer confidence. If you don't agree with LT's choice to implement this, then do not use the betas, do not use the RCs. They are unstable, they are works in progress, and most importantly; they are voluntary. Again, LT chose this, they made it abundantly clear in the OP of each release. Don't agree, don't use the unstable versions, period.

 

I choose to use Linux because it is free an open. UnRAID itself might not be, but the underlying core fundamentals remain. Implementing a feature such as this, regardless of how clearly it might be communicated is not a good idea in my opinion. This whole debate raises serious ethical questions about the integrity of the vendor, who hasn't involved themselves in our discussion yet - make of that what you will.

 

I'm not saying LT are evil. I'm not saying don't use LT software. I am saying that I don't agree with a kill-switch preventing my system from booting in any circumstances. Dev boxes, which is what BETAs and RCs are hopefully primarily run on may well be subject to air gaps for connectivity and preventing those from booting alienates the very people who make this community what it is. My 2 cents.

[jwegman]

...as I understand it, this 'phone home' caveat is a condition of running the beta/rc/trial, and *not* a feature of the 6.2 GA release (this has been *clearly* stated by Limetech).  It's up to you to satisfy the condition(s) of running a beta/rc/trial.  And I for one, don't see it as unreasonable, even though I anecdotally have encountered my own small difficulty with it following a recent severe storm/power outage (exceeded ups runtime) where my Internet was down for more than a few hours after power returned, resulting in arrays that refused to start...

 

However, if it becomes a condition of a GA release (which would most likely be to facilitate a 'license key' server lookup of black-listed usb keys), then the current 'phone home' implementation would irk me and I may be tempted to buy a pitch fork to join the mob in protest. 

 

In closing, Internet connectivity should *not* be a requirement of *any* future GA release that my existing (3) server licenses entitle me to.

[HellDiverUK]

The "Phone Home" discussion has been moved to Feature Requests.

 

 

 

Yeah, because it's a feature request.  Not. 

 

Now where did I leave my facepalm meme?

[mostlydave]

And this kind of treatment of customers having a civil productive conversation (with zero input from LT) is what makes me very nervous about the phone home.

 

I paid for a pro license, I think Unraid is a wonderful product, why ruin it with this "feature". There's nothing worse than punishing your paying customers for paying and beta testing for you.

 

I really like to think that LT implemented this with good intentions, but that's getting harder and harder to buy into as they remain silent on the issue during our recent discussion and then sweep that conversation into a corner of the forum.

 

If LT won't allow a reasonable discussion and can't tell us exactly what information the product we paid for is sending to them, how are supposed to trust them and accept that? Is my server going to refuse to boot someday because LT disabled it remotely? What if they are hacked and someone else throws that switch? I don't know and the level of communication we get from LT doesn't do anything to help build confidence.

 

If the phone home continues to be a requirement for betas than this was my last. I pray it never makes it into the full release for any reason, and if it does I'm gone and I don't think I'll be alone.

[navvy]

I have had some further thought on this. I did some quick research on the topic and have found limited information.

 

So therefore, a direct question:

 

@Limetech @eschultz @jonp

 

Can you please describe the data that is captured and transmitted in your call-home (and any other communication between my servers - both ways - and LT servers), explain exactly why each peice of that data is required and if any part or all of it is stored?

 

Based on your answer to the above question I may have follow-ups.

 

I agree.  This should be LT's minimum response.  The rest of the discussion can continue elsewhere.

[trurl]

The "Phone Home" discussion has been moved to Feature Requests.

 

 

 

Yeah, because it's a feature request.  Not. 

 

Now where did I leave my facepalm meme?

Let me know where you think it belongs and I will be happy to move it again.

[trurl]

The "Phone Home" discussion has been moved to Feature Requests.

 

[iurl=https://lime-technology.com/forum/index.php?topic=51379.0]https://lime-technology.com/forum/index.php?topic=51379.0[/iurl]

 

If you wish to continue go there. This thread is specifically for rc4 discussion.

 

trurl, I am very disappointed with your approach to this. While some of the comments might have detracted somewhat from what my post was about, it was discussion - and constructive discussion too. There was a time when that was encouraged on this forum. That being said while moving the broader discussion was perhaps a move I (as a Mod of old) would have taken, you have also removed my security/data question.

 

Therefore I am re-posting. The question below is direct and relates to a feature of RC4. The question is NOT a Feature Request. As this question relates to an exisiting feature I feel it is very much on point and as such should be allowed to remain in this forum.

 

I have had some further thought on this. I did some quick research on the topic and have found limited information.

 

So therefore, a direct question:

 

@Limetech @eschultz @jonp

 

Can you please describe the data that is captured and transmitted in your call-home (and any other communication between my servers - both ways - and LT servers), explain exactly why each peice of that data is required and if any part or all of it is stored?

 

Based on your answer to the above question I may have follow-ups.

 

I do not do this to be combative or generate more broader discussion. Please respect what is clearly a valid question about an exisiting feature and allow it to remain in the most appropriate forum.

I did not REmove anything. It is still in that other thread. Nevertheless I will leave the repeat here as long as it doesn't blow up into another several pages in this thread that is supposed to be about things that are specific to this particular release.

 

Another user complained that I had put it in Feature Requests. I agree that it is a poor fit for there. Where do you think the discussion belongs? It does not belong in this thread.

[navvy]

I'm just getting very concerned that something that was never a part of the unraid licensing or feature set has been added so quickly and with almost no official comment from LT, when the community is so vocal about our concerns.

 

It really worries me that a company that has always been so user focussed and still manages to add in kernel modules, etc. on request, has completely shutdown and not entered into the discussion.

 

All this is going to do is continue to wear away the trust that has been solidly built over the years.