1Password URL String is logged in website statistics software

admxnl

When launching a login 1Password initially sends a string with the URL probably to recognize the account in the browser extension but this gets logged in our website statistics (we saw this in Piwik statistics but I would imagine this also gets logged in Google statistics, Awstats, etc).

I find this a privacy issue because in my eyes website developers don't have to know I'm using a password program to auto complete the login process. Maybe there is another more private way to do this communication with the browser extension?

e.g. http://domain.tld/?onepasswdfill=ADE3A3EBBB0C46588E05452A6B988978

svondutch

http://domain.tld/?onepasswdfill=ADE3A3EBBB0C46588E05452A6B988978

We need this pass onepasswdfill= argument so that the 1Password extension knows what Login item to fill into your web browser. It doesn't expose anything about your Login item. It does tell whatever logging software you're running that you're using 1Password.

Maybe there is another more private way to do this communication with the browser extension?

Instead of clicking on an URL in the 1Password app, you can bring up the web browser, then press Ctrl+Alt+\ (or click on the 1Password button), then click on a Login item. This will then navigate to the URL without this onepasswdfill= argument.

RichardPayne

@svondutch Can the extension intercept the url before the browser sends the GET request to the server? If so then it could read the onepasswdfill value and then strip it from the query string before allowing the browser to continue.

svondutch

@RichardPayne I believe this is exactly what the extension is trying to do.

admxnl

@svondutch your correct, the extension is trying this but doesn't intercept the argument before the GET request.

I can't imagine Google/Firefox/MIcrosoft recommends this method of passing variables to an extension. Isn't there an API or other method to pass these variables on to the extension?

Another (probably) not so difficult change in your code would be to redirect the request after extension receives account information. Though I still prefer API method.

e.g. http://localhost/?onepasswdfill=ADE3A3EBBB0C46588E05452A6B988978&redirect=domain.tld

RichardPayne

@svondutch as I understand it, and correct me if I'm wrong, but this feature is only used when launching a login from the main 1Password application. Can the application not talk to the extension via the helper to trigger and launch and fill using the existing code in the extension?

jxpx777

For Firefox, Chrome, and Safari, the extension does indeed intercept the request and strip off this parameter before the request reaches the server at all. If you're seeing different behavior, could you please check the browser's console and see if you have any errors there? We've heard reports of similar behavior before, but we haven't been able to reproduce the problem so far. Any help you can give toward reproducing it will be most helpful.

admxnl

I'm using Chrome and see this behavior for every login I've created in 1Password. Automatically created and manually added, does not matter.

If I check our Apache logs on our webserver I can see the string passing the log for each login we launch via the 1Password application.

I can't seem to keep the console open for newly launched logins (new tabs) so I can't debug anything. Opening the console after login process does not show any problems.

You can reproduce it by creating a login point it to your own website of which you have access to the apache logs, no username or password required to enter. Launch it and track the apache logs, you'll notice the string in your logs.

Note: I have 1Password Windows 4.1.0.530

admxnl

I noticed when I search a login via CTRL + ALT + \ within Chrome and then launch the login it does not send the string in the URL.

So it seems to do this only when the login is launched directly from the 1Password Windows interface.

jxpx777

That's helpful information, admxnl! If you change your default browser to Firefox, do you still see the same behavior? I seem to remember that other users that reported similar issues were using Chrome as well…

admxnl

Hi @jxpx777‌, yes exactly the same result in Firefox and only when launched from the 1Password interface.

jxpx777

Thanks, admxnl. I'll have to do a bit of testing on this. If you have access to a Mac and could confirm that this is the same behavior there, that would be very helpful as well. There are a lot of moving parts here and narrowing down which wheel is being squeaky tells me where to put the grease. :)

admxnl

Sorry but I don't have a mac to test on. Maybe another forum user can help us out here.

jxpx777

Thanks for your willingness to test, but I was finally able to reproduce the issues here on my Mac. I've opened an internal bug report, and I'm focusing on improving some things in Firefox this week. I can't give a specific target timeframe for when to expect a fix, but please know it's on my relatively short list of things to work on in the near term.

jxpx777

