Closed Bug 1412627 Opened 8 years ago Closed 6 years ago

Privacy & Security > Accept Cookies > Exceptions... dialog's protocol separation is silly and a UX problem

Categories

(Firefox :: Settings UI, defect, P5)

Product:
Firefox
Component:
Settings UI
Version:
58 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1442179
Tracking Flags:
Tracking Status
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- ?

People

(Reporter: u580221, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20171028100423 Steps to reproduce: Privacy & Security > Accept Cookies > Exceptions... dialog's protocol separation is silly and a major UX problem with this dialog. Consider the following: 1. Click Privacy & Security 2. Click "Use custom settings for History" 3. Enable "Accept cookies for Websites" 4. Click "Exceptions" for "Accept cookies for Websites" 5. Enter "google.com" into the input field and press "Block" 6. Press "Save Changes" 7. Visit https://google.com Actual results: The cookies are NOT blocked. The reason appears to be that this dialog somehow has the super limited notion that the host I entered without a protocol must somehow imply a specific protocol, and that the protocol is supposedly HTTP. Nowadays that so many sites finally support and enforce proper HTTPS, this makes the dialog have a 70% chance that it doesn't actually do what the user implied, which is extremely annoying and for newcomer users also confusing. What the dialog actually should do is allow ://google.com entries similar to links in a site, and entering a host without protocol should generate such an entry. This would still allow people to enter a protocol distinction when necessary, and fix this issue of nonsensically defaulting to HTTP only entries. Expected results: Obvious, google.com cookies should have been blocked. (who ever spoke of HTTP? the dialog invented that for me, I never entered it into the input field.)
Even for people like me who are aware of this limitation, there is no non-annoying workaround: since most sites still use both HTTP and HTTPS in some parts, what you apparently need to do to make it work reliably is to enter every host TWICE with both protocols, which is super annoying and a big time waster.
Component: Untriaged → Preferences
I agree that we could make this better. I see a use for people wanting to block cookies from http:// but are OK with cookies being stored/transferred over https:// This won't be fixed for 57 and is unlikely to be fixed for 58 since it would require a new UX design.
Status: UNCONFIRMED → NEW
status-firefox56: --- → wontfix
status-firefox57: --- → wontfix
status-firefox58: --- → fix-optional
Ever confirmed: true
Keywords: dupeme
Priority: -- → P5
Well the current design is bad, so a new UX design sounds like a good idea to me.

I think this issue is now worse than when it was logged - both because https adoption increases and because Mozilla/Firefox is marketed as the privacy browser. The result of this is that the Cookies "Manage Permissions..." feature is sadly broken/useless for many users who would never think to type "https://" before the site name.

I decided to finally switch to blocking all cookies yesterday and then spent a couple of hours trying to figure out why my exceptions were not working. More than 95% of my exceptions need to be https and I did not notice that it was defaulting to http. I would not have thought to try typing https until I stumbled across a help article. (My only http exception is my own test Django page where I have not set up https.)

One mitigation would be to populate both http and https entries when a user does not specify. For a user who only wanted one and does NOT want the other, it is a lot less work to delete the unwanted one. For a user who only wants one and does not care about the other (most of us), this would add no work for the user.

(In reply to nullspace from comment #6)

One mitigation would be to populate both http and https entries when a user does not specify. For a user who only wanted one and does NOT want the other, it is a lot less work to delete the unwanted one. For a user who only wants one and does not care about the other (most of us), this would add no work for the user.

We did this in bug 1442179 and I think it's safe to dupe this.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.