Jump to content

Scott T.

Evernote Staff
  • Content Count

    232
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Scott T.

  1. Hi all. I'm following up to confirm that we pushed a fix out for this issue on 03/27. Please let me know if you continue to encounter any issues with revoking a device.
  2. Hi all. I'm following up to confirm that we pushed a fix out for this on 03/27. Please let me know if you continue to encounter any issues with revoking a device. @EdH I agree wholeheartedly. However, we have complications with how we do deployments that getting out hot fixes is not easy and also disruptive itself. So it's a balancing act when deciding whether to disrupt our users for a brief period of time to make the fix. As part of our rearchitecture efforts, we will be making changes which should allow us to deploy individual changes faster and independent of other changes.
  3. Hi all. I'm following up to confirm that we pushed a fix out for this on 03/27. Please let me know if you continue to encounter any issues with revoking a device.
  4. Hi all. I'm following up to confirm that we pushed a fix out for this on 03/27. Please let me know if you continue to encounter any issues with revoking a device.
  5. Hi all. I'm following up to confirm that we pushed a fix out for this on 03/27. Please let me know if you continue to encounter any issues with revoking a device.
  6. Hi all. I'm following up to confirm that we pushed a fix out for this on 03/27. Please let me know if you continue to encounter any issues with revoking a device.
  7. Thanks @GTKZ. The only interesting thing in the screenshots is the last error in the first one. Other errors are ad blocker and I think the first is an expected warning. I'll double-check this with the dev team and get back to you when I have an answer.
  8. 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.
  9. @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.
  10. 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.
  11. 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.
  12. @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.
  13. @jFog I am happy to say that we enabled Opera support for the new web version on Friday.
  14. @Dave-in-Decatur I am happy to say that we enabled Opera support for the new web version on Friday.
  15. @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.
  16. @mdezrin Though I'm not actually in customer support, I believe the discussion forums are currently intended to be the way in which free users can seek help for issues they are having, or to provide feedback to the Evernote team. I personally wish there were better ways, but I think it comes down to costs. Providing personalized customer support is expensive and due to the sheer size of our free user base, I believe it is cost-prohibitive at this moment. This approach is pretty standard across a lot of internet companies with very large, free customer bases. I've been doing my best to try to get other employees engaged in the discussion boards. Several of our customer support members monitor the boards and respond or triage issues as necessary. But, I think it's invaluable for our non-customer support members to be engaged as well. The posts on here are a great insight into the issues and frustrations that our customers have. I've been able to quickly help address several issues people have run into that would have otherwise been overlooked. I hope this information is helpful. Please continue to provide feedback and I'll do my best to help surface this information to our development teams, specifically the Android team for any beta issues you encounter.
  17. @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.
  18. @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.
  19. @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.
  20. 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.
  21. 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.
  22. Hi @Mirtma65. I addressed the first issue in another thread: For the second issue, we require 2FA every time you log in. If you didn't log out of the client, it wouldn't be prompting you. This is definitely intended behavior. However, if you believe that we should offer a feature like "Trust this device and don't prompt for 2FA again", I can put that in as a feature request. Please let me know if that's what you desire.
  23. 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.
  24. The development team is aware of this issue and actively investigating the problem. I apologize for the current inconvenience. We hope to have a fix for our weekly maintenance, which is currently scheduled for tomorrow evening.
×
×
  • Create New...