User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171120222519 Steps to reproduce: It's currently impossible for a WebExtension to infer CORS information from webRequest details. Without said information, there's no way for an extension to find out if a redirection is going to succeed. For example, forwarding requests that come from "script" elements with a "crossorigin" attribute to web_accessible_resources, results in fatal CORS exceptions. 1. Compare details from a cross-origin webRequest to those of a regular webRequest. Actual results: There is no way to infer CORS details from any of the differences between both webRequest details objects. Expected results: I had assumed that making the distinction would be trivial. I expected something along the lines of a "crossOrigin" property inside of the webRequest details, when applicable. I could see its value being either "anonymous", or "use-credentials".

Hereby, I'd like to further clarify my initial report. All this is entirely about the various CORS-modes of web requests, which can be set by webpages; either by explicitly creating a request object and setting its credentials property [1], or by defining specific HTML attributes [2]. Extensions can modify requests, but cannot assess if changes will cause issues. Addressing this bug would solve an issue that is currently affecting Decentraleyes. [3] The add-on points CDN-requests to local resources. Since these requests target external services, said extension could use CORS-mode metadata to find out if a redirection attempt would cause any problems. This is needed, as strict CORS-modes block "moz-extension://*" requests. Knowing if a particular redirection should succeed is important. It allows add-ons to ignore problematic requests, and is unlikely to have any unwanted side-effects. More and more websites are starting to implement said policies, so it's becoming an increasingly large problem. Preventing page breakage is keeping Decentraleyes from supporting additional resources. For anyone wondering if it would not be a better idea to exclude requests to web accessible resources from CORS-policies; that's probably not a good idea. I'm convinced that doing so will cause UUID leakage. [4] I believe this proposal, strikes a much better balance between functionality and security. This suffices, and should be generic enough to benefit others. [1] https://developer.mozilla.org/en-US/docs/Web/API/Request/Request [2] https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes [3] https://github.com/Synzvato/decentraleyes/issues/16 [4] https://github.com/ghacksuserjs/ghacks-user.js/issues/227#issuecomment-326682171

This bug renders the Decentraleyes add-on unusable for many users. The current workaround (to whitelist all known sites using crossorigin script attributes) doesn't scale and is too cumbersome for manual whitelisting (which will additionally be too difficult to remove once this bug is fixed, resulting in privacy issues for all manually-whitelisted sites). Since Decentraleyes is a featured add-on, perhaps this warrants P4 with normal priority (if not P3)?

More and more websites use content delivery networks, so the CDN servers become more interesting for hackers to replace existing scripts by malware scripts. Unfortunately only a few websites take care of security using the crossorigin restrictions. Decentraleyes is afaik the only option to ensure that CDN scripts have not been changed. But the more people are using this featured add-on, the more developers will leave the crossorigin attributes out (or may even remove them) to ensure their website is not broken in Firefox clients. So should the priority not (at least) be normal? With priority P5 this issue is classified as "will never be fixed" or am I wrong? In this case you should remove Decentraleyes from the featured add-ons as you recommend an add-on that breaks valid websites. I'd really regret this...

P5 means that it's on the backlog and we'll accept patches. Currently this is waiting for a design-decision-needed meeting to discuss if this API should be added.

Hi Synzvato, this bug has been added to the agenda for the February 20, 2018 WebExtensions APIs triage. Would you be able to join us? Here’s a quick overview of what to expect at the triage: * We normally spend 5 minutes per bug * The more information in the bug, the better * The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details Relevant Links: * Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting * Meeting agenda: https://docs.google.com/document/d/1-edU5RRFo2TupsOW400AcTOj8yyQnXd0F7uSsqkEzck/edit# * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Hi Caitlin, and thanks for the update, and the additional details. I'm very happy to hear that the proposal will be discussed during the next WebExtensions APIs triage, and I will definitely be attending the meeting.

As more an more stuff is making its way into webrequest, we're starting to have some concern over complexity and potentially performance, so we'll want to think carefully about those. Given that, we feel exposing this information is fine.