Advanced Crypt on Autounlock when staking seems useless

[TheCharlatan]

The autounlock feature allows users to stake, even if they have a locked wallet. Autounlock unlocks the wallet with the password the user has chosen and then encrypts it again with a special password. This password is just the Hardware ID of the machine the wallet is running on. This seems useless, since the password's goal is to protect wallets that an adversary already has access to. If this would be a hot staking wallet, the adversary would have access to the machine in any case, and guessing a hardware id is not hard. Further, the macaddress is also used in this ID string, but only when QT_GUI is defined. This furthers obscurity and a difference in behaviour between daemon and gui wallet, that is not necessary.

[iFoggz]

I agree this is not the best thing. When I figured this out I just never did autounlock again.

[iFoggz]

also if someone did compromise the users machine they could technically just decrypt the wallet password right there and then take that with the wallet and run. i think itd be best to least mention caution on the use of this feature if it is to stay thou i'd support removal of it all together

[denravonska]

I vote for either removing it or adding a big warning both to the UI and to the password generation.

[iFoggz]

i agree to either. they must know the wallet passphrase can be decrypted easily if the said system was compromised.

[tomasbrod]

I Vote for removal.

[additude]

I didn't realize that auto unlock had been discussed for removal and ultimately removed until I installed the latest version on my headless Linux box a short time ago. So I am a late joiner of this discussion. I agree with other posters about the relevance of adding a warning notice for users who wish to use the feature but not removing it. It's one thing to protect the user from security faults, but it's quite yet another to protect the user from themselves. I don't feel that protecting me from myself is anyone else's responsibility except that of my own. When I am notified of the risk, then I can make a responsible decision. There are many, many things less secure than the Auto Unlock feature and besides there are other built in layers of security on top of the Wallet. In general, a users machine would practically have to be "targeted" specifically for their GRC Wallet to expose any Auto Unlock for Staking Only Security Threat. I realize there is risk, there is risk in everything, but it's also my choice of convenience that I make at my own risk and I am quite capable of managing my own risks just fine without others intervention. Please reinstate Auto Unlock and provide an adequate detailed warning for the output of the "encrypt" function.

[jamescowens]

We are not reinstating the functionality in its current form. It provides essentially NO additional protection as compared to leaving the wallet unlocked or unencrypted. Please see #546 to understand why. And to comment on leaving protection up to you... we already provide the option of running the wallet unencrypted. At least the user knows exactly what risks they are taking when they are doing that. In the case of auto-unlock, especially in the headless situation, the warning you mention would not be heeded, or in many cases even seen.

It is a bad idea to provide false security to users, even with a warning attached.

Sent from my iPhone

On Apr 12, 2019, at 4:49 AM, additude notifications@github.com wrote:

I didn't realize that auto unlock had been discussed for removal and ultimately removed until I installed the latest version on my headless Linux box a short time ago. So I am a late joiner of this discussion. I agree with other posters about the relevance of adding a warning notice for users who wish to use the feature but not removing it. It's one thing to protect the user from security faults, but it's quite yet another to protect the user from themselves. I don't feel that protecting me from myself is anyone else's responsibility except that of my own. When I am notified of the risk, then I can make a responsible decision. There are many, many things less secure than the Auto Unlock feature and besides there are other built in layers of security on top of the Wallet. In general, a users machine would practically have to be "targeted" specifically for their GRC Wallet to expose any Auto Unlock for Staking Only Security Threat. I realize there is risk, there is risk in everything, but it's also my choice of convenience that I make at my own risk and I am quite capable of managing my own risks just fine without others intervention. Please reinstate Auto Unlock and provide an adequate detailed warning for the output of the "encrypt" function.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[denravonska]

I would rather see us using the OS keyring for storing this type of data than rolling our own, easily breakable variant. If it's possible, that is. For now you can achieve auto unlock using RPC and scripts. I know it's not as easy as the previous version but it's close to as insecure and, in the end, does the same job.

[additude]

The user has the option to not even encrypt their wallet. Encrypting the wallet is not even mandatory and the "SECURITY" threat of just that single issue alone outweighs any security threat posed by the Auto Unlock 100 fold. A user can have an un-encrypted wallet..... but can't use Auto Unlock if they wish.... That just plain doesn't make any sense to me.

[additude]

