What do onepasswdfill and onepasswdvault in browser URL bar mean?

kibitan

hi! I got similar problem with below ticket.

Login URL has "onepasswdfill=[HEX]?onepasswdvault=[HEX]" added — AgileBits Support Forum
https://discussions.agilebits.com/discussion/65168/login-url-has-onepasswdfill-hex-onepasswdvault-hex-added

for me, my chrome was requested to https://xxxx.com/xxx?onepasswdfill=xxxxxxxxxxxxxxx&onepasswdvault=xxxxxxxxxx

I'm wondering that is it safe of this parameter's value become known to other people? And how to fix this issue?

---

1Password Version: 1Password 6 Version 6.6.4 (664001) AgileBits Store
Extension Version: Not Provided
OS Version: macOS Sierra 10.12.4
Sync Type: Not Provided

jxpx777

Hi, @kibitan. Thanks for your post. (And welcome to the forums!) These URL parameters are used by 1Password to indicate that you're using an open and fill operation from a Login's details view by clicking the URL there. When the 1Password extension is installed, these should be stripped off and you should be redirected to the URL without those parameters. If the extension is not installed, you could see the behavior you're describing.

This is actually something we're looking into reworking. The least interesting reason is because the situation you're describing technically leaks some information about you, but really only that you use 1Password. It doesn't include any of your data. Those bits of text (Depending on your version, they might just be hex or could be a wider character set…) are just the UUIDs for your item and the item's vault. These are randomly generated and not connected to the content of the item or vault.

The more interesting reason for making this work differently is that it would simplify the approach in our 1Password applications for Mac and Windows take to interacting with the browser for open and fill operations and give them much more control over the process. Right now, we have some fairly unattractive workarounds for a couple of scenarios that a reworked implementation would help us remove.

Beyond that, reworking this a bit further would allow us to make 1Click bookmarks, which currently use this URL parameter technique, more portable so that they could work on, say, iOS.

These improvements are being tracked in our bug tracker but that's about all I have to share about it for the moment. Making this change will require coordination between 1Password extensions where I work and multiple platform apps (Mac, Windows, iOS, possibly even Android) in order to make this experience as consistent and seamless as it needs to be. As you might guess, that's a hefty challenge as every team has a lot of things on their list that are honestly more urgent than rewriting something that has been working the way it does now for as long as it has.

I hope that helps explain the situation. Do let us know if you have any other questions or concerns.

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

ref: OPM-4635
ref: OPM-4637

kibitan

hi Jamie @jxpx777 ! Thank you for a polite reply, and you mentions in detail finely. I really satisfied your answer, thanks.
Hopefully you can fix this issue soon, but there is no sensitive information of that token, yea just UUID I can guess it's harmless, so I don't care much when you will.
Thank you very much, I will use your lovely product well!

AGAlumB

Yeah, it's really just not an ideal solution, so we'd like to come up with a more elegant way of handling this. We'll keep working on it. Thanks for the kind words! :chuffed: