Concerns About 1P 8 for Mac from a Web and Software Developer
Comments
-
Less flippantly, I'm all for a ground up re-write, but this feels clunky. I'm not even necessarily judging it on the underlying tech here, just the end result. This feels like an Apple like "re-imagine" (that's also clunky) like when Apple went from iMovie 6 -> 7 or Final Cut Pro 7 -> X. Key features ppl relied on were missing for years until Apple restored them to the new design. I really hope that AgileBits continue to support v7 for a few years, as I won't be upgrading to this version any time soon.
We are still early in the 1Password 8 lifecycle and we will work through the issues. The rewrite was quite painful to be honest but we felt that we had to do this. It was really difficult to support multiple codebases especially when we have rapid development on 1Password.com server side that requires the client apps to keep up.
1Password 7 is being supported. We just published a new beta build this week.
Features-missing-wise, I miss being able to have a local vault as my primary vault, with a single memorable password used only for local 1Password unlock, and then have my multiple cloud vaults all added to the setup each with a SUPER complex password that I can't even remember! By adding them after my non-synced local vault it means I can have a super secure cloud passwords while maintaining a memorable one for my local devices (which are only accessible after I decrypt my FileVault and log into my Mac... etc.).
I see where you are coming from but the "single password" was a big kluge. We had many users confused why they can unlock their account on 1Password.com but not the app. Also, a lot of issues with changing passwords and with removing accounts in the app.
I would argue that it is better to use the same single memorable password for all accounts. The Secret Key provides the additional protection and there is really no need to use generated passwords.
Also, pressing Option no longer seems to reveal passwords when 1Password 8 is foremost app.
The problem with "hold Option key to reveal passwords" is that it was too easy to do that accidentally. For example, you might press ⌥⇧C or something like that. We really wanted to make 1Password 8 more "shoulder-surf" ("screenshare-surf"?) friendly and it would be bad if you could reveal your passwords by accident.
I'd love to find a better way to do this.
0 -
@roustem: I don’t generally have a problem with the choice of Electron, but I believe that it’s important to understand that your customers have in part chosen to use 1Password because it is a “Mac-assed Mac app”. I’ve been with you guys since version 1 and you were posting on the Switcher’s Blog, because I switched about the same time. You and I have probably met at TACOW meeting a few years back (I know I’ve met Dave). I also have family that I’ve put on my 1Password Family account (as soon as it was available and through several updates) because it makes so much sense, and they’re on everything except Linux.
Mac and iOS users tend to be more finicky, but in the end, everyone wants a program that works like what they know every other program is supposed to work like on their platform. It’s one of the reason that Swing failed so badly. Electron apps, without a lot of work, tend to work like Electron apps. Which is to say that they work like badly implemented Windows or Linux applications and it just shows up even worse on the Mac because nothing on the Mac works like that. Most people hate on Slack’s app because it’s lazy and is clearly very little different than a wrapped webpage. (I hate on Slack because they really don’t understand their customers’s needs and the Slack app reflects that perfectly.)
I believe that it is possible to make a Mac-assed Mac app with Electron, but it’s going to have to be something that you commit to. You can get almost all the way there by looking for things that make 1Password feel like a webpage, Slack, or even VSCode (which is the least Electron-feeling app that I use) and explicitly doing things differently on the Mac.
These to me, would include:
- Ensure there’s nothing glaringly obvious like the
⌘-Alt-Cas found by @jaysee_au. - Stop making the main window work like a webpage. This has multiple parts, but for me it still comes back to the zoom controls. In Mac apps,
⌘-and⌘+don’t change the size of the chrome , but instead change the size of the content. When things that look like chrome resize, it breaks your expectations. Music doesn’t work that way. Safari doesn’t work that way. The size of chrome is controlled by system settings. Some Mac-assed Mac apps do have a sort of “spacing” setting so that you can have a “compact” view, but zoom should only affect content. On most Mac apps, there’s no such thing as a modal. Preferences, etc. pop up as separate windows so that you can change them, possibly see interactive changes to how the preferences affect the main window, etc. They don’t get in the way of your use of the application. (Preferences sometimes have modal sheets that pop up. See Safari and what happens when you look at all cookies in the privacy tab.) Sometimes preferences are control sheets instead. I have found four “modals” so far that active get in the way of using 1Password:
- preferences
- add a new device
- sign in to a new account
- manage collections
None of these should be blocking to the use of 1Password, and as such should either be separate draggable windows (most Mac-like), sheets (second most Mac-like), or tabs (least Mac like, but at least non-blocking).
Fix the biometry prompts so that they come up immediately on display launch without launching the full application, when required.
- Make sure that almost all actions that can be done can also be done through the menu and that the important ones have keyboard shortcuts (Lock — which I believe used to be
⌘⌥Ldoes not have a shortcut and it’s hidden in a menu in the vault/collection list—the what?); the menus are really empty compared to previous versions of 1Password. - Don’t have menus that aren’t obviously menus. I’m speaking of the menu items below the list of accounts / collections:
Make sure that everything that should be chrome is properly recognized as such by Accessibility mechanisms. Make sure that it handles all of the settings at least as well as the native versions did. I can’t give as much guidance on this, as I do not currently require accessibility adjustments, but your comment on liking the zoom controls points me to this, as there are ways built into MacOS to improve overall accessibility without relying on Stupid Web View Tricks. This is one of the biggest points of being a Mac-assed Mac App, and something that 1Password has done very well in the past that I do not believe Electron apps do very well…if at all.
Allow manual reorganization of the main grouping mechanisms. This isn’t as much about being Mac-assed, but it represents a fairly big structural change for me. My work account (starts with K) is sorted before my personal account (starts with z). This does not represent my interpretation of what’s important. In fact, I should be able to designate a collection as the first thing (the so-called “all accounts” view). With 1Password 7, I could unselect a number of vaults and ensure that results for them never showed up in Mini or searches unless I was in that vault. I have vaults to which I have access on my family account that I do not want showing up for results unless I select them (my parents’ vault; my wife’s vault). BTW, the last few years of 1Password 7 have taught me that
⌘0is the “filtered all vaults” view, not “reset zoom level to default (too large)”.
As I said, I get why you’re moving to Electron. I don’t even think it’s necessarily a bad idea. But 1Password, as a multi-year recipient of Apple Design Awards, has a much higher bar to pass than the lazy management at Slack. There are a lot of people who will look at the fact that, as it stands, 1Password 8 doesn’t feel like a Mac app and decide that, as long as they are having to use something that feels like it doesn’t fit, why not go with something that doesn’t have the premium cost that 1Password has? At the moment, I’m not in that camp. But I could see myself moving that way when it comes time for 1Password 9. Right now, you have a great reputation as advocates for the Mac and deep security that also works on other platforms (not necessarily in that order). This isn’t something to spend cheaply.
0 - Ensure there’s nothing glaringly obvious like the
-
The problem with "hold Option key to reveal passwords" is that it was too easy to do that accidentally
Indeed: happened to me when pair programming on my machine... :(
0 -
I would argue that moving to Electron IS inherently bad because it naturally tends towards terrible user experience.
And stuff like this:
How a company that purports to value security would want to take on this kind of reputation is utterly beyond me.
0 -
What exactly is worrying you, @gussic ? I see that fear all over the forums and Reddit and I understand some of it but I don't get the fear of web-based technologies (which we are using in 1Password 8 only to render the UI
I think the worry is that even a good Electron App (there's an oxymoron for you) never works as well as a good App built using Apple's native frameworks. Sure a good Electron App might be better than a poorly written native App, but that's about it. Even good Electron Apps are still bad at their core - they make computers run hot, and as we've seen with 1P8 they are significant resource hogs.
With all due respect, using Electron is just lazy development. You're trying to simplify you efforts, which from a business perspective I totally get, to make it a consistent front end. That's great for you and your team, but incredibly poor for the end user.
Many of the Apple's own apps are built with web technologies. There are many Mac apps but how many of them are truly great? The list is quite short and we can probably count them on one hand: OmniGroup, Panic, Fantastical.
I agree the list is short, but you guys used to be in that list. Electron is like a turd, you can polish it as much as you like but at the end of the day it still is crap - and I don't mean that in a nasty way, but its just a fact. It's not web technologies that scare people (although this trend towards it is annoying) its Electron that scares people.
Just making an app "native" will not make it great and it is also possible to build a great user experience with web technologies.
I accept the first part of your statement - the second part I'd say that's the exception rather than the rule, but I would say that the moment you put Electron as your framework of choice for the front end you've basically ruled out having a great user experience on the Mac.
A prime example of why people are worried is the extension as well. We've gone from having a lightweight extension that used barely any memory to one that uses more memory than 1Password 7 did, with all of its attendant processes/helpers. Sure you can optimise it - but can you honestly say you'll get the extension back down to 20 mb of memory usage? No you won't be able to.
What is a user to do? You're stripping away functionality, you will eventually be forcing the use of programs that are significantly more memory than their predecessors, and still charging the same subscription fee. Add to this your comments on reddit where you sarcastically tell a user to go and use iCloud Keychain ... can you really blame users for being upset about the change? It's been incredibly poorly managed by your team.
Why not come out when you were at the fork in the road and ask users what they wanted - laid out the benefits of both and asked? I bet you a lot of people would have preferred 1P8 for Mac had a delayed shipping date if it meant you could get SwiftUI working on it.
0 -
Even with a badly-written native app, one would still have proper window behavior, text/font rendering, pasteboard, integration with system-wide keyboard shortcuts, integration with system-wide accessibility features, etc. With an Electron-based app, each of those things is a bunch of extra design, engineering, and QA work, and then each also represents different spot for an app to fall into the uncanny valley of usability.
0 -
This is going to sound snarky.... but have you considered making it a preference if you've decided it shouldn't be the default anymore? 🤷♂️🤔 Just removing a feature that ppl have been using for years seems a bit brutal.
I'd love to find a better way to do this.
I'm also glad to hear this:
1Password 7 is being supported. We just published a new beta build this week.
As I said, I'm not inherently against Electron development, and I like the sound of a single, solid core underneath + lightweight UI. I am concerned at how unpolished this release is though. Did the reaction to Electron catch you all off guard? (It seems reminiscent of Apple's surprise at the 2016 Touch Bar launch when everyone was like "WTF? That is not what we're asking for."). If I were going to pivot my long time Apple first, native Mac app to Electron I'd be keen to get it more native-looking first given the reputation Electron has.
Again, not saying it can't be a good solution. Just saying it doesn't feel like that yet. Glad to hear 1P7 will continue to get updates. Hopefully the Safari extension will also continue to get updates. That was the thing that broke 1P6 for me in the end, and to be completely honest I'd probably still be using it if the Safari extension was still available! What can I say, I'm not a big fan of redesigning workflows and interfaces just 'because'. 🤷♂️
0 -
Microsoft has got nothing on 1Password. We're clearly passionate about the changes here, but this is a silly comparison, like comparing 1Password and iCloud keychain.
Truth is, Microsoft has had a cloud-synced integrated password manager since Windows 8, when you started to be able to sign into Windows with a Microsoft Account. It ONLY works with Windows itself or Edge. Windows Store apps can integrate themselves into the manager as well, but those are very few and far between. Microsoft has started surfacing this password manager more by making it visible in the Microsoft Authenticator app, but there's no Mac or web version (yet).
1Password stores more than just simple passwords. It's also a OTP generator for example. You can assign multiple websites to a single entry for site recognition, something both Microsoft and Apple can't currently do. 1Password can store passports, driver's licences, and a whole bunch of other things that, sure, you COULD stick into a OneNote notebook, but it's nowhere near secure. This isn't a primary business for these companies, I doubt they will Sherlock 1Password's supported platform list of functionality any time soon.
Look, I joined this forum to bang the Electron drum.
PS, I don't know why people keep harping on "enterprise is driving these changes". Maybe that revenue is, but oh boy does the enterprise hate change more than all of you combined. Do you still need to encounter Windows XP in your day to day job? No? Well, I have clients who do.
0 -
The problem with "hold Option key to reveal passwords" is that it was too easy to do that accidentally.
Is it really? Can't say I've ever done it, and even if I had, pressing macOS modifier keys is a brief split second action in general. Anyone "shoulder-surfing" would have to have superhuman photographic recall to read and memorise a long complex password in a second or less.
Have you done any research into how often customers are actively using 1Password whilst screen-sharing or with someone looking over their shoulder? And then out of those people, how many regularly 'accidentally' press the Option key long enough for someone to accurately read and memorise the password? I can't imagine the number is very high. And what about lone users, who never screen-share or have anyone looking over their shoulder? Why can't they be trusted to enable this option and use the feature. Why should you dictate what is best for everyone, based on some dubious belief that a significant enough number of users are 'accidentally' revealing their passwords?
What about people who might accidentally leave their computer unlocked and 1Password open when going to get a coffee in their office? It only takes a couple of seconds to export a file of ALL vault data... Surely this is a much bigger risk than a brief glimpse at a single long password on-screen. The export function doesn't even ask the user to confirm their master password before handing over all the data!!!
0 -
The export function doesn't even ask the user to confirm their master password before handing over all the data!!!
That sounds like an actual great security-related feature request.
Personally I've never used, nor accidentally triggered, the option-clicking function.
0 -
My experience with Electron is not at all positive. High resource usage. Non-native behaviour (e.g. Cmd-Tab to Teams... won't find it's window). Microsoft is abandoning it and expects Teams 2.0 to use 50% of the resources. This feels like Flash 2.0. As an organization grows, I expect to see greater and more specific commitment to native platforms, not going lazy to create a one-size-fits-all client.
Anyhow, I've been with 1P since the very early days and have touted the product to many. I'll wait until 8 to pass judgement, but moving will be a no-brainer if this is a disappointment.
0 -
XIII commented just above that they have had the issue with '⌥ to reveal' accidentally revealing sensitive information. This is a problem we're looking at, but I don't think it is as easy as simply re-doing what we had in 1Password 7. We need to look at how we can offer this functionality without the downsides.
Regarding requiring a password to export... it appears our security team has already weighed in on that, and we will be requiring that in the future.
The security engineering team decided that we should be requiring a password prompt for users to confirm the export action.
It looks like it is just design and UI implementation work to be done for that to happen.
Ben
ref: dev/core/core#8989
0 -
This is a problem we're looking at, but I don't think it is as easy as simply re-doing what we had in 1Password 7.
Why not? Have it turned off by default if necessary and a preference for users who understand the risk to turn it on if they want. You could also limit the amount of time the password is revealed for on a press and make that user configurable.
Not everyone uses 1Password in a situation that can be easily shoulder-surfed or screen-shared, so why deny those users a very useful feature if they want it? Again this seems to be dumbing the product down for the corporate market.
0 -
Why not?
We're going in circles here, I'm afraid.
We definitely want to find a solution here that will allow users to quickly and easily reveal their passwords without the level of risk the behavior in v7 exposes.
Ben
0 -
In the meantime Apple released iCloud 12.5 for Windows: https://forums.macrumors.com/threads/apple-releases-icloud-12-5-for-windows-with-icloud-keychain-password-manager-app.2307743/
It includes a keychain password manager. This should really settle it. There is no reason (for most people) to invest in sth like 1Password.0 -
Chiming in here. First, electron as a UI is a been-there-done-that-and-dumped-it pattern. Java and Flash are the two predecessors, and the issue is that don't get a mac app or a windows app. You get a flash app, or java app or electron app. They don't look and feel like native apps and the more you try and work around the framework, the more exposure you have to bugs. Sure, it's easier for developers, and looks good to the bean counters because it is initially cheaper, but in the long run the UX is always substandard compared to native code. Full Stop. Over the long term that costs more money because as customers leave, you end up rewriting to a native app anyway.
Security issues? Yes, absolutely as both Java and Flash clearly demonstrate. Electron should be somewhat better because of 20 years of advancement in coding practices and language development, but the risk is non-zero. Now any third party library has those issues, but native API's are one less abstraction layer to worry about, and Electron has a much larger attack surface and is a bigger, more juicy target.
Browsers are the most vulnerable, most commonly compromised, piece of software on the system. Browser integration is a key feature of a password system, so I accept that risk/ease of use tradeoff - especially for the less technical members of my family, but I've disabled the in-line unlock features both because it's just too darn easy to type into the wrong field (and I'm waiting for a malicious site to pop up a fake prompt), and because it covers up important information most of the time. The net is that runs in/with the browser needs to be at a higher standard than a standalone app.
I have zero issues with requiring a subscription for 1P8. Agile needs funding to support development, and their pricing is very reasonable for the capability they provide. However, that does mean I do expect a Mac application that enhances my overall security posture, not a lowest-common denominator hobbled solution based on a shaky framework with poor performance and UX.
Would I stop using 1P8 because it's electron? Not sure yet. Because of functionality gaps? Probably, but it's still early, so they should be fixed. Is there anything in 1P8 that looks like a genuine killer feature for the users? No.
Still haven't heard what's in it for the users with this migration. Maybe I'm missing something?
Net: As long as 1P7 will work on Monterey, and they commit to support it until 1P8 is full featured and stable we have time to see if Agile gets it right. If not, well, then time's really short.
P.S. At least they didn't try to build it on something like eclipse!
0 -
Is it really? Can't say I've ever done it, and even if I had, pressing macOS modifier keys is a brief split second action in general. Anyone "shoulder-surfing" would have to have superhuman photographic recall to read and memorise a long complex password in a second or less.
The problem is that the Zoom call or a Twitch stream can be recorded and it is pretty easy to go back frame by frame.
0 -
Very good reason to not do password unlocks inline in the browser :-)
and to share only the app, not the screen, but that's a different forum!
0 -
The problem is that the Zoom call or a Twitch stream can be recorded and it is pretty easy to go back frame by frame.
So at least make it an option, even if it's disabled by default. Don't just summarily remove the feature.
0
