Why does 1password need to be logged in before I launch Chromium?

xthemage
xthemage
Community Member
in 1Password in the Browser

Since the recent update to how 1p interacts with browsers, Chromium integration has been wonky. I understand that Chromium isn't officially supported... but the fact that I can go through a very specific song and dance that gets Chromium to work makes it seem like this is a bug on 1p's part (I'll give you credit and not assume that this is intentional).

Specifically: I have code signing disabled, but I still get the "Browser could not be verified" message when I launch chromium, or when I try to use the 1p widget. However, if I log in to the 1p widget (i.e., I enter my password without actually filling in any passwords), and then launch (or restart) Chromium, everything works perfectly fine until Chromium quits. So erm... what's up?

1Password Version: 6.8
Extension Version: 1Password 6 Version 6.8 (680015) AgileBits Store
OS Version: OSX 10.10-10.11
Sync Type: Not Provided
Referrer: forum-search:log in to 1p before launching browser

Comments

  • littlebobbytables
    littlebobbytables
    1Password Alumni

    Hi @xthemage,

    I have news you won't like I'm afraid. The workaround you're using won't last for long and 1Password will only allow connections from signed browsers that are whitelisted in 1Password. The list of supported browsers include:

    • Safari
    • Firefox
    • Chrome
    • Vivaldi
    • Opera

    Longer term there are discussions as to what we can do to better allow user choice over the browser but there is no ETA and nothing agreed on yet. None of the scenarios I've seen discussed will allow an unsigned application to connect at all due to the untrusted state it represents.

    I imagine you won't be happy about this and I can empathise. The implications of this security change and the impact on Chromium were discussed before being agreed upon and the change made. Sorry :(

  • xthemage
    xthemage
    Community Member

    That's disappointing. Please make it abundantly clear when you publish the update that outright breaks Chrome support, as I will not be upgrading past that point.

    One point that I am curious about however. The "fill-in password" functionality is triggered by me from the keyboard. I actively interact with the 1password menu-bar widget, and explicitly select a password, which presumably gets then pushed to the browser. Given that a user interaction is (or at least should be) required to trigger the release of a password, why does 1p care what app I'm choosing to release that information to?

  • matthew_ag
    matthew_ag
    1Password Alumni

    Hi @xthemage,

    We will do our best to make it clear when this change comes around. In the event that you inadvertently upgrade it is possible to downgrade again. While of course we would discourage this given you would be missing out on any security and feature updates we would be very happy to help with any trouble you encounter.

    Given that a user interaction is (or at least should be) required to trigger the release of a password, why does 1p care what app I'm choosing to release that information to?

    A user interaction is always required for a password to be filled by 1Password. However this is only implemented by user interaction design. Within the protocol (the way the extension and 1Password app communicate) it is possible for the extension side to request information from the 1Password application therefore it is necessary for the application to ensure that it can trust the extension is the real deal instead of a rouge application pretending to be the extension. This trust is developed by using the operating system's built in application verification system to ensure that:

    1. The application was distributed by a known and trusted developer, e.g. Google in Chrome's case, Mozilla in Firefox's case, etc.
    2. The application has been verified to have not been tampered with since it was distributed by these trusted developers.

    In Chromium's case, the developers have specifically chosen to not sign the Chromium application when they distribute it so it is not possible to check the above two in order to trust it correctly.

    I hope this helps, if you've any further questions please don't hesitate to ask.

    Best regards,
    Matthew

  • jxpx777
    jxpx777
    1Password Alumni

    I should add to what @matthew_ag said and make it clear that we are planning eventually to remove the older WebSocket approach from our Chrome extension later this year. (We don't have a timeframe to share but it's not coming next month or anything like that.) So, this is not only a change that is happening in the 1Password apps but also in the extension. Browsers are rightfully aggressive in keeping extensions up-to-date, so over time, you will likely find this more and more difficult to maintain.

    I would love to hear more about your reasons for using Chromium vs say Chrome Canary or one of the other Chromium-based browsers. It seems like a lot of trouble to be honest since Chromium does not automatically update in addition to being unsigned. Failure to update software is one of the top (if not the very top) cause of security breaches.

    The ability to disable code signature verification was a necessary evil for some legitimate cases where 1Password could not properly locate a legitimate browser. This happened sometimes with proxy software such as ad blockers and the like but in other situations too. It had the side effect of leaving the door open for any other unsigned browser such as Chromium to connect to 1Password. Now that we no longer have the issues with locating the browser process in the code signature validation routine, we no longer need to allow this checkbox to work for native messaging connections.

    The fact is it is a security risk to use unsigned software. There is simply no way to verify where the code came from or that the code hasn't been tampered with before download, during transit, or at some intervening time on your own disk. We take our users' security very seriously and allowing arbitrary connections to 1Password from unsigned applications is not something we're considering. Like Matthew said, we are considering ways to make it easier to use 1Password with signed applications other than those that 1Password has built in recognition for, but I don't have a timeframe to share for when that might be available.

    Thanks for taking the time to discuss this here, though. It's really useful to talk with our users and get their perspective so we can make the best decisions going forward.

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

This discussion has been closed.