Chromium compatibility with 6.8 [1Password does not send data to unsigned apps via Native Messaging]

c0re
c0re
Community Member
edited July 2017 in Mac

How do I downgrade from 6.8 (MAS) to a version compatible with chromium?

After using 1Password for years and recommending your App to a whole bunch of peoples around me (now paying customers), it's time to say goodbye. I really pissed what's going on here and what decisions are made at AgileBits. I don't like, that you force users to use your cloud service (like you do on Windows) and I don't like, that you tell me which browser I've to use (there are reasons not to use Chrome!). That’s the point.

So I'll downgrade to a working version of 1Password and then change to an other password manager. I'm done with 1Password.


1Password Version: 6.8
Extension Version: Not Provided
OS Version: 10.12.6
Sync Type: Not Provided

Comments

  • Hi @c0re! Thanks for reaching out. 1Password 6.8 has a different scheme in the database from the previous one, so downgrading directly isn't possible. You can export your data as 1PIF file, uninstall 1Password for Mac, and install an older version then import your data to use that.

    I'm also letting the team know that Chromium is something you used daily. Sorry for the inconvenience in your workflow, and thanks for continuing to use 1Password.

  • cyberdork33
    cyberdork33
    Community Member

    Thanks. I also found the change rather dissapointing. I've been using 1Password with Chromium for many many years.

  • Thanks for the feedback @cyberdork33.

    If you haven't read elsewhere, the reason 1Password cannot currently work with Chromium is that Chromium is not a codesigned application. 1Password's new messaging system requires that applications be codesigned in order to talk to it. This is generally a good thing, in that it increases security, but it does mean that some 3rd party developers will need to either start codesigning their apps, or they will not be able to talk to 1Password.

    Thanks.

    Ben

  • cyberdork33
    cyberdork33
    Community Member

    Thanks Ben, but since chromium is primarily distributed as source, it doesn't really make sense to codesign the builds that they distribute because many users are not using those builds. I turn the browser verification off, I would have expected it to work in that configuration.

    Is the primary concern about verifying a browser build or just establishing an certified communication path between the two applications? Maybe allowing the users to provide their own credentials to both apps could satisfy the concern? Relying on some signature by an entity that the users have no control over seems to leave the users out.

  • AGAlumB
    AGAlumB
    1Password Alumni
    edited July 2017

    @cyberdork33: The whole chain of trust that all of us depend on for security, at least on the web, though more and more on the desktop as well, is out of users' control. And it's about not only security but also accountability. Most users aren't going to be able to review the source code even though it's available. And not having it signed defeats the purpose of us signing 1Password and getting the extensions approved by the browser vendors. You make some interesting points. Every link in the chain matters, and as browser extensions are locked down further and we move to support these changes ourselves, maybe it makes sense to remove this option, since it only applies to WebSockets anyway, as we move away from that technology in this and future releases. Thanks for the feedback on this.

  • jxpx777
    jxpx777
    1Password Alumni
    edited July 2017

    @cyberdork33 I just want to add on to what Brenty said with a little more details. First, I would love to know more about why you're using Chromium over Chrome or another Chromium-based browser. I'm not sure what benefit there is to using unsigned software that doesn't automatically update and can't be validated before you run it.

    If I could rephrase your "primary concern" question, I would say it's more about being able to verify the identity of a process, that it is who it claims to be. 1Password is conservative in what processes it allows to access your 1Password data. We don't want just anybody that knows how to use stdio to be able to ask for your 1Password data. And in the case of an unsigned application, there is simply no way to verify from one connection to the next that the identity is the same. The system has no way to distinguish between an updated application and an application that is pretending to be another application.

    We are thinking of ways that we can open things up a little bit in the future, but in the best case, you'll have a prompt from 1Password every time Chromium tries to connect since 1Password wouldn't have a way to validate that this process that's claiming to be Chromium is indeed the same Chromium that previously connected. To be clear, this feature doesn't exist yet and isn't something we're actively working on right now, but we're considering our options.

    In the case of some mutual authentication, we do have this for WebSocket connections because those connections are by their nature open to connections from other user accounts. (We filter out any connections from other user accounts, but there are edge cases that the authentication guards against.) But this can't protect you from processes running inside your own user account. The main reason for this is that there is nowhere to store such a secret that could not be found and exploited by a bad guy. (Safari is the only browser I know of that has secure settings that are encrypted and stored in a secure fashion.) 1Password does use a shared secret to obscure traffic between the extension and the main app for all connections, but this cannot protect against a process that can run with the full privileges of your user account. (Malware tends to opt out of application sandboxing. :wink:)

    So, back to my original question about the motivation to use Chromium… The Chromium team themselves encourage Canary as a signed build for those that want early access to the newest features and emphasize that Chromium should be used to verify bug fixes and other active development and testing of the Chromium project:

    You can test Chrome builds or Chromium builds. Chrome builds have the most infrastructure for analyzing crashes and reporting bugs. They also auto-update as new releases occur, which makes them a good choice for most uses. Chrome Canary is available for Windows and Mac and autoupdates daily. Other channels (dev and beta) are available.

    Chromium builds do not auto-update, and do not have symbols. This makes them most useful for checking whether a claimed fix actually works.

    There are of course other browsers that are based on the Chromium source that are great options if you do not want to use Chrome of any flavor. Brave and Vivaldi are two that work well with 1Password. Brave is security and privacy focused, and Vivaldi, which is being developed by some of the original figures associated with Opera and has attracted a lot of the old school Opera fans, has a lot of very useful features and gorgeously integrates its UI with the websites you visit.

    I hope this explanation makes sense, whether or not you agree with the decisions. As we are fond of saying around here, no decision is permanent, but right now, we don't have plans to allow code signature checking to be disabled for native messaging connections, and in the not-too-distant future, our client apps will begin removing the WebSocket capabilities and the advanced checkbox entirely. We definitely want to hear your perspective, though, so that we can take everything into account as we work to make sure we've made the best decision for the greatest number of 1Password users.

    --
    Jamie Phelps
    Code Wrangler @ AgileBits
    Fort Worth, Texas

  • XIII
    XIII
    Community Member

    First, I would love to know more about why you're using Chromium over Chrome

    I don't use Chrome, but would rather use Chromium if I had to because it has less proprietary close-sourced Google bits:

    https://www.howtogeek.com/202825/what’s-the-difference-between-chromium-and-chrome/

    This (privacy concern) might be a consideration for more 1Password users?

  • c0re
    c0re
    Community Member

    This is not a discussion about chromium. It should be a discussion about why you disable clients browsers (limitation on signed browser) and force user to use an other browser without proper information of such elementary changes. A small note such as "Native Messaging for Chrome" in the release notes is much not enough!

    By the way, talking about the "chain of trust" maybe makes sense on your perspective in a technically consensus but in my view, it’s just stupid to send passwords in the cloud an hope "the owner will care about my security and privacy".

  • AGAlumB
    AGAlumB
    1Password Alumni

    @c0re: That's why we don't "send passwords in the cloud". We don't want that either. But as Jamie mentioned already, what you're asking for is to have 1Password send your data to anything running on your system. So that seems a bit contradictory.

    The browser implementation we we've been using for years has been good enough, but given the changes in Chrome and Firefox, which are still the most used browsers overall, we needed to make some changes ourselves to be able to support them going forward. The option to disable the code signature check didn't exist to facilitate insecurity; we support that with WebSockets because this is necessary for many users to be able to use the 1Password extension in supported browsers which are codesigned, since firewall, proxy, and antivirus software can interfere with the connection, preventing it from working at all. That isn't the case with Native Messaging. As Jamie also mentioned, there are plenty of alternatives out there (Canary, Vivaldi, etc.), and not having the ability to circumvent a security check isn't stopping you from using one of those, and doesn't prevent others from using supported browsers due to interference from 3rd party software.

    I can't promise that we'll have a solution for you to use unsigned browsers with 1Password in the future, but it's something we'll continue to discuss both internally and with you and other customers. I'm sorry that you're no longer able to force 1Password to allow you to use an unsupported browser, but we need to focus first on making sure that 1Password works with supported browsers both now and in the future.

  • AGAlumB
    AGAlumB
    1Password Alumni

    @XIII: Thanks for letting us know! Have you tried Vivaldi? Many of us (well, at least it seems that way to me) here are huge fans, and since it's signed you (and 1Password) can also verify its source and hasn't been tampered with. Also, great link on some of the differences between Chrome and Chromium. Cheers! :)

  • cyberdork33
    cyberdork33
    Community Member

    @jxpx777 It seems that the main reason that Agilebits believes that people use Chromium is to be on the bleeding edge, and maybe for some that is the case. For me that is simply not true. In fact, that is something that I dislike about it. I'd rather have builds that are not ahead of what is used for Chrome. That would make some of my usage situations easier.

    I use chromium over chrome mainly for two reasons. The first because of what @XIII mentions above. I am not interested in the proprietary inclusions from google. I prefer to use open source software where possible. The second reason, which is somewhat related to the first, is that I use several OS platforms. My primary system that I use everyday for work is Mac OS, but my preferred OS is a linux distribution, and several distros rely on chromium as a primary browser. I sync settings and what extensions are installed between browsers, and once you do that on a newer browser version, it sometimes breaks your account usage on older browser versions (like Chrome). So I also use it for consistency in my usage between Mac OS and Linux Desktops. Some of the reasons stated for moving to a signed build of a browser are also reason that I would not want to change. My primary source for builds of chromium for Mac OS is usually freesmug. Although I get much of my open source software for Mac OS through homebrew.

    Please know that I do not under-appreciate the concern for data security in inter-process communications. I understand that this is very important to 1Password’s operation, as it should be. My thought was that since both the main 1Password application and the extension were controlled by Agilebits, that communication between those two items could be authenticated in some other way. I do see your point about not having a way to securely store credentials in the extension though. This was just an idea I threw out and I have not tried to think through the entire problem.

    I may look into Brave. Vivaldi is certainly not for me (I never liked Opera though either so…). I appreciate that you are indeed having a full discussion about it and the reasoning behind it. So many companies make changes to software for good reason but do not lay out the reasoning well to users.

    The one thing that makes 1Password stand out from other password managers for me is the great browser integration. Having that no longer work for me is a huge impact and basically makes 1Password no different to me than many other systems out there. I, of course, do not expect Agilebits to develop and maintain a portion of code simply to appease one user’s unique case, so I understand if it is decided that better support for usage in chromium is not priority. Thanks again for the true dialog on the matter and your consideration of the idea.

  • AGAlumB
    AGAlumB
    1Password Alumni

    @cyberdork33: Wow. Yeah, totally. Thank you for your reply! You make some great points, especially with regard to using a consistent setup between all of those platforms. I'm sorry I don't have a good solution for you there, other than considering alternatives. There a number of Firefox- and Chromium-based browsers out there, and you may find that one will fit into your workflow. As a multiplatform user myself, I definitely sympathize. It isn't easy to find a browser I'm happy with that works everywhere.

    Honestly, while your comments and mine above are certainly relevant, I think we may have gotten away from the core issue here: These changes to 1Password's browser integration are necessary moving forward. I get that it would be preferable to have more options and better communication, but the problem is that neither of these are really feasible in this situation. For example, it's necessary for us to lay this groundwork now so that browser integration doesn't unceremoniously break for all users with future releases of 1Password and the extensions. And since users don't have a choice in this (we don't either; we will have to use Native Messaging exclusively later this year) offering more information about this stuff upfront isn't actually helpful. As much as it sucks that your browser of choice may not be able to work with 1Password going forward due to its unsigned/prerelease status, I don't think a press release (for lack of a better term) announcement this offers a real benefit either, because either way it's got to happen.

    It isn't something we're making a lot of noise about since it's a fairly early beta, but you may want to check out the ChromeOS- and Linux-compatible extension we've recently released as a private beta. I'm not sure this will be a good solution for you, and it certainly isn't complete at this stage, but I wanted to at least mention it since it may be of interest.

    Thanks again for your feedback on this. Knowing the way that people use 1Password really helps us as we make these tough decisions, even if we can't always accommodate everyone's use case.

    P.S: I should warn you that Brave will not work with 1Password at all until they get around to updating their integrated extension, since they do not allow 3rd party extensions to be added the way that others do. Last I heard they were working on this, but the current release it several months behind as I write this. I rather like Brave and what they stand for, so I'm hoping to be able to use 1Password there again soon.

  • AGAlumB
    AGAlumB
    1Password Alumni

    @cyberdork33: Just wanted to follow up here on my last comment regarding Brave. I was told that they were shipping a new 1Password extension with their latest release, 0.17.19, but since I was still getting (1Password extension) 4.6.3.90 after updating fully I was hesitant to tell anyone else that this was so. However, installing a fresh copy of Brave 0.17.19 over the one I'd gotten with the in-app updater gave me (1Password extension) 4.6.7.90. So looks like we're back in business there. :)

  • jxpx777
    jxpx777
    1Password Alumni

    @cyberdork33 You definitely raise some interesting points. We have some ideas for how we can allow browsers other than The Big Four that 1Password officially supports (Safari, Chrome, Opera, Firefox) or those that 1Password has blessed with code signature whitelisting to connect to 1Password. There's an issue open to track it as well, but I don't have anything more to share for how this might pan out since it's still such early days and whatever we end up doing could look wildly different to what we have discussed even internally so far. We have talked about a few different ideas, but for all of those ideas, a signed application is still going to be a much better experience than an unsigned one.

    Since we were talking about Brave and Vivaldi, I am reminded of the issues that some of their teams had with testing the update to the 1Password extension. The transition to native messaging meant there were a few things they needed to check out. They obviously run their browsers locally from source during development. These builds are not signed of course, so it was indeed a bit of a chore for them to test things out because they had to sign a build once they were confident they were ready to test things out. So, while Chromium is probably the best and most public example of this challenge of an unsigned application, it's not something we have singled out as a particular target for the pillory.

    Thanks again for this discussion. It is obviously important to hear from our users whose situations might be on the edges of the 1Password experience. We definitely try to keep the tent as big as possible to cover everyone, and where we can, we will continue to do so.

    --
    Jamie Phelps
    Code Wrangler @ AgileBits
    Fort Worth, Texas

    ref: OPM-4763

  • XIII
    XIII
    Community Member

    Have you tried Vivaldi?

    No, I use Firefox on Windows/Linux and Safari (& Firefox) on Mac, so I'm probably fine with respect to browser signing.

    I'd like LastPass-like integration in iCab Mobile on iOS though... :wink:

  • AGKyle
    AGKyle
    1Password Alumni

    Hi @XIII

    I'm fairly certain we won't be adding anything like that to any 3rd party apps. It appears that it allows you to sign into your account and that grants iCab complete access to your data. So the basis of my response is based on this assumption.

    The distinct difference with 1Password is that we do not advise our users type their Master Password (or Secret Key) into anything other than our official clients. We can make promises about how we don't send your Master Password or Secret Key anywhere, but we cannot make those same promises of other third party apps. This isn't to say that 3rd party apps are doing this, but due to the risk there we simply can't advise it. It's a bad habit to get into and not one we will ever encourage.

    While we do wish that there was a more distinct way of quickly accessing the extension in 3rd party applications this type of change is one that most definitely seems to sacrifice security for some convenience that we don't find worth it. I'd love if I could put my 1Password extension icon in the Safari toolbar on iOS though :)

  • XIII
    XIII
    Community Member

    Ah, understood.

  • AGKyle
    AGKyle
    1Password Alumni

    Hi @XIII

    We never say never, but giving the keys to the kingdom to a 3rd party is probably much closer to never than to maybe someday.

    That said, if you ever have any requests definitely reach out to us so we're aware of any requests. We try to work on the requests that have the most people asking for it. Not everything will make it on the list but it's one of the ways we try to handle requests as best we can.

  • cyberdork33
    cyberdork33
    Community Member

    Following up here... Unfortunately Brave will not work for me (at the moment anyway) as I have a requirement to support smartcards in the browser for authentication. It does not appear that Brave has that capability.

    @AGKyle While your concerns about providing your private key (master password) to a 3rd party application are completely valid, is it really valid for Agilebits to force the user choice in that instance? If I, as a user, and owner of the data in question, find the risk acceptable, shouldn't I be allowed the choice to provide my keys to that 3rd party application if I deem it acceptable?

  • AGKyle
    AGKyle
    1Password Alumni

    @cyberdork33

    Something very important to keep in mind here is that while some users, likely several in this thread, know the ins and outs of what they're doing and can make more informed decisions the vast majority of people will not know the gritty details.

    What happens if we want to change things under the hood? Now all those users who might use some 3rd party app might get stuck in a situation where that no longer works until it's updated in the 3rd party app until that's updated. Whereas we can plan our updates around these changes. Working with other parties is complicated and can really slow development down. And if we allow one app to do it, a bunch of others will want to as well and that increases the potential risk significantly. We might be able to vet one app but we can't vet all of them.

    But to go directly to the point, you might find the risk acceptable, but you understand the risks. My mom or dad? they'll never understand these risks no matter how I explain them and I would never under any circumstances type my Master Password into anything other than 1Password so I would therefore never recommend it to my mom or dad. There are a lot more users out there that use 1Password than just the technically savvy users. This is what we want of course, we want everyone using 1Password because it makes people more secure and we hope it also improves their experience online. Our users trust us to help them make the right decisions and we feel this is a step backwards with regard to security.

  • cyberdork33
    cyberdork33
    Community Member

    I guess I value the freedom of choice over the walled garden ideology. It is not meant to be an offense to the business practices for the company. Agilebits should cater to their primary market.

    I guess my issue is that we are not talking about whether something the default, or whether to make a setting non-obvious to change though, you are providing no other option other than what you have decided for the user. That crosses the line a bit for me beyond just looking out for me. Not something I would fall on my sword about, but not my preference anyway.

    As far as your security / risk education argument, I would only offer the old adage, "Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime."

  • AGKyle
    AGKyle
    1Password Alumni
    edited July 2017

    @cyberdork33

    Consider this:

    What happens if another app does something that causes data loss or steals the data in someone's account?

    Is that our responsibility for not protecting our users or is that the user's fault? It's very hard as a company to blame the user for trusting something we allowed. It never goes over well and will often result in the user not trusting us and these days the average user has a pretty big voice with all of the platforms the internet has allowed.

    The technical users will once again think no biggie, you enabled an option that's meant for power users, but all of the casual users (and media outlets most likely) will latch onto the fact that we allowed something bad to happen to user data and our non-technical users or potential users might see that, not totally understanding how things work and now have a negative opinion of 1Password.

    We also have to look out for ourselves in this respect.

    I never said this would never happen, but it's very much approaching that end of the spectrum I think. The beauty of the 1Password extension on iOS is that it has to be explicitly enabled and invoked. It also requires the user to select the item they wish to send to the app and only that item gets sent to the application. This limits the impact of a potentially malicious app. They can't just pull in all of the information.

    And because it's our extension we control the look, feel, and operation of the extension. It can live up to our expectations and our users expectations. We can also make sure that the extension is doing the right thing with regard to security of the Master Password.

    I see your point, and I certainly respect your opinion on this (I'm not saying you're wrong, just that our stance is likely different than yours), and I am most definitely not the person who makes these decisions at AgileBits. But given past answers to these types of questions I don't think this type of feature will become available unless there are better security precautions that can be made and enforced by someone other than the 3rd party application. I realize this goes against what your opinion and desires are, and this is part of the beauty of there being choice of password managers. No one single application will ever do all that you want, so you'll very likely always have to weigh the pros and cons of each to find the one that fits the most checkboxes for you. We hope we're that one but we realize we won't be that option for everyone.

    There have been a number of security articles written in the near 6 years I've been here and many other apps have been hit much harder than we have because we took the secure route instead of the potentially dangerous (but maybe more featured) route. We've been really happy that certain choices we've made have helped our users be more secure.

    On another note, I suspect that as developers, many of our team really would love to experiment with these types of things because they are incredibly neat. But incredibly neat doesn't always win out against the security issues that come with those neat ideas.

This discussion has been closed.