Browser could not be verified. [Solution: browsers must be stored under /Applications folder]

scottrbaxter

I found a bug in Chrome 56, so I decided to test Chrome Canary 58 on my Mac and the Chrome bug is gone.

Since testing this, I get the 1Password extension "Browser could not be verified" message... even though it did the verification in Chrome Canary. I read that there are issues since Canary is a dev. build... fine. I did not touch the 1Password beta, or the beta extension... i need this to be stable for work, so I'd really rather not go that route.

I've since uninstalled Canary, and reinstalled Chrome 56, also removed the 1Password extension and rebooted my Mac. On startup, I install the extension from the 1Password Mac app, and it installs and prompts me for the 6 digit verification number. All of that is fine. I click on the Chrome extension icon, and still see "Browser could not be verified". How do I fix this?

Fwiw, the extension in Safari works fine, and has not needed any changes in this whole process... but I use Chrome as my primary browser and need it for work.

---

1Password Version: 6.5.3 (Mac App Store)
Extension Version: 4.6.3.90
OS Version: MacOS Sierra 10.12.3
Sync Type: iCloud
Referrer: forum-search:browser could not be verified chrome

scottrbaxter

Also, I just removed google-chome 56 as well, and downloaded v55, as that was prior to the bug i came across. I removed the 1Password extension, rebooted my Mac, opened chrome 55 and installed the 1password extension again... same issue. Honestly at a loss here.

scottrbaxter

Ok, I just realized the issue. Following https://support.1password.com/code-signature, I did buy 1Password from the Mac App Store.

I'm on a work computer, and don't (usually) have admin access, but can gain it for a small amount of time as needed. Since that restricts me access to /Applications, i have apps like chrome and chrome-canary in my user folder ~/Applications.

I got the chome 55 app moved to the root /Applications, and i no longer get this error.

Moving forward, any chance your devs would be willing to accept ~/Applications as a safe location to a browser such as google-chrome's stable build? That'd be a huge help for non-admins on Macs.

matthew_ag

Hey @scottrbaxter ,

Thanks for writing in and I'm glad you were able to figure this out. Thanks for the suggestion, it's always good to learn of the different setups that people have and requirements that you guys need. Unfortunately for the Mac App Store version of 1Password, it's not possible for us to add ~/Applications as a trusted location because the limitation is imposed by Mac App Store Sandboxing rather than something that we can control ourselves. It's a security limitation imposed on us when we distribute through Mac App Store. The idea is good in that it imposes restrictions on the app so that it only has the capability to do what it needs to do rather than having the full permissions of the user account it runs under.

The good news is that if you like you can switch and use the version of 1Password we distribute directly through our website and you won't have this limitation. You can do this for free too - all you need to do is contact us with a copy of your Mac App Store receipt and request a license directly from us. That should help work around this limitation.

If you've done that just post the ticket code you get back in the auto-reply to this thread and I'll get you sorted out :chuffed:

Best regards,
Matthew

scottrbaxter

Thanks @matthew_ag. Just to be clear, the 1Password app purchased through the Mac App Store is still in the root /Applications folder as it was installed via MAS. I downloaded and added Google Chrome.app to my user ~/Applications folder. Could you better explain what this sandbox limitation is, since the 1Password.app is not being moved?

I'm just not following how the Mac App Store could have a security limitation for the 1Password extension running inside a 3rd party app that is in a different location than /Applications.

matthew_ag

Hey @scottrbaxter,

Sure, sorry for the confusion - I was referring to where the browsers were located rather than the 1Password app. The Mac App Store version of 1Password can only verify signatures if the browsers are installed under the root /Applications folder. macOS will prevent 1Password from reading from other locations.

Our extension connection and verification flow works like this:

1. The 1Password extension in the browser attempts to open a connection to the 1Password app. This is done via a loopback network connection (i.e. connecting to 127.0.0.1).
2. The 1Password app is running a local server that is listening for a connection. Once a connection is made the verification process begins.
3. To verify and trust the connecting process, the 1Password app takes the source port of the connection and does a reverse look up of the macOS process connecting from that source port. So in the case of the 1Password for Chrome extension this will be one of the Chrome processes. Once the reverse lookup completes we'll have the path the process that initiated the connection. In order to verify the signature of the connecting process the 1Password app will then attempt to verify the signature of that process using it's path. This is where the failure occurs due to sandboxing. The low-level signature-validation API we use to verify the process signatures only works for processes under /Applications.

I hope this clarifies the limitation - if I didn't answer your question or you have anymore questions about it do let me know.

Best regards,
Matthew

scottrbaxter

Thanks for the clarification. This certainly helps explain what's going on in the sandbox. I may consider taking 1Password up on the offer to transfer from the MAS purchase, though I'm pretty hesitant to do that, not being able to know what can change in the future.

jxpx777

@scottrbaxter Your hesitation is definitely understandable. As a developer and consumer both, I prefer direct distribution over the MAS for a few reasons:

1. It puts more money in the pockets of the developers (Apple takes a 30% cut…) so they can continue to make great software (And, yes, so I can pay my mortgage and such.)
2. It means faster turnaround times for updates. Even with app review being so much faster these days, a direct distribution is only constrained by the speed of the computer that's building the release and the Internet connections that are transferring them.
3. There are fewer restrictions on what apps can do. If an app wants to pursue a feature that runs afoul of the MAS's sandboxing requirement or other rules, the direct distribution model still allows the app to fully embody the vision of the developer.
4. Bonus Round: I can automate the downloading and install of (most) direct distribution apps, which is not possible with the Mac App Store to my knowledge. I use Boxen to keep my configuration repeatable, and since it has Homebrew Cask support, I can easily keep my MacBook Pro and iMac up-to-date and in sync.

I think this issue with validating the browsers falls under 3 above. For now, the more flexible model is outside the Mac App Store. The only downside to purchasing direct is if you eventually wanted to move to the Mac App Store version for some compelling reason, the developer wouldn't have a way to prevent you needing to make an additional purchase.

I hope that helps. Let us know if you have other questions or issues.

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

scottrbaxter

Makes sense for a developer. As a consumer though, i really like knowing that I can install the app on all of my appleid registered devices, and am not digging through faq pages hoping someone's already asked the multicomputer licensing question. Having a work and personal computer, it's great to be able to install on more than one machine with a single purchase. I'm also a fan of both the rating system and user comments. Crowdsourcing info on an app (including per version) may not be perfect, but it is a strong indicator en mass as to whether the app will suit my needs. I'm not a huge fan of the walled garden limitations sometimes, but it has been a great help in many regards.

jxpx777

I definitely see where you're coming from as well. Luckily both are available so we can both choose what suits us better. :)

luckyday

I came here to find a solution, but have discovered that the latest MAS version 6.7 has corrected the issue. FYI

matthew_ag

Hey @luckyday,

Thank you for sharing this for others who may encounter this same issue. :+1:

You are correct, with the release of version 6.7 of 1Password for Mac we updated our built-in Chrome signatures which ensured that 1Password for Mac was able to correctly verify the connection from the Chrome browser. Sorry for the inconvenience.

Thanks again and if you have any further trouble with 1Password don't hesitate to contact us again.

Best regards,
Matthew