"At least the user knows exactly what risks they are taking when they are doing that. In the case of auto-unlock, especially in the headless situation, the warning you mention would not be heeded, or in many cases even seen." At least in the case of comparing it to an unencrypted wallet it's some security. Not every hacker, per se, that can even get into a machine would know specifically how to and what to do to reverse Auto Unlock... They would have to have specific prior knowledge of the software function and that means more like their mission would have to be direct target and they would have to get past all the other security and maybe even chown.... Your saying that you want to take away the remote access to a car because a traditional metal key in hand is safer....then if that's not good enough, just leave your car unlocked everywhere you leave it... I say that's non-sense.

[jamescowens]

Look. I am not going to get into an argument with you on this. Anyone that has the resources to break into somebody's computer and mount an attack against the wallet itself will also have the resources to derive the hardware ID of the machine. Read the original write-up above carefully. What auto-unlock does is re-encrypt the wallet with the hardware ID as the passcode. This provides no additional protection over storing the passcode in a text file to be fed into an RPC command for unlock from the point of view of the attacker. It is one rather trivial additional step.

The core dev team is discussing alternative implementations of the auto-unlock feature on Slack. We would welcome a PR if you have ideas on how to implement a secure alternative.

[jamescowens]

@additude One idea that @denravonska and I talked about is to have your machine email you on reboot, which at least allows you to be notified of an unplanned shutdown...

[additude]

I wish I would have known of this intention previously. I just didn't know. I apologize if I am sounding arguementative. I don't mean to be, I'm just trying to make a point. My configuration finds Auto-Unlock not just a very useful feature but for me, necessary. My headless machine is remote, obviously and is overseen by "Watchdog" circuitry and Python code. It is able to reboot automatically based on ping and command processing, of which I'll then be notified, but what I don't need to do is get online, remote to the machine, log in, unlock...etc. For myself, I find that time consuming and completely unnecessary. I did read the above carefully. I'm not contesting the security issue, I fully understand that issue and that's my issue is that I want to make that choice for myself based on the knowledge of my system and the probabilities that I could or even would become a victim. I am aware that it happens. A "rather trivial additional step" is not in question..... but rather having a choice is. My alternative would then be to do what if I wanted Auto Unlock? I suppose I could try to create a separate script that would act as a "Personal" Auto Unlock for my wallet , or maybe I can modify source code to achieve my goal. Either way I am still exposed, either way it was my decision and equally within my right to do so. Email would be ok, but honestly... I'm trying to avoid the whole remote login procedure all together... The chances of a "Hacker" targeting a specific machine (me for example) for the intended purpose of accessing the GRC Wallet is in itself extremely, extremely rare. I personally have 51+ machines.... They are behind two stages of Router NAT's, behind Firewalls in both routers, IP isolated, Username and complex Password protected system. It would require a hack into each one of the machines searching on the "Hopes" that one of those machines had the or had a GRC Wallet on it. Instead, give the "gridcoinresearchd encrypt" a user input to a question such as, "Have you read about and do you understand the negative security consequences associated with using the Auto Unlock feature ?" Answer YES or NO User input needs to write "YES", default is "No" No = Terminate Encrypt YES = "Enter Password" User enters Password and hits the enter key.... Output is the current output of "Specify in config file.....encryption" I'm having problems locating Slack. Is it Gridcoin Slack? I found some links but they are not working for me... Thanks.

[jamescowens]

Hmm. If you are using that much automation and your machine is that secure, then you can simply set up a script to call the daemon to unlock the wallet using a passcode stored in a file with chmod 600. Are you saying you just don’t want to go to the effort of scripting it out?

On a remote machine, I would be running the wallet in a limited authority sandbox account anyway.

Sent from my iPhone

On Apr 12, 2019, at 10:20 AM, additude notifications@github.com wrote:

