Scott T.

@Dave-in-Decatur I am happy to say that we enabled Opera support for the new web version on Friday.

@CalS Thanks for the additional info. I'm going to follow-up with the team on the whole "beta" thing. Also, the "classic" version is only available to those grandfathered into it. New users cannot get to it without a special link. Nobody has touched that code in quite a while. BTW, to my earlier comment regarding Firefox, I unfortunately misspoke. It's Opera support that we enabled last Friday. Firefox support is still pending the other changes we're working on with the editor.

@Dave-in-Decatur @CalS: To clarify my statement, the "current" web client would be the "beta" client (as you've referred to it), though I don't believe we label it as "beta" anymore. This is the focus of our engineering efforts. The "older" client is the one from @xfactoid and @CalS's left screenshot. FWIW, I only recently learned that the "classic" interface (@CalS's right screenshot) was still available to customers. That one predates my time at Evernote and I've only ever seen it in cases where we had a bug that led to it. I fully understand that the current web client is still lacking specific features such as stacks, but we are really working to get those into the latest version to have parity with the previous clients. In regards to timelines for the new architecture, I can only state that it's our primary focus at the moment. As our CEO has indicated, it's our main goal in 2019 to try to fix a lot of the core issues in the product that are impacting our customers. A big part of this is fixing the architecture to let us move forward with building the features our customers have long been asking for. Lastly, it's my understanding that support for Firefox in the latest client is imminent. I'm trying to follow-up on the date, as I thought it was actually supposed to go out last week. I'll post a status when I learn more.

@xfactoid To provide a bit of context on what I assume the issue is (based on my understanding of our code): Our existing editor mixes content with how it should be rendered. I've been told that a client basically renders our ENML files (how notes are stored) into a view. You edit in that view (i.e. a rich text editor). We then convert that view back to ENML and save it. This is a really bad design in the sense that if something is rendered differently between clients, you'll see breakage. Think of what happens if you go to Google translate and translate the same sentence back and forth between two languages. It always seems to change just a little bit every time, getting worse and worse. In the case of the bullet issue, the older client and editor is rendering the bullets and then saving them back to ENML in a way that is causing them to be broken on the Windows client when it goes to render the updated ENML. The re-architecture work we're doing includes separating the model (i.e. the content) from the view (how to render the content). To put it another way, the bullet list might be stored as follows: <bullet> <b1> "top-level bullet text" <b2> "sub-bullet text" <b1> "another top-level bullet text" </bullet> Then, a client would individually decide how it would render a top-level bullet vs. a 2nd level bullet. A different way to look at this would be for a binary choice, such as enabling/disabling a feature. The code might have: <choice> <On> <Off> </choice> iOS client might decide to render that as a pretty slider button. The Windows client might render it as a radio button. In general, I think we'd be consistent, but the point is that it offers the flexibility to do that while not changing the actual content. So the hope is when we're done with this work, we'll not only be able to address a lot of these problems that come from the issue with rendering, but we'll be much better suited to apply new features around how we render that content in a better way.

@xfactoid I was unable to reproduce this with our current web client. Only after I switched to the old client was I able to see the issue. Please try the Evernote web client located at https://www.evernote.com/client/web and let me know if you continue to experience the same problem. Our development teams are currently working on major changes to our architecture and clients, including the editor, to address issues with stability and quality. These changes will also enable us to deliver many features that have been requested for a long time. The priority is moving forward with the newer clients and architecture, and not fixing issues in older clients. I definitely understand your frustration, however, and I will see what I can do to push for a fix.

Spoke with the Security team. Since our whole technology stack is built on top of the Google Cloud Platform (and stored there), we automatically get encryption at rest by default. You can read more about it on the GCP site.

I will follow-up with our Security team about this.

This is a fair concern. We have tests for 2FA, but they use a testing helper function for getting the code. Effectively, the helper acts like the authenticator, generating the code from the seed. We don't have tests for the actual SMS sending. I'll follow-up with the team to find out if we can use one of the many services out there that let you setup a virtual phone number for receiving SMS texts.

Hi @John in Michigan USA. Our 2FA uses TOTP, which is an algorithm based on HMAC, and does not use any asymmetric algorithm with public/private keys. When a user sets up TOTP 2FA, they scan a code into their google authenticator app. This code is a “shared secret” that both the Evernote Service and the user’s gauth app keep a copy of. This secret is used to generate codes that can be transmitted to authenticate one party to the other. When you send a 2FA code to Evernote, the service uses its copy of the secret to generate a code, and compares your code to it to see if your code is valid. It’s very important that the secret stays safe, which is why it is never transmitted again after 2FA is set up. You can read more about TOTP on Wikipedia.

