"Remote harvesting" is very confusing for people who don't understand the technical background of this feature.
Any ideas how we could call it?
There is the idea to call it "secure harvesting".
Any other ideas?
Edit:
List of all proposals:
- Remote harvesting
- Secure harvesting
- No risk harvesting
- some acronym for "proxy private key secure remote harvesting" or similar
- Harvest by proxy
- Private harvesting
- Trustless harvesting
- Premium secure harvesting
- Delegated Harvesting
I have activated remote harvesting, used it, and deactivated it, and I am still not completely sure what it is. hahahaha
I think there could definitely be a better term for remote harvesting.
I wish somebody would do a little bit of a write up about what it is, how it works, and possible real world uses for it.
I can explain what remote harvesting is, but this thread actually has another topic.
When you activate local harvesting, the private key of the account for which you activated local harvesting is sent to the connected NIS. NIS probably uses that private key to sign a block (I'm not 100 % sure about that) when it gets one for harvesting (the higher your importance score the higher your chance to be allowed to harvest a block and earn all the fees inside that block).
When you are connected to a remote NIS, you don't want to send your private key to that remote NIS of course, because you don't know if that NIS is maye hosted by a scammer, who is just collecting private keys to steal the funds from the according accounts. So if you want to use the importance of your account to harvest with a remote NIS, "remote harvesting" is a secure solution: NCC creates another account for you in the background and transfers your importance score to that new account, but no funds are transacted. So you now have an empty account (no XEM) but it has the importance score of the account for which you activated "remote harvesting". You can now send the private key of that empty account to a remote NIS to start harvesting, because there is no XEM to steal!
okay… so technically then it is a proxy private key secure remote harvesting feature. Now… to just figure out a simple term for "proxy private key secure remote harvesting". 
I'm thinking an acronym might be called for in this case.
Need to think about synonyms for those words arranged in different combinations until is spells something cool.
We have been working on a fairly long FAQ to cover the basics. It will be on the main nem.io website after it launches
I don't know why this hasn't made it into the client but "remote harvesting" - I think - was later actually supposed to be called "secure harvesting" which is a much better term.
Using that term also makes much more sense when you think about harvesting on your local NIS. Remote harvesting sounds pointles on your local NIS because it's local, not remote. Secure harvesting makes sense though. And yes there is a security benefit to it even if you're using your local NIS since your private-key won't reside in the memory of your local NIS. It's basically the same benefit security-wise that you'd have on a remote machine.
Remote-Harvesting --> Secure-Harvesting. Done 
i agree, secure harvesting i think is the best… and then you can use secure harvesting on a remote, or local Nis if you like. secure harvesting for security, remote Nis for convenience… its the Ncc and Nis i think that need new names…
I also like "secure harvesting" a lot more than "remote harvesting". But maybe there are even better ideas. Thats why I started this thread.
@pat: Having a private key in the memory should not be a security issue since the kernel won't let anybody access it. And if somebody got so much control about your machine that it can manipulate the kernel, you have other serious problems. But I also suggest to just always use "remote harvesting", because the only disadvantage I see in "remote harvesting" is that it takes 1440 blocks (24 hours) to get activated - but this is only once…
+1 for secure harvesting
lots of good points made for that term
I also like "secure harvesting" a lot more than "remote harvesting". But maybe there are even better ideas. Thats why I started this thread.
@pat: Having a private key in the memory should not be a security issue since the kernel won't let anybody access it. And if somebody got so much control about your machine that it can manipulate the kernel, you have other serious problems. But I also suggest to just always use "remote harvesting", because the only disadvantage I see in "remote harvesting" is that it takes 1440 blocks (24 hours) to get activated - but this is only once...
Anything that is in memory is to be considered at risk imho. It doesn't matter what should or should not be accessible. ALR is nice and all but nothing is 100% secure. Way too many crazy people out there that try the most absurd side-channel attacks.
If data in the memory wouldn't be safe, then all passwords wouldn't be safe. Because they all get loaded in the memory, always. But maybe we should discuss this outside this thread…
If data in the memory wouldn't be safe, then all passwords wouldn't be safe. Because they all get loaded in the memory, always. But maybe we should discuss this outside this thread...
Passwords that stay in memory aren't safe. Obviously everything depends on the attack vector.
If someone gains physical access to the machine where NIS is running I'd rather have secure harvesting activated.
If data in the memory wouldn't be safe, then all passwords wouldn't be safe. Because they all get loaded in the memory, always. But maybe we should discuss this outside this thread...
Passwords that stay in memory aren't safe. Obviously everything depends on the attack vector.
If someone gains physical access to the machine where NIS is running I'd rather have secure harvesting activated.
Read the best answer here: http://security.stackexchange.com/questions/29019/are-passwords-stored-in-memory-safe
If data in the memory wouldn't be safe, then all passwords wouldn't be safe. Because they all get loaded in the memory, always. But maybe we should discuss this outside this thread...
Passwords that stay in memory aren't safe. Obviously everything depends on the attack vector.
If someone gains physical access to the machine where NIS is running I'd rather have secure harvesting activated.
Read the best answer here: http://security.stackexchange.com/questions/29019/are-passwords-stored-in-memory-safe
Sounds like it confirms what I've been saying.
I don't think so. If your code is good (avoid buffer overflow attacks) and the user doesn't save the whole RAM to hard disc (hibernate), you should be good. But hibernate is not really a problem either, I think. Because good operating systems probably shut down all unneeded programs and services before writing RAM to hard disc and the other way around when getting the RAM content back to RAM from disc.
I don't think so. If your code is good (avoid buffer overflow attacks) and the user doesn't save the whole RAM to hard disc (hibernate), you should be good. But hibernate is not really a problem either, I think. Because good operating systems probably shut down all unneeded programs and services before writing RAM to hard disc and the other way around when getting the RAM content back to RAM from disc.
That's the point right there. You can never assume any code is good. And NEM is using Java. There have been a butload of security issues with Java in the last years. No matter how well NEM is written, if there is a whole in the JVM then that's for none.
I'm not saying anything in RAM is open for everyone to grab. I'm saying you can't assume it's safe under all circumstances.
ok, i agree to that.
SO… nothing better than "secure harvesting" yet…
Yes, I also think it should be the default.
When a user creates a new account, NCC should automatically create a second account and activate remote harvesting for the newly created address. That way people will learn pretty fast, that for newly created addresses they have to wait 24 hours to be able to harvest and that is no problem at all.
Edit: That's not possible, because the activation of remote harvesting is in fact a transaction with a fee, but a new account has no balance. And something that costs money should not happen automatically.
maybe someday remote harvesting will just be default. I just created a new account, loaded it up with XEM, and after the first confirmation was able to "activate remote harvesting". Since it takes 24 hours anyway before I could do regular harvesting, I am not really losing anything except for a transaction fee for activating secure harvesting.
I can see how some people might have lots of hot wallets that they won't harvest with and don't need to activate secure harvesting, so that could be a sticking point. But as far as I am concerned, for now on when I create an account, I'll go ahead and activate secure harvesting.
One thing that worries me about using the term "secure" harvesting is that it would imply that regular harvesting was somehow not secure, but that really isn't the case. Regular harvesting is secure and remote harvesting is very secure.
Another term might be "trustless harvesting" because once it is activated, you don't have to trust whether a machine has been compromised or not. Plus crypto people always like it when you use the term "trustless" and it implies something pretty epic, which actually remote harvesting is actually.
Calling it trustless harvesting would also imply that for regular harvesting you need to trust that your computer isn't compromised, which is in fact the case.