I wish I would have known of this intention previously. I just didn't know. I apologize if I am sounding arguementative. I don't mean to be, I'm just trying to make a point. My configuration finds Auto-Unlock not just a very useful feature but for me, necessary. My headless machine is remote, obviously and is overseen by "Watchdog" circuitry and Python code. It is able to reboot automatically based on ping and command processing, of which I'll then be notified, but what I don't need to do is get online, remote to the machine, log in, unlock...etc. For myself, I find that time consuming and completely unnecessary. I did read the above carefully. I'm not contesting the security issue, I fully understand that issue and that's my issue is that I want to make that choice for myself based on the knowledge of my system and the probabilities that I could or even would become a victim. I am aware that it happens. A "rather trivial additional step" is not in question..... but rather having a choice is. My alternative would then be to do what if I wanted Auto Unlock? I suppose I could try to create a separate script that would act as a "Personal" Auto Unlock for my wallet , or maybe I can modify source code to achieve my goal. Either way I am still exposed, either way it was my decision and equally within my right to do so. Email would be ok, but honestly... I'm trying to avoid the whole remote login procedure all together... The chances of a "Hacker" targeting a specific machine (me for example) for the intended purpose of accessing the GRC Wallet is in itself extremely, extremely rare. I personally have 51+ machines.... They are behind two stages of Router NAT's, behind Firewalls in both routers, IP isolated, Username and complex Password protected system. It would require a hack into each one of the machines searching on the "Hopes" that one of those machines had the or had a GRC Wallet on it. Instead, give the "gridcoinresearchd encrypt" a user input to a question such as, "Have you read about and do you understand the negative security consequences associated with using the Auto Unlock feature ?" Answer YES or NO User input needs to write "YES", default is "No" No = Terminate Encrypt YES = "Enter Password" User enters Password and hits the enter key.... Output is the current output of "Specify in config file.....encryption" I'm having problems locating Slack. Is it Gridcoin Slack? I found some links but they are not working for me... Thanks.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[additude]

Well @jamescowens I'm just saying that I already have a do-dad system, albeit, "work in progress" that operates as designed.....and... first and foremost, Thank you for this conversation. I know that you are a very well respected individual in the world of GRC and I honestly and I truly appreciate your time with me discussing this subject. Believe me James, I am not here for not.... as a double negative.... I come with respect. Part of that design implementation is based on the availability of an Auto-Unlock-ish feature.... or a such like Auto-Unlock recovery dispatch routine that I can base a personal belief and faith in as a full recovery effort and restore to system operations without human intervention. I like systems that operate as I designed and they notify me when they fail to meet defined criteria. That doesn't mean I power 'em up and ignore them. They are monitored 24/7 by human (me) "look-see" because MAG counts, RAC...... well not so much... I totally respect that you are a much more knowledgeable individual of Gridcoin and it's workings than myself. You, probably more than I will ever be. I think I'm a year and a half old into Gridcoin... my first ever and only Crypto. So, I'm still just turning dirt in the garden..... But all of my mechanical and electrical and computer-ness...... is commissary of decades before.... I mean, those decades ago when then understanding that a software "feature" was an absolute difference than what was a software "function". But, I think today, not so much... Feature, Function, eh... who knows?? You said; "then you can simply set up a script to call the daemon to unlock the wallet using a passcode stored in a file with chmod 600. Are you saying you just don’t want to go to the effort of scripting it out?" @jamescowens I truly and I honestly wish that you would not spelled this out explicitly as such. Your advertisement to the internet has just reinforced the vulnerability to all of those that use this feature. Exposing it to even the simplest of computer enthusiasts. Do you realize that "Not Having Knowledge or Understanding" is equally yet another form of a security layer? But lets just move on here..... I honestly wanted to redact this piece and send personal and private at this time, but it's opened up, lets just take it for what it is now at this time and move on..... You present me this and then I am compelled to ask sir, "How does my scripting it out stop or prevent your conundrum of the "attacking intruder concept" that you refer to being an ultimate security risk? And, Secondly, I ask, why should I have to do that, create an auxiliary script to perform the same function as the Auto-Unlock feature in previous versions? Is it because you personally feel that it is the "best" thing for me? or is it for some other meandering reason that awareness rejects? What if sir, I generate such script as you speak and I offer such script as such to open source to anyone who cares to acquisition it to their own personal repository of software utilities ? It's based on your idea...... That sir, I believe is honestly a much larger breach of GRC Wallet software security than what I have been am advocating for. And the problem here and now is, now that it's been a can of worms opened in this forum.... it's even more of a security risk than it was before.... So with that in mind, I will private you with this portion to preserve the architectural security of the code and make some other skirled searches for answers to their criminalist ways. Then, what have you contained? Nothing more than a "YES - NO" question and diss-allowing knowledgeable, even if they are not "knowledgeable" to your standards, the rights with full knowledge to make a "Knowledgeable" decision for themselves and who they feel they are? You express to them, obviously myself included, with this action and to those like myself, that you must be more knowledgeable than I. I put it forth as such sir, because that option represents a positive perception. My second option is that of a negative perception, which I will refrain. I am not an enemy Mr. @jamescowens, we share the same concerns of security, I am an adversary to achieving the best, most efficient and the ultimate common sense practical solutions to all and any problems that present themselves to us. I want to look for an answer beyond "Shutting the lights off" because they draw mosquitos mentality. I know I can't get rid of "ALL" of the mosquitos.... I know that.... But I know that if I just keep the lights on inside the house, the security of the doors closed, that the mosquitos wont get in.... To me, that's an exercise in practicality..... So just to make it clear.... the analogy of the mosquitos .... that was a reference to hackers and intruders......just to substantiate the knowledgeability of things...... I'm still waiting for reference to the SLACK group..... Thanks, when you can....