Hi, folks. Just wanted to pop in and let you know that I've just finished some Go & Fill changes. The next beta of the extension should be available within the next day or so, so please be on the lookout for it and give things a test. This should especially take care of the onepasswdfill parameter showing in the website statistics logs in Chrome and make Go & Fill much more stable especially in both Firefox and Chrome. It also uncovered a couple bugs in the Firefox add-on SDK, so I've opened tickets to have those investigated as well. Thanks so much for your patience, and please let us know how the new release treats you.

jxpx777

OK, my "relatively short list of things to work on in the near term" turned into 6 weeks, but yesterday we finally published a beta with a big update to our Go & Fill feature. Please have a look here (Be sure to click "Show betas") for the release notes, but specific to this thread, the onepasswdfill parameter should not reach the website's server as long as the 1Password extension is installed. If it's not, then our code that recognizes these URLs and works 1Password magic with them can't fire to remove the parameter. So for instance, if you created 1Click bookmarks and synced these to another machine that does not have 1Password's extension installed, then those would include the parameter in the request. Please give it a test and let me know if you have any other questions or concerns.

@RichardPayne Mentioned the possibility of the helper handling this directly. 1Password only uses the onepasswdfill parameter when performing Go & Fill from the main 1Password application. When invoked from the helper, 1Password should essentially shortcut passed this step and issue the next step in the Go & Fill flow from the start.

Thanks again for your patience and passion for 1Password. Folks like you are who help us make 1Password better every day. :)

RichardPayne

Mentioned the possibility of the helper handling this directly. 1Password only uses the onepasswdfill parameter when performing Go & Fill from the main 1Password application. When invoked from the helper, 1Password should essentially shortcut passed this step and issue the next step in the Go & Fill flow from the start.

I know that. My point was that this could be the process:

1) User requests Login open
2) 1Password app send the request to the helper
3) The helper looks up its link to the appropriate browser extension
4) The helper sends the request to the helper
5) The extension then opens a new tab, loads the page and fills the login.

admxnl

Why go trough all this trouble when you cannot make the extension integrate like it's supposed to on short term?

Maybe a much simpler solution: just let 1Password launch the site as a normal shortcut/hyperlink and let the extension pop-up when it finds a login for this site.

In my opinion the onepasswdfill parameter is a workaround probably made because lack of time to write a direct interaction between the extension and the 1password application. Intercepting data after it has been send is probably not even recommended by Google for interacting with extensions.

jxpx777

Thanks for the feedback, guys.

@RichardPayne

3) The helper looks up its link to the appropriate browser extension

This is the tricky bit, right. How does 1Password know which connected client is the correct one? What if no browsers are running so you don't have any connection. What if there is a browser running that is not the user's default browser, say if I'm a web developer checking how my site looks in Firefox because of a bug report and I forget it's running and try to use Go & Fill from the main app. For me, that could lead to all sorts of headaches because of things like missing cookies to bypass security question prompts, etc. I'm not saying it's impossible to do this from the main app, but there are quite a few scenarios that could trip things up.

4) The helper sends the request to the helper

I'm not sure I know what you mean here. I think one of those "helper"s needs to be extension, but I'm not sure which one. :)

5) The extension then opens a new tab, loads the page and fills the login.

This is problematic already because of some browser bugs that actually prevent opening windows from extensions in some situations. For instance, Firefox Bug #1134785.

@admxnl

Why go trough all this trouble when you cannot make the extension integrate like it's supposed to on short term?

Not sure what you mean by this. Barring any regressions or new bugs in the new implementation, 1Password is behaving as designed.

Maybe a much simpler solution: just let 1Password launch the site as a normal shortcut/hyperlink and let the extension pop-up when it finds a login for this site.