@EdH (and others on the thread): I looked into this and it turns out to be a small error on our side for the 2FA logic that was introduced while fixing other issues. Simply, we were evaluating a statement incorrectly that determines whether we send the code to the phone if authenticator is enabled. The logic was flipped, so it would always send the code in the case where a user has an auth app setup. We've got a fix already. It should hopefully go out in the next day or so, when we do our weekly scheduled maintenance.

@tedwlm I just tested this and did not encounter an issue with my cell phone. Is there something special about your phone number, such as being a Google Voice or other non-standard cell service?

@Beau Haan Spaces was intended to be an alternative to notebook stacks. Much like stacks grouped notebooks, Spaces group notebooks, but give additional features like auto-joining/sharing for members of the space. I don't think we currently intend to implement notebook stacks in Spaces, though anything is possible.

@Daniel Stimpson That's a IFTTT ticket number? If so, hopefully they can address this and reach out to us to work together to fix it. If that's an Evernote support ticket, not sure we can do anything without assistance from IFTTT staff. I was able to reproduce this issue myself. I will see if I can get a dev contact at IFTTT that can help us out.

@Balders Thanks for the ping about this. I apologize for not following up. Our developers looked into it and believe it to be an issue on IFTTT's side, likely with not handling specific image/file types or content we're sending back to them. We're not 100% sure, but that appears to be the case with our initial investigation. If you are able to reproduce this, you should reach out to IFTTT and report the issue. They should then be able to contact us to give us more specific technical details on which API is failing, what data they're sending, what data they're getting back, etc. We would then have a lot more information to work with. Separately, I'll see if I can reproduce the issue myself and reach out to IFTTT.

@cloud9tn The hackers are not using actual physical iPhones to access your account. Once they are able to log into your account using a compromised password, they can authorize another service to have access to your account via our public APIs. This is the same as authorizing a service like IFTTT to access your account. The "iPhone" is just the name of the service they're authorizing as. I think they are using iPhone because it's common and will obfuscate what they are doing, confuse users, or lead them to blame Evernote (which has been happening). The best thing you can do as a user is to follow good security practices, as noted in Rich's post above.

@douglerner The "Shared with Me" view is displaying all notes that were shared with you at any time in the past, regardless of the current state of the share. At the moment, it's a "view" and not a manageable list. We're in the process of fixing and redesigning sharing, and this view will likely be changed/improved. But the behavior above is the current behavior for the near future.

We have an open bug ticket for this issue. I just asked for an update on it.

@Kaylebor: My understanding from the devs was that note display worked pretty well in Firefox, but note editing had some issues. I did just verify the developers will be revisiting support across all browsers with the updated changes they are working on.

It seems your local DB might be in a bad state. Please try closing Evernote, going to the Command window or Run (Windows + R) and run the following command: Evernote.exe /NoLastState Then start Evernote again.

Much like many large websites, hackers are pretty much constantly testing out credentials in two ways: They're testing lists of emails/usernames to see if they are valid Evernote accounts. Presumably these are coming from previous leaks/hacks. If they determine it's a valid account, they test out passwords they have based on the leaked data. We have various tools in effect to help protect our users, such as limiting the amount of failed attempts allowed by a user, IP, etc. But, the hackers are smart and can work-around some of these, such as using botnets or limiting their throughput to stay underneath our limits. As has been mentioned, the number one thing users can do is change their password and not share passwords with any other account or reuse passwords that have been potentially leaked/compromised. A good website to visit is https://haveibeenpwned.com/. You can check if your email was part of any published leak data sets. I can pretty much guarantee if you have a yahoo.com account, information was leaked.

@Idahobob, I looked at your account. The recent iPhone devices that have shown up in your account (and you have revoked) are different device identifiers than your currently active iPhone client. This looks like the issue Rich identified in his post above. Please ensure your account is secured. I would advise changing your password and not sharing it with any other website login. You may also consider enabling 2FA for your account. Rich's post: https://discussion.evernote.com/topic/117015-2-devices/?do=findComment&amp;comment=525791

@ever_coffee: I can't say too much, but there's definitely hope for Linux users sooner than later. For Firefox, I can't say for sure, but based on my knowledge of changes we're making, it's quite possible we'll get better support for Firefox. Again, can't give any specific timeline. I can only point to Ian's recent blog post with regards to priorities.

Thanks @Grzamy. I'll send this over to our dev and support and see if they have some information on this that can help.

@Grzamy To clarify your comment, you're saying that the device in your list is definitely your own device and just a duplicate? You're saying it's not potentially an unauthorized device?

@DavidAmpleford The fix was on our server and should apply to all existing clients. No need to download an updated client. If you're still not seeing the thumbnails, please let us know what client and version you are using. Please note that @Garrett P mentioned it's possible that a client may have a cached placeholder thumbnail for up to a week.