[jamescowens]

I am not trying to upset you. I just am having trouble understanding your position in this matter...

We have a public announcement as to the vulnerability of auto-unlock. This has been well known for some time. And yes I WANT everyone to be aware of this. This issue dates back a long time, and quite frankly we should have taken action on it quite a while ago.

Also the command

gridcoinresearchd

Is well known as a way to script out unlocking the wallet. The issue of course is that the must be in the clear, although it can be parameterized and fed in from a different file. This provides about the same level of security as auto-unlock.

You can create a script for the daemon startup that first starts the daemon, tests for it to respond to rpc calls, and then calls the walletpassphrase function.

Simply suggesting there are very easy alternatives with equivalent security.

Jim

Sent from my iPhone

On Apr 12, 2019, at 1:58 PM, additude notifications@github.com wrote:

Well @jamescowens I'm just saying that I already have a do-dad system, albeit, "work in progress" that operates as designed.....and... first and foremost, Thank you for this conversation. I know that you are a very well respected individual in the world of GRC and I honestly and I truly appreciate your time with me discussing this subject. Believe me James, I am not here for not.... as a double negative.... I come with respect. Part of that design implementation is based on the availability of an Auto-Unlock-ish feature.... or a such like Auto-Unlock recovery dispatch routine that I can base a personal belief and faith in as a full recovery effort and restore to system operations without human intervention. I like systems that operate as I designed and they notify me when they fail to meet defined criteria. That doesn't mean I power 'em up and ignore them. They are monitored 24/7 by human (me) "look-see" because MAG counts, RAC...... well not so much... I totally respect that you are a much more knowledgeable individual of Gridcoin and it's workings than myself. You, probably more than I will ever be. I think I'm a year and a half old into Gridcoin... my first ever and only Crypto. So, I'm still just turning dirt in the garden..... But all of my mechanical and electrical and computer-ness...... is commissary of decades before.... I mean, those decades ago when then understanding that a software "feature" was an absolute difference than what was a software "function". But, I think today, not so much... Feature, Function, eh... who knows?? You said; "then you can simply set up a script to call the daemon to unlock the wallet using a passcode stored in a file with chmod 600. Are you saying you just don’t want to go to the effort of scripting it out?" @jamescowens I truly and I honestly wish that you would not spelled this out explicitly as such. Your advertisement to the internet has just reinforced the vulnerability to all of those that use this feature. Exposing it to even the simplest of computer enthusiasts. Do you realize that "Not Having Knowledge or Understanding" is equally yet another form of a security layer? But lets just move on here..... I honestly wanted to redact this piece and send personal and private at this time, but it's opened up, lets just take it for what it is now at this time and move on..... You present me this and then I am compelled to ask sir, "How does my scripting it out stop or prevent your conundrum of the "attacking intruder concept" that you refer to being an ultimate security risk? And, Secondly, I ask, why should I have to do that, create an auxiliary script to perform the same function as the Auto-Unlock feature in previous versions? Is it because you personally feel that it is the "best" thing for me? or is it for some other meandering reason that awareness rejects? What if sir, I generate such script as you speak and I offer such script as such to open source to anyone who cares to acquisition it to their own personal repository of software utilities ? It's based on your idea...... That sir, I believe is honestly a much larger breach of GRC Wallet software security than what I have been am advocating for. And the problem here and now is, now that it's been a can of worms opened in this forum.... it's even more of a security risk than it was before.... So with that in mind, I will private you with this portion to preserve the architectural security of the code and make some other skirled searches for answers to their criminalist ways. Then, what have you contained? Nothing more than a "YES - NO" question and diss-allowing knowledgeable, even if they are not "knowledgeable" to your standards, the rights with full knowledge to make a "Knowledgeable" decision for themselves and who they feel they are? You express to them, obviously myself included, with this action and to those like myself, that you must be more knowledgeable than I. I put it forth as such sir, because that option represents a positive perception. My second option is that of a negative perception, which I will refrain. I am not an enemy Mr. @jamescowens, we share the same concerns of security, I am an adversary to achieving the best, most efficient and the ultimate common sense practical solutions to all and any problems that present themselves to us. I want to look for an answer beyond "Shutting the lights off" because they draw mosquitos mentality. I know I can't get rid of "ALL" of the mosquitos.... I know that.... But I know that if I just keep the lights on inside the house, the security of the doors closed, that the mosquitos wont get in.... To me, that's an exercise in practicality..... So just to make it clear.... the analogy of the mosquitos .... that was a reference to hackers and intruders......just to substantiate the knowledgeability of things...... I'm still waiting for reference to the SLACK group..... Thanks, when you can....

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jamescowens]

