zllllo

You two bring up a good point regarding the relevance/intended use of the encrypted portions of text within EN. My primary use case is to encrypt lower-level, less significant things, like temporary codes, serial/license numbers, gift card codes and the like where I want some level of privacy but want the convenience of access from cross platforms (Mac, Win, iOS, Android). That is the whole raison-d'etre of EN and why I still use EN as a tool, to have a simple cross-platform digital brain. My logins to sites get stored into a password manager which is highly secure, offline, and not cross-platform. Important docs in the form of pdfs or other formats I use their native encryption. These are all important things to use to secure yourself holistically, but the convenience and utility of encryption in EN is still highly valued, and especially since many have used this feature for years prior to the release of the new architecture six months ago.

Indeed, this is outrageous, and it's March! Also, there used to be another forum discussion from earlier, but that one seems to have been combined with the current discussion by someone? https://discussion.evernote.com/forums/topic/132677-encrypted-text-unable-to-edit-formatting-issues/

Thanks. I voiced my discontent with customer service the other day and learned that "At this time, this is by design to prevent users to accidentally deleting the encrypted texts causing for a data loss." Additionally, they stated that they received a lot of reports from users who accidentally deleted their texts. Personally, I've never had this problem, and have been using this native feature for many years in my workflow. To me, this is a bug as it has been a feature that has been around for years, and if I did enough searching and digging into the past, maybe even highlighted in release notes or other documentation before. It's a brilliant feature that was native and convenient. The new design is very clunky at best and vulnerable security-wise at worst (why do I need to decrypt the text permanently, have the decrypted text potentially synchronized, then create a new encrypted block ... or try to beat the race condition by cutting and pasting ... many more steps that are prone to error, when the edit in-place was just seamless, simple and worked). Were users just accidentally placing the cursor behind the encrypted block and backspacing to accidentally delete? And if they did that, did they not learn to distinguish the encrypted block from the regular text? I also learned that their bug database is internal-only, so we have no visibility into their release roadmap or priorities. I see your workaround @agsteele and may try that out sometime. My own workaround for now is to restore the prior version of EN and keep ignoring all the App Store prompts about updating to the new version of EN (which is an annoyance, but a necessary burden). I use a good handful of Macs and one Windows machine, so for me, it is easier to stick as long as I can to the last version of EN, or I would need to set up the external decryption workaround on all my platforms.

Wondering if anyone knew the bug number on this problem?

Is there an official bug # for this issue? Same problem on Macs.