1Password has always maintained a only-fill-when-the-user-says-so approach. There was even a security paper out a while back that praised 1Password for not having any autofill capabilities like some other password managers do. (I don't have the link to hand but I could locate it if folks are interested.) If there is no clue in the URL itself that the user intends to invoke 1Password, 1Password won't involve itself in the user's browsing.

In my opinion the onepasswdfill parameter is a workaround probably made because lack of time to write a direct interaction between the extension and the 1password application.

Again, not entirely sure what you mean here. 1Password and the extension do have direct interaction over their WebSocket connection. There are just two ways of initiating the Go & Fill operation. And we've had the onepasswdfill parameter since the beginning of the extension's development, which is nearly five years going back to the launch of Lion and Safari 5 on Mac OS X.

The onepasswdfill parameter also serves another function of providing 1Click bookmarks, which can be used directly from browsers and even from non-browser apps such as a todo list.

Intercepting data after it has been send is probably not even recommended by Google for interacting with extensions.

We are not intercepting it after it has been sent. (At least not anymore. The previously broken approach did send the onepasswdfill parameter, but 1Password should no longer be doing so. If you're seeing other behavior, please let me know.) We are using Chrome's chrome.webRequest API, which is the sanctioned way from Google for intercepting and modifying HTTP requests, which is exactly what 1Password does.

Thanks again for your feedback. Let me know if you have any other questions or concerns.

--
Jamie Phelps
Code Wrangler @ AgileBits
http://agilebits.com

RichardPayne

@jxpx777

What if no browsers are running so you don't have any connection.

Then you launch the browser and wait for the connection to appear.

What if there is a browser running that is not the user's default browser, say if I'm a web developer checking how my site looks in Firefox because of a bug report and I forget it's running and try to use Go & Fill from the main app.

How does the app determine which browser to launch when using the default "Open" command? If using the "Open In" command then the user chooses the browser.

For me, that could lead to all sorts of headaches because of things like missing cookies to bypass security question prompts, etc. I'm not saying it's impossible to do this from the main app, but there are quite a few scenarios that could trip things up.

All of which applies to blindly launching a browser as 1Password does now.

4) The helper sends the request to the helper
I'm not sure I know what you mean here. I think one of those "helper"s needs to be extension, but I'm not sure which one. :)

Oops. The second helper is supposed be the extension.

5) The extension then opens a new tab, loads the page and fills the login.
This is problematic already because of some browser bugs that actually prevent opening windows from extensions in some situations. For instance, Firefox Bug #1134785.

And yet, this is exactly how the 1Password extension works normally. Am I missing something?
Besides, surely you just catch the exception on tabs.Open() and call window.Open() instead?

admxnl

