Open Bug 1246096 Opened 7 years ago Updated 2 years ago

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

Categories

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

defect

Tracking

()

Tracking Status
firefox44 --- affected
firefox45 --- affected
firefox46 --- affected
firefox47 --- affected
firefox-esr38 --- unaffected

People

(Reporter: magicp.jp, Unassigned)

References

Details

(Whiteboard: [necko-backlog])

Attachments

(1 file)

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)
Has STR: --- → yes
Component: Untriaged → Networking: Cookies
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
According to bug 1210379 comment 8 this blocking should continue to work with the http:// prefix. Does this avoid the problem?
(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?
Does it work, however?
(In reply to Josh Matthews [:jdm] from comment #3)
> Does it work, however?

Unfortunately I cannot make out what you means.
Do cookies get blocked as expected if the http:// prefix is used?
(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.
Is this something you could look into? This seems like unintentional fallout from the permission manager changes.
Flags: needinfo?(michael)
(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
(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)
(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?
(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.
(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]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
See Also: → 1576799
You need to log in before you can comment on or make changes to this bug.