All users were logged out of Bugzilla on October 13th, 2018

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

NEW
Unassigned

Status

()

P3
normal
3 years ago
a year ago

People

(Reporter: magicp.jp, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox44 affected, firefox45 affected, firefox46 affected, firefox47 affected, firefox-esr38 unaffected)

Details

(Whiteboard: [necko-backlog])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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)
(Reporter)

Updated

3 years ago
Has STR: --- → yes
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox-esr38: --- → unaffected
Component: Untriaged → Networking: Cookies
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All

Comment 1

3 years ago
According to bug 1210379 comment 8 this blocking should continue to work with the http:// prefix. Does this avoid the problem?
(Reporter)

Comment 2

3 years ago
(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

3 years ago
Does it work, however?
(Reporter)

Comment 4

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

Unfortunately I cannot make out what you means.

Comment 5

3 years ago
Do cookies get blocked as expected if the http:// prefix is used?
(Reporter)

Comment 6

3 years ago
Created attachment 8716553 [details]
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

3 years ago
Is this something you could look into? This seems like unintentional fallout from the permission manager changes.
Flags: needinfo?(michael)
(Reporter)

Comment 8

3 years ago
(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

3 years ago
(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.
Flags: needinfo?(michael)
(Reporter)

Comment 10

3 years ago
(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

3 years ago
(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.
(Reporter)

Comment 12

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

http(s) is not my request. just writing for short word. sorry for confusing.
Whiteboard: [necko-backlog]
You need to log in before you can comment on or make changes to this bug.