We are not intercepting it after it has been sent. (At least not anymore. The previously broken approach did send the onepasswdfill parameter, but 1Password should no longer be doing so. If you're seeing other behavior, please let me know.) We are using Chrome's chrome.webRequest API, which is the sanctioned way from Google for intercepting and modifying HTTP requests, which is exactly what 1Password does.

Ah, I've tested this and the onepasswdfill parameter is no longer actually send to the server.

jxpx777

@admxnl 4.4.0.BETA-1 You can get it here if you're not already using the betas. (Click Show Betas at the top of the page.) The Chrome version will be 4.4.0.1 since Chrome doesn't allow letters in its version numbering.

jxpx777

@RichardPayne

How does the app determine which browser to launch when using the default "Open" command? If using the "Open In" command then the user chooses the browser.

I would have to check with @svondutch on this, but I believe it should just be constructing the URL and passing it to the system's default handler. AFAIK, our Windows app doesn't have Open In, but I don't use Windows, so I could be mistaken.

All of which applies to blindly launching a browser as 1Password does now.

Yes and no. If we blindly launch the default browser, it's likely that you've already used it to go to the site in question and have the necessary cookies and such in place. If we did something like targeting any open browser first, then we could launch the site in a browser that you may not want to use. By just opening the onepasswdfill URL, we're guaranteed that the user's default browser will handle it. If we target it at whatever browser happens to be launched at the moment, it could lead to user frustration at being prompted for those things that are already properly configured in the default browser.

Besides, surely you just catch the exception on tabs.Open() and call window.Open() instead?

I would love to! Part of the problem is that the situation is just silently ignored. I forget what exactly at this point, but windows.open() had its own set of issues related to tabs. I didn't mean to digress this thread with these details; I just wanted to mention one example of an issue that we are facing. There are lots of these kinds of things that go into the decisions we make with 1Password.

RichardPayne

AFAIK, our Windows app doesn't have Open In, but I don't use Windows, so I could be mistaken.

That's incorrect. It does.

If we did something like targeting any open browser first

That's not what I meant. You should always attempt to use the default browser unless the user tells you otherwise.

Part of the problem is that the situation is just silently ignored.

Ooo, nasty.

I didn't mean to digress this thread with these details;

Maybe it's just that I'm a developer, but I like to understand these sorts of things, especially when the resulting decisions seem bizarre.
Given the questions that @admxnl was asking, I'd guess he's the same.

jxpx777

AFAIK, our Windows app doesn't have Open In, but I don't use Windows, so I could be mistaken.

That's incorrect. It does.

You're right. Our Windows folks corrected me on this point. I suspect some of our users would like this on Mac as well. :) I still need to check with @svondutch to see how this is handled. My assumption is that it's constructing the onepasswdfill URLs, but I want to be sure.

That's not what I meant. You should always attempt to use the default browser unless the user tells you otherwise.

I see. Sorry for misunderstanding before. Right now, using the onepasswdfill parameter is the most reliable way we have to perform Go & Fill in the default browser. There are a few different things that could happen if, for instance, the browser isn't already running and using the onepasswdfill URL parameter allows us a little more flexibility in making sure that the browser is fully launched and ready for requests.

Maybe it's just that I'm a developer, but I like to understand these sorts of things, especially when the resulting decisions seem bizarre.
Given the questions that @admxnl was asking, I'd guess he's the same.

Of course! I just didn't want to hijack this thread away from the original topic too far. We love talking with other developers about 1Password for sure. (Or about anything else for that matter…)

I do hope that my responses here have given some clarity about the design decisions and the various tradeoffs we've had to evaluate before arriving at the current design.

RichardPayne

Of course! I just didn't want to hijack this thread away from the original topic too far. We love talking with other developers about 1Password for sure. (Or about anything else for that matter…)

The point I was making was that I don't think that @admxnl would see it as hijacking. Hopefully I'm not taking too many liberties by putting words in his mouth.

admxnl

My concerns about the onepasswdfill parameter has been taken away because it no longer sends this data to the webserver. Though in my opinion it still is very weird to see the parameter in the url when opening the login.

MikeT

Hi @admxnl,

My concerns about the onepasswdfill parameter has been taken away because it no longer sends this data to the webserver.

We're glad to hear that.

Though in my opinion it still is very weird to see the parameter in the url when opening the login.

What is it specifically that makes it feel weird to you? We need the parameter to be able to do what you asked 1Password to do, open the Login and fill it. Some users have multiple Logins for the same site, so when you ask 1Password to open a very specific Login item, we need a specific ID to know which Login to use.

admxnl

It just doesn't feel naturally to first see a string behind the URL, the site refreshes and then see the actual URL. I haven't measured it but it also seem to consume more time because of the refresh.

Previously I've used Sticky Password, which was (and still is) capable of launching a specific login without the string/parameter behind the URL. Maybe this has some disadvantages or makes it less secure but it looks more neat.

MikeT

Hi @admxnl,

That's a good point. I am not familiar as to how it is doing that but in Chrome, it didn't refresh the page for me. However that could be because I blinked and the page refreshed very quick from the cache. Note: it is possible that it is only doing it in Firefox. Jamie bought up the link to the Chrome's WebRequest APIs, I suspect the way it works is that it modifies the URL before it reaches the site, so it didn't refresh. It is possible Firefox may not be doing this properly.

I've contacted the extension team for more information on how this works, I or Jamie (jxpx777) will follow up on that for you.

Thank you for explaining your concern, it is a very good point.

jxpx777

All three browsers cancel the request before it reaches the server. We monitor the requests and when onepasswdfill parameter is detected, we "correct" the request to strip the parameter and set up the tracking for that Go & Fill operation for that tab. As you can likely guess, this is handled slightly differently in the different browsers. After basically rewriting our Go & Fill approach thanks in part to this thread, I understand the various approaches much better now. Chrome's API is very nice and allows us to filter the requests to only run our script when a particular URL pattern is matched. In Firefox, we have to short circuit this ourselves, so we check the URL against a regular expression and return as early as possible if we are not interacting with a go and fill URL. Firefox's performance is slightly worse than Chrome's because it still has to locate and execute our Javascript function even if it's returning at the first line. Safari behaves similar to Firefox but its performance is a little worse still because Safari's navigation events are simply not as powerful as the HTTP monitoring available in Firefox and Chrome. I hope that makes sense. Let me know if I can clarify anything further.