Leaderboard

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.

For example: Enpass is minimized to tray and I need to login to Spotify. First, I click on the enpass icon and the popup window opens. Then I open the spotify entry, copy my username and paste it in the spotify login field. The problem is, if I want to copy my password now, I have to search for the Spotify entry again, because the window closes when I click into an other program. It would be nice, if the current state of the window will be saved. Thx!

Hi all, I'd like to request that the sorting algorithms be improved in a few ways. Not sure if part of the behaviour I'm seeing is due to a bug or a setting, but I have a few observations: On the macOS desktop app, the very first item in my "All Items" list is (ironically) "1Password". However the very first item in my "All Items" list on the iOS app is "Add This". For some reason, the macOS desktop app shows items starting with numbers at the top, but those same items show at the bottom in the iOS mobile app. Not sure if this is a bug or not, but this leads me to want to request the ability to customize the sorting of whether numbered items are at the top or bottom. I couldn't find an existing setting for that. Right now, the behaviour is definitely not in sync across the apps. In the browser extension and applications, the sorting when searching for an item seems to be only alphanumeric rather than sorted intelligently based on whether the keyword was found in the title or just part of a field, etc. Likely in the vast majority of cases, users would want to see items with their keyword in the title before items with their keyword in a field name or field value. In my particular use-case which prompted me to want to request this enhancement, I search for "Facebook" in Enpass. Since I have a good deal of items in my list with a note saying "Logged in with Facebook" to indicate that I use my Facebook credentials for the service, I get many items alphabetically listed upon my search for "Facebook" which means I need to scroll down a ways to get the one I was looking for which is the one where "Facebook" was in the actual title of the item. So in that use-case, it'd be great to see "Facebook" at the top of the search results when "Facebook" is in the actual name of the item, and then list the remaining "Facebook"-related items afterwards where it was found in just a field name / value or a notes section, for example. Does that make sense? I might be having a hard time explaining this one, so please ping me if you need any clarification on this one. Another example is searching for "Mail" where I expect to see my mail account credentials come up first, but instead it lists nearly everything I have because "Mail" is part of the "Email" field in nearly all my items in the Enpass app. Ultimately I'm just looking for more intelligent sorting in search results rather than simple alphanumeric. It'd be good to see the title weighted heavier in the search results, for example, than the items which have that same keyword just in a note or as part of a field name. The ability to sort based on title, based on "last used", based on "last edited", "last added", etc. would all be useful to have in the application and browser extension. Just some food for thought on sorting. Number 2 above might be more around searching than sorting, but wanted to add it as I feel it still very much relates to sorting as it has to do with the sorting of results after doing a search for something. I can create a new feature request post though if you feel it has more to do with searching than sorting. Just let me know. Thanks again for making such an awesome app. -- Dustin

When there are a lot of passwords saved for a particular domain, it can be quite difficult to scroll through the list in the Chrome Extension to find the one or two that you use most often (and have been made favourite). Please please please could you show favourite passwords first in the list? You could show they are favourites by overlaying the star icon over the top. I have attached a quick mock-up of how it could look. As you can see I have 14 passwords for this particular domain.

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.

Hi, can we have an option like on Linux (and presumably Windows) to start the app with the system but only minimized on macOS aswell? It's rather annoying when my OS comes up and the first thing it does is opening an Enpass window that takes up the whole screen. Seeing that you have implemented this on other systems I think it would be doable on macOS aswell. Thanks in advance!

Actually, on desktops, Enpass shouldn't even start minimized, because it shouldn't have a Window at all. 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. I added a dedicated thread for this here: