1246096 - In case of blocking cookies from website in the exceptions, should not be added "http://" automatically

Status: RESOLVED WORKSFORME

(Core :: Networking: Cookies, defect, P3)

Description

[magicp]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160204030229

Steps to reproduce:

1. Start Firefox 42.0 and later version
2. Open "about:preferences#privacy"
3. Switch to "Use custom settings for history"
4. Click "Exceptions..." button
5. Enter "google.com"
6. Click "Block" button


Actual results:

The website address entered is added "http://" automatically. Therefore this setting cannot block the following cookies...

google.com
accounts.google.com
doc.google.com
etc...



Expected results:

In case of blocking cookies from website in the exceptions, should not be added "http://" automatically. The blocking should block cookies widely for secure and privacy. (In another case of to allow cookies, should narrow)

Comment 1

[Josh Matthews [:jdm]]

According to bug 1210379 comment 8 this blocking should continue to work with the http:// prefix. Does this avoid the problem?

Comment 2

[magicp]

(In reply to Josh Matthews [:jdm] from comment #1)
> According to bug 1210379 comment 8 this blocking should continue to work
> with the http:// prefix. Does this avoid the problem?

I cannot understand http prefix needs for cookie blocking because cookies' domain does not have http prefix. How about pros cons?

Comment 3

[Josh Matthews [:jdm]]

Does it work, however?

Comment 4

[magicp]

(In reply to Josh Matthews [:jdm] from comment #3)
> Does it work, however?

Unfortunately I cannot make out what you means.

Comment 5

[Josh Matthews [:jdm]]

Do cookies get blocked as expected if the http:// prefix is used?

Comment 6

[magicp]

Attachment: Bug1246096-test-case-fx41-vs-fx44.png

(In reply to Josh Matthews [:jdm] from comment #5)
> Do cookies get blocked as expected if the http:// prefix is used?

Please find attached test case.

Comment 7

[Josh Matthews [:jdm]]

Is this something you could look into? This seems like unintentional fallout from the permission manager changes.

Comment 8

[magicp]

(In reply to Josh Matthews [:jdm] from comment #7)
> Is this something you could look into? This seems like unintentional fallout
> from the permission manager changes.

bug 1210379 comment 1

Comment 9

[Nika Layzell [:nika] (ni? for response)]

(In reply to Josh Matthews [:jdm] from comment #7)
> Is this something you could look into? This seems like unintentional fallout
> from the permission manager changes.

The problem in this case appears to be that the permissions in the new case are set with the `www.` prefix. If that was done in the old model, the same effect will occur. Try adding permissions for `https://google.com` and `http://google.com` instead.

www. acting different than the base domain is intended, and occurred before the update.

Comment 10

[magicp]

(In reply to Michael Layzell [:mystor] from comment #9)
> The problem in this case appears to be that the permissions in the new case
> are set with the `www.` prefix. If that was done in the old model, the same
> effect will occur. Try adding permissions for `https://google.com` and
> `http://google.com` instead.

I tried it. Certainly, it seems working as "http(s)://*.google.com". It's a tentative solution?

Comment 11

[Nika Layzell [:nika] (ni? for response)]

(In reply to magicp from comment #10)
> (In reply to Michael Layzell [:mystor] from comment #9)
> > The problem in this case appears to be that the permissions in the new case
> > are set with the `www.` prefix. If that was done in the old model, the same
> > effect will occur. Try adding permissions for `https://google.com` and
> > `http://google.com` instead.
> 
> I tried it. Certainly, it seems working as "http(s)://*.google.com". It's a
> tentative solution?

Try just http(s)://google.com - I don't think we intend to allow http(s)://www.google.com to apply to http(s)://maps.google.com etc., as they are different subdomains, and thus can have separate permissions.

Comment 12

[magicp]

(In reply to Michael Layzell [:mystor] from comment #11)

http(s) is not my request. just writing for short word. sorry for confusing.

Comment 13

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 14

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 15

[edgul]

The title of this bug seems a bit misleading and that the feature request is actually for eTLD+1 cookie blocking to also apply to it's subdomains. Comment 11 seems to indicate we have no intention of adding such a feature. So I think we can close this?

pbz, thoughts?

Comment 16

[Paul Zühlcke [:pbz]]

While including the scheme may be a bit misleading from a UX perspective, we do apply cookie permissions for the entire domain. So if you add a cookie block permissions for "example.com" "foo.example.com" won't be able to set cookies either. If you add a (more specific) cookie block permissions for e.g. "bar.example.com" both "example.com" and "foo.example.com" can still set cookies.