Also slack invite...

https://join.slack.com/t/teamgridcoin/shared_invite/enQtMjk2NTI4MzAwMzg0LTUzMmY0YjdiNzYxYzQ0MDc3MGE1NjQ3Nzg2NWMzZTUzMjAwZjdhMWI1YWUzMDE4YzQyZjVjMjMzOTc1M2RmMmM/

Sent from my iPhone

On Apr 12, 2019, at 1:58 PM, additude notifications@github.com wrote:

Well @jamescowens I'm just saying that I already have a do-dad system, albeit, "work in progress" that operates as designed.....and... first and foremost, Thank you for this conversation. I know that you are a very well respected individual in the world of GRC and I honestly and I truly appreciate your time with me discussing this subject. Believe me James, I am not here for not.... as a double negative.... I come with respect. Part of that design implementation is based on the availability of an Auto-Unlock-ish feature.... or a such like Auto-Unlock recovery dispatch routine that I can base a personal belief and faith in as a full recovery effort and restore to system operations without human intervention. I like systems that operate as I designed and they notify me when they fail to meet defined criteria. That doesn't mean I power 'em up and ignore them. They are monitored 24/7 by human (me) "look-see" because MAG counts, RAC...... well not so much... I totally respect that you are a much more knowledgeable individual of Gridcoin and it's workings than myself. You, probably more than I will ever be. I think I'm a year and a half old into Gridcoin... my first ever and only Crypto. So, I'm still just turning dirt in the garden..... But all of my mechanical and electrical and computer-ness...... is commissary of decades before.... I mean, those decades ago when then understanding that a software "feature" was an absolute difference than what was a software "function". But, I think today, not so much... Feature, Function, eh... who knows?? You said; "then you can simply set up a script to call the daemon to unlock the wallet using a passcode stored in a file with chmod 600. Are you saying you just don’t want to go to the effort of scripting it out?" @jamescowens I truly and I honestly wish that you would not spelled this out explicitly as such. Your advertisement to the internet has just reinforced the vulnerability to all of those that use this feature. Exposing it to even the simplest of computer enthusiasts. Do you realize that "Not Having Knowledge or Understanding" is equally yet another form of a security layer? But lets just move on here..... I honestly wanted to redact this piece and send personal and private at this time, but it's opened up, lets just take it for what it is now at this time and move on..... You present me this and then I am compelled to ask sir, "How does my scripting it out stop or prevent your conundrum of the "attacking intruder concept" that you refer to being an ultimate security risk? And, Secondly, I ask, why should I have to do that, create an auxiliary script to perform the same function as the Auto-Unlock feature in previous versions? Is it because you personally feel that it is the "best" thing for me? or is it for some other meandering reason that awareness rejects? What if sir, I generate such script as you speak and I offer such script as such to open source to anyone who cares to acquisition it to their own personal repository of software utilities ? It's based on your idea...... That sir, I believe is honestly a much larger breach of GRC Wallet software security than what I have been am advocating for. And the problem here and now is, now that it's been a can of worms opened in this forum.... it's even more of a security risk than it was before.... So with that in mind, I will private you with this portion to preserve the architectural security of the code and make some other skirled searches for answers to their criminalist ways. Then, what have you contained? Nothing more than a "YES - NO" question and diss-allowing knowledgeable, even if they are not "knowledgeable" to your standards, the rights with full knowledge to make a "Knowledgeable" decision for themselves and who they feel they are? You express to them, obviously myself included, with this action and to those like myself, that you must be more knowledgeable than I. I put it forth as such sir, because that option represents a positive perception. My second option is that of a negative perception, which I will refrain. I am not an enemy Mr. @jamescowens, we share the same concerns of security, I am an adversary to achieving the best, most efficient and the ultimate common sense practical solutions to all and any problems that present themselves to us. I want to look for an answer beyond "Shutting the lights off" because they draw mosquitos mentality. I know I can't get rid of "ALL" of the mosquitos.... I know that.... But I know that if I just keep the lights on inside the house, the security of the doors closed, that the mosquitos wont get in.... To me, that's an exercise in practicality..... So just to make it clear.... the analogy of the mosquitos .... that was a reference to hackers and intruders......just to substantiate the knowledgeability of things...... I'm still waiting for reference to the SLACK group..... Thanks, when you can....

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[additude]

