Unsecured Websites - 1Password 7 Version 7.0.BETA-18 (70000018) AgileBits Beta

Mr. K.

This could be made easier and work better. First off, it would be nice if 1Password could just go and check to see if the site has been updated to secure and then add the"s" to http and be done. Also, when I click edit, add the "s," and then click save, 1P7 takes me to the categories list rather than the next item in the Unsecured Websites list. That should not happen in my opinion. If I don't click the save button after I edit, and just click the next time in the Unsecured Websites list, then I get a "do you want to save changes" message, I click that and I stay in the Unsecured Websites list. That's how it should work either way.

---

1Password Version: 7.0
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

OAW

Ditto!

Bill.

Along similar lines, the notifications are bold, intrusive, and not necessarily relevant. For example, I have 2 factor authentication on for a site, but bypass it when my device is recognized as having previously logged in. Now I have an orange block that shows up whether I like it or not.

In addition to the suggestion above, which would remove the irrelevant notification about insecure sites, it would be nice to have a means to close specific notifications that the user, with good reason, chooses not to deal with.

Every notification that I've looked at so far refers to a circumstance that I do not wish to change. These notifications are loud and unwelcome.

Ben

@Mr. K.

Thanks for the feedback! I can certainly understand the desire for more automation. Perhaps that is something we can consider as we continue to iterate on the new Watchtower features. I agree that when finished editing an item it would be helpful to return to the next item in the list, rather than the All Items view. I’ll make that suggestion to the team as well.

Ben

Ben

Hi @Bill.

For 2FA flags you can have Watchtower ignore them by adding a “2FA” tag to the item. I’ll pass along the suggestion about being able to dismiss other types of notifications as well.

Ben

a.jaffe

@Ben,

This might not be the right place for this, but I really don’t like needing the 2FA tag to get rid of the banner (not least since I already use that tag for sites which do use 2FA!).

But I do like the idea of being able to (stickily) dismiss/shrink the banner on a per entry basis.

A

Ben

Thanks for the feedback, @a.jaffe.

Ben

[Deleted User]

To add to what was already mentioned here, I'd like to be able to "ignore" certain banners. I really do like the fact that they exist, but sometimes there is just nothing I can do about it.

I'm not using a long password because the site has a stupid 8 char limit. And in another instance, I'm using a duplicate password because it's the same credentials, just on another site.

To add even further to that last bit, it would be great if I could manually save different login fields (on different domains), that all share a password as one item. For instance, I have one site that asks for
username: whiteblade
password: psswd
id: 12345

another site that asks for
username: whiteblade@domain.com
password: psswd

and yet another site that asks for the same info as the first one but the id field is named differently so 1Password won't fill it. However, not only when I change the password does it change across all these sites at once, but they are logically one login in my head (since they are my credentials for a single org).

Ben

Thanks @whiteblade. I don’t have any specifics to share but better handling of logins that are applicable across multiple sites within a domain is definitely something I too would like to see improved. Hopefully that is something we can address in the future.

Ben

JayTay

What I'd really like is for some kind of mass-update option. I have over 100 sites listed in the Unsecured list and I'm pretty certain the majority are https compatible but I just haven't updated the URL from when I first saved the password years ago. I'd happily just select all > update URL to https if that were an optional editing them one by one is really annoying, especially due to the aforementioned dropping back to the main list each time.

Ben

Thanks for the feedback, @JayTay. Personally I'd feel a little hesitant to do that, as it may break some sites that do not support https. May be something we can consider, though.

Ben

JayTay

Yeah, I can see your point however I would hope that the http only sites would be in the minority so could easily be changed back as and when I encountered them - I've just tried a random few from my list and they are all redirecting to https versions now.

Ben

Certainly we'd hope that HTTP traffic would be the minority.

Ben

mirv

I find that just keeping the bare domain name (eg. "adobe.com") in the website field works fine. I've been doing this instead of just adding an "s" to the "http". (I also usually remove the subdomain info, as that is quite often stale and doesn't work any more.) Is there any disadvantage to this?

Mr. K.

mirv, That is a great idea, and it works well.

invalidptr

I would like to +1 what @JayTay has said... bulk convert everything to https. I hate the house cleaning task (and I want a clean house!) - I have over 250 that need fixed up! And the off chance it's broke I'd rather fix it then. I wonder how many don't work today but will work when I finally use them again. We'll call it the Schrödinger's Website.

AGAlumB

@invalidptr: :lol: :+1:

I find that just keeping the bare domain name (eg. "adobe.com") in the website field works fine. I've been doing this instead of just adding an "s" to the "http". (I also usually remove the subdomain info, as that is quite often stale and doesn't work any more.) Is there any disadvantage to this?

@mirv: There's nothing wrong with that approach, and I think it looks nice...but I find I save a TON of time in aggregate by having the direct URL to the page I usually visit anyway. For some sites, that's the login page. For others, it's for account information, a common product search, etc. Saves me a lot of clicking around. :)

EnerJi

I find that just keeping the bare domain name (eg. "adobe.com") in the website field works fine. I've been doing this instead of just adding an "s" to the "http". (I also usually remove the subdomain info, as that is quite often stale and doesn't work any more.) Is there any disadvantage to this?

@mirv @Mr. K.
cc:@brenty

There is a historical security downside to this, although the relatively recent widespread adoption of HTTP Strict Transport Security (HSTS) mitigates it to an extent.

Absent HSTS, when you first attempt to go to http://site.com (which is what happens if you don't add https), a malicious actor could secretly redirect you to https://s|te.com and then steal your password and even a two-factor code for that site.

This is one of the reasons I still run the EFF's HTTPS Everywhere Chrome extension. The Chromium Project has a short but sweet explanation of HSTS which also outlines some scenarios where it may not provide protection here:
https://www.chromium.org/hsts

mirv

About subdomains, I tend to get URLs like this saved in my 1Password entries:

https://accessmygov.com/Account/Register?uid=xxx

so it seems best to just delete all the subdomain info since I never would want to register on that site again.

About the https:// prefix, good idea to use HTTPS Everywhere. I thought that Safari does try to use https but I don't seem to be able to find the info about that right now. Would it be best to have a 1Password function that edits every single URL to have an https:// prefix, rather than an individual button for each entry?

AGAlumB

@EnerJi: When no protocol is specified, the URL should open in the browser as HTTPS. So I think it would still be better to use just example.com rather than http://example.com

AGAlumB

@mirv: That's a really good point. I guess I wasn't specific about that: it's not only useful to specify a page you want to go to, but also to avoid a page you don't want to go to — like account registration.

And indeed, if you don't specify the protocol in the browser, it will default to HTTPS. We also get that "for free" in most cases just by using the platform APIs. But as I mentioned above to EnerJi, you'll get the same behaviour by using a "naked domain" in 1Password too. Cheers! :)

EnerJi

@brenty

When no protocol is specified, the URL should open in the browser as HTTPS. So I think it would still be better to use just example.com rather than http://example.com

Good to know! I should have expected that 1Password would do the smarter thing and attempt to open the site as https:// by default. Thus, my advice above only applies to anyone navigating to a website manually.

AGAlumB

Sounds good! :) :+1: