Jump to content


Level 1
  • Posts

  • Joined

  • Last visited

About ElliesDad

ElliesDad's Achievements



  1. No, you can reuse the same password for mltiple notes. However, EN's encrypted document support remains primative in design, and the web client implementation does not allow editing (I believe is due to multiple bugs which haven't been fixed in classic web UI (I haven't tried the new web Ui recently, because it it is so unusable for me. I posted about that in a different post. I am hoping EN will provide a stable CRUD UI to enable 3rd parties to develop replacement UIs....
  2. Here's a vote AGAINST the new web-interface, for the following reasons: too much whitespace -- gutters/margins/leading/fonts are all far too big. The designers need to give up their gorgeous 4K monitors and use a 1024x768 (certainly nothing higher-res than 1366x768) monitor like the rest of us. Screen real-estate is precious -- please don't waste it! the bland monochromatic UI is too hard on the eyes (same reason I dislike Windows 10). Think chili peppers not yogurt, guys and gals! Too many "verbs" are hidden -- I can't figure out how to do stuff -- you have no hover-help, a very anemic menu-bar, no context menus -- please, please do NOT re-invent well-designed, time-tested, familiar UI usage patterns. I want the UI to work the way I expect it to, I want it to leverage what I already know, not have to discover how it works, not have to learn something new. I want EN to be a hammer, a *****-driver, a can of nails which I can get stuff done with, not a painting I have to study! funky font-sizing (not sure what's going on...sometimes I get the font I want (nice small 8-pointer), sometimes I get this monstrous large 16 point. (Its probably just a bug.) On Firefox on Windows (at least) the text-insertion-point cursor (vertical bar) is not vertically aligned properly following a check-box -- it seems to be vertically aligned on the subscript position. Can't high-light text. Can't figure out to make the note-list compact with small font. I want to see the titles of 40+ notes listed vertically to the left of the note view-edit panel. I'm lucky if I get 15! I want obvious grab handles for dragging column widths, not an expand/contract button way over on the opposite side of the column! I want UI changes to snap, not a slow glide. I would like "*" <space> and "1" <space> to automatically enter corresponding list mode. You have several iconbars all over the screen some vertical, some horizontal with humongous icons. This is a waste. You only need one, it goes at the top, each icon should be 2-3 ems wide and high (not 4-5). You need to let me pick what icons go on it, and let me put them in the order I want, with- and with-out text-labels (since the metaphors behind the icons you choose may be unrecognizable/ambiguous to me.) I realize EN has spent a lot of effort re-inventing the new Web-UI -- that's a shame, because I haven't found any improvements, and I know that 2 UIs is too expensive to maintain, and I know that the managers in charge aren't going to be willing to abandon the new UI and go back to something they spent a lot of money replacing. Therefore, please consider the points above, and make changes to the new UI, to "finish" adding the goodness in the old UI which you "haven't yet" implemented in the new UI.
  3. Strong encryption at the notebook level (eg, all note content, and all note metadata (eg title, tags, creation date, change history) with no escrowing of keys, and the ability to perform rich-text-editing of the contents of an encrypted note (which includes encryption of attachments to the note) on any device, is a requirement before I will pay for Evernote. I'll use the free basic account lightly until then, but I won't go "all in" with Evernote until this is implemented. As a software developer who has implemented all the parts of encrypted note store functionality which I envision, I assure you there is no rocket-science to doing this, these days. You want one or more seasoned developers to do it, but it is certainly do-able. To do it properly (given the current feature sets), EN will need to implement both server-side crypto (for EN Web and EN APIs), and client-side-only crypto (for tin-foil hats like me who are annoyed at the fact that GCHQ and NSA have staff and/or data-feeds and/or secret letters which enable them to access anything stored in the major cloud services, and are concerned about APT threats to corporate data -- such as what has recently been disclosed about Russia's and WikiLeak's actions in the US elections. To do it properly, sync-ing and change history and search indexing should be enhanced to work properly with ciphertext (post-encryption) as well as plain-text (unencrypted) content. Encryption does not mean you can't have searchability -- EN would need to index the unencrypted text, then encrypt the resulting search indices with the appropriate encryption key. Then, in order to search, the search engine would need to decrypt the indices which it can using the password(s) which the user has provided, in order to include those indexed values in the search process. This might not scale to be able search millions of users' databases in a single query -- which is actually quite desirable from my perspective -- but it should scale quite comfortably for 1 to 1000 users/passwords over 1 to 1000 notebooks. Modern mid-to-high-end cell phones have enough RAM and enough CPU to provide searching of client-side-encrypted notebooks (eg, keys never supplied to servers); I can't speak for others, but for me, only indexing of note metadata and note text would be good enough (eg, no client-side searching of attachments such as PDFs). Finally, client-side encryption does not mean you can't share encrypted documents on the server, or do server-side merging of encrypted changes from multiple people. To support these features you'd need to use public key-encryption, and it does mean you'd need to canonicalize the pasted-in HTML which you store or create, since the unit of merging and change history recording would need to match the unit of encryption -- which I suggest would be a complete HTML tag and its nested children, for simplicity. If I were designing the feature set, I would make the recording in the change history of who initiated certain changes and when they were done, a configurable feature at the notebook level, to provide a degree of plausible deniability. You would need to record change sequence, but you should allow updates to be persisted anonymously. Implementing server-side key-escrow/storage for those users who want it (eg, corporations) is not a big deal either. For those who don't want it, it should be possible to prove by inspection, that the encryption key is not hidden in any files which are synced to the server, and is never sent to the servers using an API, unless a user initiates such a transfer explicitly, and is never stored on disk locally. You should allow a user to use different keys for different documents (and even different sections of a single document) within an encrypted notebook. In summary, I believe the problems which need to be solved are well understood, are tractable, and do not involve any compromise of the current feature set. So EN, please just do it! PS: I encourage you to crowd-source a detailed technical requirements spec, and the priority of various features, in order to ensure you don't miss critical security details, and that you implement features in the correct order to avoid serious gotchas along the way. If you go this way, I would be interested in participating.
  • Create New...