Forum Discussion
Cookie blocking in Edge canary does not work
MissyQ No change at all. I'm now on Version 81.0.363.0 (Official build) canary (64-bit). Here is an entry under Block on edge://settings/content/cookies
And from edge://settings/siteData
You can see it fails blocking the host named in settings directly and subdomains.
In regard to subdomains, I believe the UI strongly implies that all subdomains of a named domain are covered by the setting. Here is why. This is the Add dialog.
Note the wildcard in front of the name. As is, this is ambiguous and could indicate either that a wildcard is permitted or that one is implied. Now, here is the UI when you enter the example
You can see that the wildcard is rejected. I just found that the value is accepted with the brackets as shown below.
I thought I had tried this long ago and it too failed. I don't know if that was changed or I entered it wrong. I will try this but it is a side issue. The clear evidence that entering "findagrave.com" and cookies for "findagrave.com" not being blocked is an obvious failure. The question of why "http://www.findagrave.com" is not blocked depends on how this undocumented feature is expected to work. It is not documented anywhere that I can find nor is there explanatory text in the UI.
rshupak Happy new year! Sorry I did not respond to your follow up earlier. Holidays can cause some craziness here.
I did receive some more info about ways to add websites to it. It's not the most intuitive thing, and I've relayed that feedback to the team so they are aware this isn't the greatest. Aside from adding in the website using the [*.], you can also add websites using the site permissions settings.
Click the lock icon up in your URL and select Cookies:
Click on the domain name you want (the example here is microsoft.com), and then click Block.
Refresh the page, and go back to the Cookies settings and click the Blocked tab at the top.
To clear on exit for that specific site, click it and then click Clear Upon Exit. It should show up in your Settings > Site permissions > Cookies and site data under the clear on exit portion now.
Again, not entirely intuitive, but the team knows that. Hopefully this will help you out in the interim! 🙂
Missy Quarry (she/her/hers)
Community Manager - Microsoft Edge
MissyQ This is just another entry point to the existing UI. The root bug still exists. This UI is also interesting because it doesn't do what you would think. First, using findagrave.com as an example, I have the following configured in the Block section of edge://settings/content/cookies. This is configured to block this host/domain only and not subdomains, i.e. it lacks the [*.] prefix.
I now visit I and click on the lock icon to see what cookies were set. Note that it ignores the Block setting and accept cookies anyway.
Now for the unexpected, and I believe broken, functionality. If I select http://www.findagrave.com in this dialog then click on block, the following is what gets added. It is curious that it includes subdomains by default when the UI in edge://settings/content/cookies does not. If this behavior is sufficient expected to be the intent that this UI uses it by default, maybe the UI in edge://settings/content/cookies should direct users to this. The broken behavior is that it restricted the block to HTTPS only. I have no reason to expect it to allow cookies over HTTP. It's also curious because the example text in the UI on edge://settings/content/cookies gives no indication that a URL scheme is allowed.
Another indication that this is a bug is the behavior when I click on findagrave.com, without the www. subdomain prefix, then the block button, the following is added to the block list on edge://settings/content/cookies. Note that this lacks the HTTPS prefix
In summary, the problems are
- the existing block entry for findagrave.com is not honored
- Blocking http://www.findagrave.com adds an HTTPS scheme excluding HTTP
- The domain and subdomains are blocked by the addition of the [*.] prefix which is not indicated in the UI and the user is not informed that the block has larger scope than requested
In regard to the latter, one more flaw. If I remove all the entries for this domain from the block list and visit again, I then selected the findagrave.com entry (without www prefix) first then the Block button. Note that the label "Blocked" was added. It is almost invisible which is a UI flaw but not the issue I am noting. Because the block entry added is for [*.]findagrave.com, it also blocks http://www.findagrave.com which is not labeled as blocked.