Closed Bug 1475832 Opened 6 years ago Closed 4 years ago

WebExtension - WebRequest: it should be possible to cancel or redirect data-URL requests

Categories

(WebExtensions :: Request Handling, defect, P3)

Product:
WebExtensions
Component:
Request Handling
Version:
61 Branch
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

Details

Attachments

(1 file)

blocking-data-url-1.0.zip
(deleted), application/zip
Details
Attached file blocking-data-url-1.0.zip (deleted) —
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180705213349 Steps to reproduce: When using browser.webRequest.onBeforeRequest with blocking it should be possible to cancel or redirect data-URLs. There is even a "FIXME" comment in the webRequest-Code with this issue... https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/addons/WebRequest.jsm#250 Reproduction scenario: - install the provided webExtension temporarily - go to https://itty.bitty.site/#/data:text/html;base64,PGh0bWw+PGJvZHk+PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLm9yZyI+Y2xpY2s8L2E+PC9ib2R5 PjwvaHRtbD4= Actual results: The browser console shows that the webExtension found a data-URL and tried to redirect it. But the iFrame displays the data-URLs content and not example.org. Expected results: The data-URL content is shown.
Flags: needinfo?(mixedpuppy)
This doesn't work because synchronous handling of non-http* requests was removed (necessarily). We'll probably need a larger effort at rewrite of webrequestcontent and possibly various channels/etc. to make this possible. So while we should do something here, it's potentially a larger project.
Flags: needinfo?(mixedpuppy)
Priority: -- → P5
Priority: P5 → P3

I ran into this issue, struggled with it, and updated the documentation to reflect the current limitations on non-HTTP(S) protocols on the webRequest MDN page.

Is there currently any kind of workaround available to modify the request in any way? I make an extension that blocks NSFW images and right now my working but highly unfortunate alternative is to intercept and scan text/html via regex for base64 image URLs.

Flags: needinfo?(mixedpuppy)

webRequest is tightly bound to http channels, other protocols just don't work the same. The only alternative I can think of off the top of my head is to use a content script to detect images using data urls.

Flags: needinfo?(mixedpuppy)

I was just doing a bit of backlog management today and remembered this issue, so figured I would link it here. Tracking this bug in my project due to this limitation: https://github.com/wingman-jr-addon/wingman_jr/issues/18

Depends on: 1631933

Should this bug be closed?
Because the feature to observe data urls has been removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1631933

Flags: needinfo?(rob)

I'll wait until bug 1631933 reached the release channel. If there is zero interest in data:-URLs, then we can close this bug.

Otherwise we can convert this to an open feature request.

Flags: needinfo?(rob)

There is interest in data-URLs. I have to use CSP headers in CanvasBlocker to prevent fingerprinting over these (https://github.com/kkapsner/CanvasBlocker/issues/208) which causes several other problems (e.g. https://github.com/kkapsner/CanvasBlocker/issues/214) directly blocking would be much better.

Better for this issue would be if https://bugzilla.mozilla.org/show_bug.cgi?id=1475831 would be fixed though...

(In reply to kkapsner from comment #7)

Better for this issue would be if https://bugzilla.mozilla.org/show_bug.cgi?id=1475831 would be fixed though...

Definitely... The network level (data:-URLs) is not the right place for your use case. Extensions should be able to run content script in any web page that extensions can load. That's not just data:, but also blob: and sandboxed origins. It's a pet peeve of mine but I haven't got to fix it yet.

Closing bug since data:-URLs are not supported, and there hasn't been a compelling reason to support it again (in particular hardly anyone noticed that the feature disappeared). I've removed the notice from the webRequest docs at https://github.com/mdn/content/pull/5150

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: