Jump to content
Enpass Discussion Forum

Unsay

Members
  • Posts

    26
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Unsay

  1. A similar error has already been reported (here), but this is a defferent problem. Tested on Android 8.0. After selecting OneDrive from the "Sync With" drop down menu, Enpass briefly shows an "Authenticating" pop-up, Firefox is automatically opened and directed the the Microsoft website, and then Enpass shows this error message: The sync with OneDrive was canceled by the user. I can only click "OK". The "Sync With" drop down is reverted to "None". This worked fine in 5.x FYI: My device is rooted and the default browser is Firefox. Chrome is not installed on my device.
  2. On Linux, Enpass configuration information is saved to: /home/<user>/Documents/Enpass This is very "Windowsy". In keeping with the spirit of Linux, it should be saved to: /home/<user>/.enpass
  3. This is the problem! You should be working smarter, not necessarily harder ;-) Place all editions of Enpass for Windows on a single code base, with a swappable UI (QT, UWP, or a headless version without a UI which is what would be used 95% of the time when Enpass acts as the back-end for a browser extension)! If you did that you could: release non-UI features for all editions of Enpass for Windows simultaneously, including FF57 support. Require only two editions of Enpass (legacy QT edition for Windows 7/8.x/ and Enpass Portable and an UWP edition for Windows 10), making it much easier for customers to understand and get the correct version for their environment. Enpass could start up much faster as the headless version wouldn't have to load all the QT bloat. Eliminate the feature gaps between editions, the sole exception being UWP related features. This would be far easier to understand than the seemingly arbitrary differences Enpass editions currently exhibit. Reduce or eliminate the delay between releases of different editions of Enpass for Windows. Remaining delays would only impact UI specific changes.
  4. Yes, I completely agree. I've been complaining about the root cause of this problem too, for over a year now. Every version of Enpass for Windows suffers from it, e.g. the portable version also isn't compatible with FF57, so people who need the combination of portability and FF57 are out of luck too. Need FF57 and Edge... out of luck. Need Windows Hello and any browser plugin at all... out of luck. All of these editions of Enpass for Windows should theoretically be generated from a single, consolidated and shared code base. That would ensure that all non-UI features (like browser plugins, or Windows Hello) would become available for all versions of Enpass for Windows simultaneously. Most of the Enpass for Windows code base should be shared across editions, only swapping out the UI layer for alternative implementations where necessary (like the UWP version). The fact that they aren't doing this is the root cause of this mess, which the Enpass team understands but isn't willing to correct (I'm guessing due to the effort required). This is definitely worthy of being complained about. My previous post was intended to reduce the number of posts in regard to things where the information is available, but people were confused regardless.
  5. All of the questions asked in this thread, and much of the confusion, could be avoided if people would just read! Anyone saying "Help! I'm using the current/latest version of Enpass on Windows and the Firefox 57 plugin doesn't work" needs to stop and inform themselves first! There are multiple editions of Enpass on Windows, all of which have different version numbers. All of them are the current/latest version of Enpass, for their edition. Only one edition is compatible with Firefox 57. Three of them work with Firefox 56 and earlier. Only one of them works with Edge. Frankly, I think the Enpass team is having some difficulty communicating on this topic, but here is the break-down: * The 'Traditional Win32' edition is the only edition that works with Firefox >= 57. ** The 'Windows UWP' edition is the only edition that supports Windows Hello and Cortana. IMHO the table above is what should be on the Enpass download page, under a single heading for Windows. Considering the ludicrous mess they have there now, the confusion isn't surprising. Anyway, according to this blog post: the Windows 10 - Desktop (a.k.a Bridged) edition is what the Enpass team will be focusing on going forward. It will eventually become compatible with Firefox 57 and include all the features that are currently unique to the 'Windows UWP' edition. The 'Traditional Win32' edition won't get that much attention, but it will stick around for people with older versions of Windows. I've not seen anybody mention anything about the portable version, which at this point looks like it has been abandoned. Here are the download links for the various versions of Enpass for Windows: Traditional Win32 (5.6.0) Portable (5.5.6) Windows 10 - Desktop [a.k.a bridged version] (latest version) Windows UWP (latest version)
  6. @bunnyhero @tojtojka As Gajender mentioned in the OP, you must have: "the latest Enpass v5.6 for Windows, Linux or Mac (Website version)". The version you are using is v5.6.2 (Microsoft Store version). That will not work. There are currently four different versions of Enpass for Windows: 1. Win32 version for Windows 7/8/8.1/10 [Website] 2. Win32 version for Windows 7/8/8.1/10 PORTABLE [Website] 3. Win32 version for Windows 10 [Store] (the only version that supports the MS Edge WebExtension) 4. UWP version for Windows 10 [Store] (the only version that supports UWP features like Windows Hello) [Website] = downloadable from the Enpass website [Store] = downloadable via the Microsoft Store Of these, only #1 works with the WebExtension for Firefox 57.x My hope is that one day all the distinct Win32 versions become a single version (even the UWP version should be based on the same core application, and "merely" swap out the QT based UI for a UWP based one). Unfortunately, I'm somewhat disillusioned at this point. Cleaning this up should be a major focus for Enpass. Doing so would provide many benefits beyond alleviating this confusion, but but for some reason it just isn't a priority for them.
  7. Hi @Anshu kumar It's frustrating because it's so entirely unnecessary. It just makes absolutely no sense for both "standard" and "portable" versions of Enpass to exist. The "standard" version for Windows PC reached 5.6. weeks ago. There is no reason that shouldn't automatically yield the "portable" version for Windows PC as well (or visa versa). For Windows, the state of the WebExtension for Firefox on other platforms is simply irrelevant. For each platform, both the "standard" and "portable" versions really should be one and a same, with the only difference being a slightly different configuration made by the "standard" version's installer.. In our software shop we use Firefox developer (not beta or pre-release) version, which was automatically updated to v57 last week. Everyone using Enpass is now forced to switch browsers (and recreate all their browser configurations which for some of us is time consuming). I saw this situation coming from miles away. I've mentioned this problem on your forums multiple times already, the first time over a year ago. It baffles the mind that you guys can't give something like this higher priority. Like most of Enpass' design and architectural shortcomings, you seem to ignore it, despite there being no technical reason both "standard" and "portable" versions can't be in sync. In any development shop where efficiency mattered they would be. You needn't even be very technical to notice something is off. Looking at your website's list of supported platforms is enough: Windows, Windows PC, Linux, OSX, Blackberry, iPhone/iPad, Portable... which one of those is NOT actually a platform? I hope you guys can finally get around to fixing this architectural flaw. That would be at least as important as bringing the portable version up to v5.6.
  8. Seriously, what are you guys thinking? For any well designed piece of software, there is no reason to separate the standard from the portable version. There is no reason for these two distributions to not be the exact same thing. *sigh* Everyone else can do it, why can't you? People using the portable version also use Firefox... now at version 57... which is incompatible. This has been fixed in the standard version 5.6, but the portable version continues to frustratingly lag behind. It remains incompatible. Any chance you'll get around to updating the portable version from 5..5.4 to 5.6? Better yet, get rid of the standard version entirely and allow the portable version to be configured in a way that mimics the so very slight differences to the standard version? It's about time that happened.
  9. Woot! Just tried out Portable 5.5.5 and this has finally been fixed. Thank you! Now we just need to find out why keeping the non-portable version makes sense (hint: it doesn't): ;-)
  10. I just tried out the portable version again. It still uses the nag-dialog which unnecessarily asks us to specify the path to the wallet file every time it is launched. :-( If the most recently used relative path from enpass.exe to the wallet file is still valid, why not skip the nag-dialog entirely and just provide a way to explicitly open it if required? Why not consolidate on using just the portable version and getting rid of the non-portable version entirely?
  11. Or, rather than going only half way, solve the problem entirely. Just update Enpass in the background automatically without requiring any user interaction whatsoever. Allow users to disable automatic updates in the settings, which would prompt users to update, but don't make that the default.
  12. Well, in any case, thanks for the update. Much appreciated Vinod ! I'm glad you're considering your software's startup impact. Thank you. However, I think it's safe to assume that your software architecture is borked if you have UI dependencies in the lowest/core levels of the application. I suspect that's likely due to events that must be received and handled in the UI layer. If so, then you shouldn't be using QT for that, but rather your own event aggregator (see the Prism framework for a C# code example or any other observer or publisher/subscriber pattern). That would be useful on every platform, including those that don't use QT (I'm assuming your mobile apps don't use QT and that you use the same OS independent core on every platform). The core would then communicate only with the cross platform event aggregator. That eliminates QT dependencies from the core. In desktop applications, the event aggregator would then propagate those events to the subscribed QT based event handlers. In mobile applications the aggregator would propagate those events to each mobile OSes native event subscribers. Particularly for a company that builds a single application for so many platforms, it seems like a no-brainer that you'd be very interested in keeping UI dependencies out of the core. Just something to consider... Good luck!
  13. Hey @Vinod Kumar It's been four months, so I'm popping in to check up on this. Do you have any more information on that major refactor you said you had planned for this year, and whether or not, as part of that endeavor, you will split Enpass into a small, efficient, headless (without any dependency on QT) background task and a front-end application? I've noticed the rate of updates being applied to the Windows desktop application has slowed (which I'm almost thankful for), and thought a larger refactoring task may be the cause *hopeful* ;-)
  14. ^ rather than just hiding the Window, it would be better to just not have it exist at all. Even if it is hidden, we'd still be paying for its existence in terms of an additional 10MB of memory being wasted and it slowing down boot times.
  15. Another benefit of having only the portable version, would be that you could dump the installer (less maintenance, fewer things that can go wrong).
  16. Hey My1. Thanks! As I typically do, I had attempted to manually add Enpass to the Windows startup sequence, in which case the full UI is opened (ugly). Thanks to you I've since noticed the "Autorun on system startup" option. When that is checked, at least on my PC, a small Enpass Window briefly flashes on screen during startup and then disappears quietly (for once) into the tray (still ugly). Yes, that's workable, but it remains unpolished. Still, whatever is included in the startup sequence should be small, lightweight and fast! That's why Windows attempts to measure the "Startup impact" for every application that participates in the startup sequence (see the Task Manager). For some reason that impact isn't measured for Enpass. However, my own measurements show that it's slow as molasses. I'm guessing that's down to Qt, which is a great technology choice for a cross platform UI. However, it is also fat and heavy and therefore has absolutely no business being loaded into memory as part of what should be a small and light background process. It also has no business just sitting around 90% of the time, doing absolutely nothing but wasting my memory. It could be argued that a single application like Enpass going rogue during the startup sequence is tolerable, but if every application behaved this way we'd soon be back to waiting minutes for our computers to boot, for no other reason than those applications not having been designed properly. An application like Enpass is destined to be included in the startup sequence. It's "startup impact" should be measured and it should be as small as possible. Right now neither is the case. Lastly, whether I add that background process to the Windows startup sequence manually, or allow Enpass to do so itself via settings, the result should be the same. That it acts differently is unintuitive/funky behavior. So, I no longer have to deal with the full Enpass window being opened on boot (although the small flashing window isn't exactly pretty). The other aesthetical issues I mentioned remain. More importantly, startup performance is still abysmal and memory usage unjustified. Therefore I'd still very much look forward to Enpass implementing this suggestion. I know I'm being tough here. I admit that these issues aren't deal breakers. However, it's things like this that make the difference between software that is just good and software that is great. I really want Enpass to be great! ;-)
  17. @Anshu kumar Hey Anshu, any ETA on this? Do you folks agree that there is no need for the normal desktop version if the portable version behaves as discussed above?
  18. I just also wanted to chime in and say I love the portable version of Enpass, and throw my support behind the same request everyone else here is voicing: By default use a standard path to the wallet that is relative to enpass.exe, and if the wallet file exists, don't show the configuration dialog at all. If you do this, the portable version of Enpass is the only version anybody needs. The normal non-portable desktop version might as well be retired.
  19. I'd like to know what you, Jespreet, expects the benefits of this to be. A lot of people misunderstand "open source" to mean free, which is of course wrong. Open source software can be free, but it doesn't have to be. One isn't related to the other. More importantly, asking people to give away their hard work for nothing is a bit brash. On the other hand, open sourcing Enpass can make a lot of sense if the idea is to allow anyone who has the technical skills to audit the software, thereby giving Enpass' security related claims a "community approved" stamp. Besides actually making Enpass more secure, this can also be used as a marketing instrument. I'd vote for this request if the idea is about community auditing, and strictly against it if it's the first (I want the people behind my security solutions to be well funded). Can't say where I stand if the idea is something else. Anyway, I think the post should describe what the idea behind it is. Just asking for "open source" isn't really enough IMHO.
  20. Any other feedback on this idea? What do you other users think? Anybody from Enpass want to take a public position?
  21. Of the few icons you suggested Dylan, I'd find two useful, yet I have a whole host of other icons I'd also find useful. Ultimately, no matter how many icons the developers add, there will always be some that are missing. At least for websites, this is not the right approach. It can't ever work well for everyone. Websites already have their own icons that enpass could access and reuse however. They are called favicons, and they are displayed in front of the URL in pretty much every browser's address bar. That's what enpass should be using. It's a mystery to me that they aren't already using that. Enpass should really do the following: for websites, enpass should always automatically use the favicon as the default. enpass should include one or two generic icons for each template type, but otherwise provide primarily icons for things that aren't websites (credit cards, bank accounts, etc). instead of trying to provide all the icons which anybody could ever want (and which will never work), allow users to add their own icons. This would solve the problem once and for all. It also wouldn't require the developers to invest more time in making ever more icons that will never meet everyone's needs. IMHO that is just investing more time into a dead-end solution.
  22. Enpass on desktops should be split into two separate programs: EnpassCore.exe: This executable file constitutes the core Enpass service that browser plugins communicate with. It should have no window-based-UI whatsoever. This is also what users (and/or the installer) would add to the boot sequence. On boot, adding an icon to the tray (on Windows) or the menu bar (on OSX) would be the only clue it is running. EnpassUI.exe: This executable file constitutes the windowed UI. If EnpassCore isn't running, launching the EnpassUI would automatically launch EnpassCore as well. From any browser plugin, EnpassUI should never be more than a single click away. Benefits: EnpassCore has no windowed UI, so we could launch it as part of the boot sequence without having to deal with the annoying Enpass window being opened on every boot. A UI window should be in in one of the following states: opened, minimized, maximized, or closed. Since EnpassCore is always represented in the tray and EnpassUI is independent of that, there would be absolutely no need for the additional and unusual "minimized but in the tray" state Enpass currently employs. By separating what should be purely a background process from the front-end UI, we can eliminate the need for the quirky "minimize to tray" option and also say goodbye to the bothersome "Click here to restore Enpass" message that is shown every time Enpass is minimized to the tray on Windows 10. In a nutshell, how and when we require the UI for data lookup or data entry should have no affect on whether or not the Enpass service is running in the background. Because EnpassCore has no windowed UI, it could be very "lean and mean", thereby not noticeably impacting boot performance (assuming it's implemented as a native C/C++ application). For those people who are used to (or like) the way Enpass works now, there is no difference. Users can still add EnpassUI to the boot sequence and have the Enpass Window opened on boot if that is their preference. Technical thoughts: Architecturally, browser plugins and the EnpassUI would just be different clients of the same EnpassCore application. In the interest of a shared code base and developer productivity, EnpassCore would ideally be implemented as a C/C++ program that can be compiled on any of the platforms Enpass supports. I chose the filenames EnpassCore.exe and EnpassUI.exe only as a way to more clearly communicate their purpose. Nothing more. The filenames are not part of this suggestion. It would probably be best if EnpassUI is named enpass.exe, so that launching enpass.exe would open the windowed UI as it always has. In this way, people who don't know about, care, or want this change wouldn't be impacted by it at all.
×
×
  • Create New...