EFForg / privacybadger

Privacy Badger is a browser extension that automatically learns to block invisible trackers.
https://privacybadger.org
Other
3.19k stars 386 forks source link

portal.azure.com is broken in certain conditions #2975

Closed walliski closed 5 months ago

walliski commented 5 months ago

What is your browser and browser version?

Google Chrome Version 125.0.6422.142 (Official Build) (64-bit)

What is broken and where?

We have a GPO that disables Privacy badger for portal.azure.com, due to earlier issues with the page.

In special cases though, it can break when following links to the page:

  1. Go to https://azure.status.microsoft/en-us/status
  2. Click the "Go to Azure Service Health" button
  3. portal.azure.com should load, but it shows a ERR_FAILED error page in Chrome instead

Checking Privacy Badger, it says that its disabled for the site. However, going into Privacy Badger settings, and "Tracking Domains", the "portal.azure.com" URL is set to Red. Switching it to green here, makes the above procedure load the Azure Portal as normal.

What is the "culprit" domain?

Please follow the debug instructions to identify which domain breaks stuff when blocked: https://github.com/EFForg/privacybadger/wiki/Find-out-why-Privacy-Badger-is-blocking-a-domain

I could not follow those, as Privacy Badger just says its disabled for the site.

What is your debug output for this domain?

To get the debug output, please see the instructions link above.

I tried to follow the instructions above, but the Privacy Badger extension only has a "Service worker" in the inspect views. It does not allow me to run the JS in the instructions due to that, as Chrome says some method is not allowed for Service Workers?

Let me know if you need more information.

image image image

ghostwords commented 5 months ago

Hello and thanks for opening a thorough bug report!

Looks like our debug instructions for Chrome are broken at the moment, something for us to fix. But I don't think we need to know where PB learned to block portal.azure.com for this particular issue, so it's OK to not have the debug info.

Is there a way for me to reproduce the problem without having an Azure account? Clicking on "Go to Azure Service Health" prompts me to log in.

ghostwords commented 5 months ago

We might work around this issue by adding portal.azure.com to Privacy Badger's "yellowlist", which is a list of domains that are allowed to load albeit without access to cookies.

What I don't understand is why Privacy Badger blocks what appears to be the top-level document of a portal.azure.com website. PB should only ever block requests to "third-party" domains; that is, domains unrelated to the domain of the website that you are on. If you choose to visit portal.azure.com, it should never get blocked.

Does this happen if you visit https://portal.azure.com/#blade/Microsoft_Azure_Health/AzureHealthBrowseBlade directly, instead of clicking the "Go to Azure Service Health" button?

ghostwords commented 5 months ago

Also, can you reproduce the problem if you install this previous version of Privacy Badger in a new profile? If you don't make a new profile, please make sure to temporarily disable your other content blockers for the test.

walliski commented 5 months ago

Tried new profile, with the official version, to have clear reproduce steps:

  1. Create new profile in Chrome
  2. Install Privacy Badger only (checked that nothing else is installed at this point)
    • Checked that portal.azure.com is in the disabled sites list (as it comes through gpo)
    • Checked that portal.azure.com does not show up in the tracking domains list
  3. Go to https://azure.status.microsoft/en-us/status, click the "Go to Azure Service Health" button
  4. It works this time, and I get redirected to Microsoft login page.
  5. Log in to the Azure Portal.
  6. Go back to the status page, click button again.
  7. The Azure Portal no longer loads, and shows the error.

I tried doing the same list, with manually installing the old version you linked (and adding portal.azure.com to the disabled list, as its then not from GPO anymore), and its still the same result.

I cannot recall exactly when the first time we saw this issue was - it was only noticed by one person at first - but now we are having links to the portal from other places (our own internal tools), and those are also broken in the same way for multiple users. The first time we saw it could have been a month, two or three ago?

Does this happen if you visit https://portal.azure.com/#blade/Microsoft_Azure_Health/AzureHealthBrowseBlade directly, instead of clicking the "Go to Azure Service Health" button?

No, browsing the website directly works without issues. A workaround for this issue is that when it happens, you just click the address bar and "Enter" - the page will load correctly.

EDIT: Woop, seems like I missed one of your messages.

Is there a way for me to reproduce the problem without having an Azure account? Clicking on "Go to Azure Service Health" prompts me to log in.

It does indeed seem like one has to sign in to the portal to be able to reproduce it.

EDIT 2: I also tried some older version from Github, which show the same issue:

ghostwords commented 5 months ago

Thank you for debugging! It sounds like this is not a new or a Manifest V3-specific issue.

ghostwords commented 5 months ago

This is another website service worker-related bug in Chrome. When the https://portal.azure.com/ service worker tries to fetch the portal.azure.com document, Privacy Badger thinks we're on https://azure.status.microsoft/en-us/status and something there issued a service worker request to https://portal.azure.com/#blade/Microsoft_Azure_Health/AzureHealthBrowseBlade. There is no way to tell that this is a top-level navigation, as far as I see.

Related: #1997, #2859

ghostwords commented 5 months ago

We can work around this particular issue by telling Privacy Badger that status.microsoft belongs to the same entity as azure.com.

ghostwords commented 5 months ago

We have a GPO that disables Privacy badger for portal.azure.com, due to earlier issues with the page.

By the way, do you know if this is still necessary? If there are still issues, I would like to fix them for all Privacy Badger users.

walliski commented 5 months ago

We can work around this particular issue by telling Privacy Badger that status.microsoft belongs to the same entity as azure.com.

If I understood, this would then fix the case used for repro in this issue.

As mentioned somewhere in my posts, the issue also happens on links to the portal from internal homemade tools that we have. Is there some way then I can make these work, or will there be some better fix from your side at some point?

We have Privacy Badger turned off already on the internal page that has the link to the portal on it, and portal.azure.com is disabled, but still seeing the same issue with links from the internal tools.

By the way, do you know if this is still necessary? If there are still issues, I would like to fix them for all Privacy Badger users.

No idea to be honest. We saw issues with it at some point, and just asked IT to push it on the block list to avoid annoyances for everyone. Cannot remember even when this was, could have been a looong time ago.

ghostwords commented 5 months ago

As mentioned somewhere in my posts, the issue also happens on links to the portal from internal homemade tools that we have. Is there some way then I can make these work, or will there be some better fix from your side at some point?

Could you update to PB version 2024.6.14 and then check if my workaround fixes these links as well? Thank you!

To force extension updates, visit chrome://extensions, enable "Developer mode" in the upper right, and click the Update button.

walliski commented 5 months ago

With the new version the https://azure.status.microsoft/en-us/status page is fixed, but links in our internal tools to the Azure Portal are still broken.

An index.html is enough to break it:

<html>
<head>
<title>Azure Portal link</title>
</head>
<body>
<a href="https://portal.azure.com">Azure Portal</a>
</body>
</html>