Scott T.

Hi @GTKZ. Thanks for the additional info. I'll follow-up with the team tomorrow when I'm back in the office. If you are able to, can you open the network tab of the dev tools and make sure the web client has fully loaded (network activity stopped). Then clear the network tab out and try editing the note. Then send a screenshot of that. It will help to see if one of the calls is maybe timing out. We'll be looking for something like "utility" or "notestore". Those will be the updates/syncs. If you do the same thing on the old client, the calls should also be "notestore".

Hoping this will help us figure out what is going on. Also, let me know if you are running any specific Chrome extensions. We sometimes see issues with them interfering with our calls. I think we're generally OK with most of the popular ad blockers since I know some devs use them. But, would be good to know just in case. Though, you indicated you saw something similar on Edge, which would lead me to look elsewhere, like network issues or firewalls. LMK if you have anything like that.

@GTKZ, can you provide details on the exact error you are receiving? Please provide the exact text, if possible. Also, if you are familiar with Chrome dev tools, you could open up the Javascript console and see if there are any errors there. 

Also, you might consider trying the latest web client again. That's the version that we are actively supporting. If you encounter issues in the older web client, we will be less likely to address the issue if not urgent. Though, if there's an issue saving notes, that would definitely be fixed. 

1 hour ago, xfactoid said:

When I go to the latest client link I am dropped in to the "previous web client", regardless of platform. As far as I can recall, I have never opted into or out of the beta/latest client. Is this intended behavior? If the "beta" client is no longer considered "beta", should it not be the default? 

I believe the preferred client is controlled by a preference setting. It shouldn't exist if you have never visited the newer client. The second link in my post above included a parameter that might have set that. I included it on purpose to force the old client to load. Depending on which you visited, that may have set the pref.

Regardless, you can switch between the two clients by opening the profile menu. That's the menu that opens when you click on your profile picture. There's an option to switch to the newer or older client. That should set the preference setting accordingly.

As I noted to @CalS, I think we're aware of the confusion between the versions. We're trying to fix that. 

1 hour ago, CalS said:

Good to know, easy to see how we get so confused.  As you no doubt know, this latest client (Beta) does not support stacks and does not replicate all shortcuts (surely not function to be deprecated), and is a couple of orders of magnitude slower than the Current client.  Maybe that's why it is still called Beta.   

Not picking on you @Scott T., you are definitely part of the solution.  Just in my view, some clear communication from EN would be helpful re the web versioning strategy.  And the logic behind deploying a beta version sans all the intended functionality, to the public in any case.  Can't follow the logic on that one.

My understanding is that stacks is coming very soon to the latest client. For shortcuts, I'm pretty sure I've filed a ticket for the missing functionality and some of it was intended. Can you provide details on what specific shortcuts are missing so that I can make sure to raise those as an issue?

Total transparency: I'm not convinced we (at least in the past) had a clear versioning strategy. This is something we're working to fix now. In fact, I got an update on my inquiry about calling the latest client "beta", and they actually want to leave that until we've met feature parity with existing clients.

@CalS Just to follow-up and clarify.

This is the latest client and the one we are actively developing on. It is not a "beta" client, though it seems we still reference that in at least one place (PersonalSettings.action). I filed a ticket to address this and hopefully we'll remove all references to beta:

This is the previous web client that has existed for quite some time. New development has ceased. We're fixing major bugs if we get a report, but efforts are all focused on the client above. There are features in this client that don't yet exist in the latest client, but we intend to support those soon or clearly indicate they're deprecated (hopefully in favor of other features which replace the functionality):

As noted, the classic client is REALLY old and only those accounts that are old enough to have actually used it are able to access it via a setting that grandfathered them into having a link to it.

@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.

4 hours ago, eric99 said:

Thanks for the info. I hope the shared secret is  encrypted at rest in your databases ...

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

3 hours ago, John in Michigan USA said:

I am still concerned that audited code apparently made it into production with a logic error, even though that logic error itself presents only a minor security problem (codes leaking without user's knowledge).

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. 

1 hour ago, John in Michigan USA said:

Furthermore, sending out the G Auth code gives up one of the strongest features of Google Auth, a thing that separates it from simple, SMS-based 2FA: only the user can generate codes! Letting the server generate codes is the equivalent of storing the user's password in the clear in the user database...you should always store a salted hash of it, or otherwise prevent server admins from being able to easily discover user passwords for themselves.

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:

1. They're testing lists of emails/usernames to see if they are valid Evernote accounts. Presumably these are coming from previous leaks/hacks.
2. 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.