Sorry I have been away for a while and have not had an opportunity to respond. "We have a public announcement as to the vulnerability of auto-unlock." I have been involved in Gridcoin for maybe a year or less. So I am still unraveling the ropes of this thing and as much as I would like to spend more of my time at learning more about GRC, the wallet operations, etc. I have other commitments as well so I can't spend as much time at it as I would like to. So what may be "Well Known" is completely relative to those who have prior history with it. I am not a formal programmer by profession. I know what I have learned thru books and courses I have taken and what I have taught myself over the years. When you say, "Simply suggesting there are very easy alternatives with equivalent security." Then I feel compelled to question that if the Auto-Unlock feature is being removed for it's security vulnerability and there is an "easy alternative with equivalent security", then doesn't that alternative as it exists provide an equivalent vulnerability the same as Auto-Unlock.... at least with Auto-Unlock, the passcode isn't potentially "In The Clear"..... which I honestly feel would be true security vulnerability. Thanks for the invite...

[jamescowens]

I don't know how to explain this any other way. Auto-unlock and an in the clear password stored in a script file provide about the same level of security. The problem is that auto-unlock provides the ILLUSION of some security where there is none. At least requiring someone to script out the unlocking using their password makes it plainly obvious to them what the risks are. You may be aware of the risks of auto unlock. I can guarantee you that there are 900 others that are blissfully unaware of the vulnerability of auto-unlock. I can also guarantee you that people do not read and head warnings. This feature will not return until we can find a way to do it in a secure manner.

Thanks.

[philipswift]

Not the right place? let me know :) Wallet locking, encryptions, timeouts, mnemonic from the get go, auto modes

Maybe look at what the industry standard is; James is of course correct with KISS. Swap (XWP) wallet shoves a password field in your way straight off the bat. One can change the timeout of the autolock of the wallet. This just locks the wallet and does not encrypt it of course

Wallet is not connected for syncing on access but has auto-start daemon syncing logging cli has 'help' or 'status' stated proactively help Wallets versions are exportable as read-only and 'spendable'

Massive mnemonic is needed when starting up the wallet in addition to the wallet password.

GUI can close with daemon still running (no dirty shutdowns?). Swap icon is not present in taskbar. swapd.exe is manageable in Windows Task Manager (by CPU load) User can set where the big files (blockchain) reside (not on C:) to stop smaller capacity and pricy SSD and M.2 getting clogged up

Also helpdesk calls are minimised as there is a caveat stating 'users themselves are responsible for maintaining their password and backup phrase/mnemonic'. Period. KISS

Article from 10 months ago: https://medium.com/atomic-wallet/atomic-wallet-protection-54741fc1bcb3

[jamescowens]

These are good ideas. To implement a lot of this, we need to split the front end and back end into a loosely coupled architecture. This is part of the GUI rewrite bounty.