Closed Bug 1279371 Opened 8 years ago Closed 8 years ago

chrome.webRequest events have not occur with service request, but it is not documented

Categories

(Developer Documentation Graveyard :: Add-ons, defect)

Product:
Developer Documentation Graveyard
Component:
Add-ons
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fdsc, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Steps to reproduce:

Check update for firefox or addons with chrome.webRequest.onBeforeRequest.addListener(...)


Actual results:

No events


Expected results:

Events must occur (and tabId must be specified in documentation)
Blocks: webRequest-full
I don't quite understand what you're saying.

Are you asking for requests associated with add-on update pings and downloads to be reported to webRequest listeners?
No. All service requests (OCSP for example). As well as "http-on-opening-request" event.
Sorry, I still don't understand.

We almost certainly aren't going to allow access to OCSP requests. Beyond that, I'm not sure what you want.
I want WebRequest fulfilled the all requests as well as "http-on-opening-request" event. You want all extensions could be ported to WebExtensions. And requests through the WebRequest are not all.
This applies to all requests that do not belong to the tab. For example, requests from extensions too, apparently, will not be visible in the WebRequest.

In general, extensions should be able to block the all requests to ensure privacy. In particular, requests for updates and OCSP.
For example, when a user works through TOR and he doesn't need any, even the most necessary, extraneous requests.
Now, in "http-on-opening-request" event I can see OCSP-requests, update requests, addon service requests.
I don't understand why you couldn't see them through WE.
Traditional extensions had access to all requests because they ran with the full privileges of the browser. WebExtensions are designed to be sandboxed. They're not meant to have access to implementation details of the browser, and they're especially not meant to have access to security-sensitive requests such as update checks and OCSP checks.
Then port all of the extensions to WebExtensions is impossible. Although, as I understand the Mozilla statements, such a task is have.
Correct, it won't be possible to port all existing extensions to WebExtensions. Bug 1263011 will help with some of the edge cases, but it won't ever be possible for extensions to do all of the things they can currently do in an environment with absolutely no sandboxing.
Summary: chrome.webRequest events must occur with service request → chrome.webRequest events have not occur with service request, but it is not documented
I think that this is a defect in the documentation for the WebRequest, as it the policy is not clear.
Component: WebExtensions → Developer Tools
Product: Toolkit → Developer Documentation
(In reply to fdsc from comment #4)
> In general, extensions should be able to block the all requests to ensure
> privacy. In particular, requests for updates and OCSP.
> For example, when a user works through TOR and he doesn't need any, even the
> most necessary, extraneous requests.

If privacy is a concern, extensions probably aren't the best solution. There's a reason the TOR browser is more of a fork than an extension - it's so it can make more intrusive changes to the platform. Blocking the update ping is definitely not something an extension should be able to do. Blocking OCSP is less of an issue, but if a user really wants to do this, they can use the checkbox in Preferences -> Advanced -> Certificates. (And in any case it sounds like this is more of a documentation issue.)
> they can use the checkbox in Preferences -> Advanced -> Certificates.

I don't think it's good. The user should have the option of using a extensions to restrict the all queries. And it should be easy. It should not change dozens of settings, or even several, to do it. But if he doesn't know any of the settings? The user may not even know about the existence of OCSP, but with an add-on to block it (and then have to figure out why nothing works).

As for Tor, the user should have a choice what to use. I prefer to use tor and FireFox with add-ons, than the Tor-browser.



Generally speaking, this behavior is not terrible.
The problem is that Mozilla want to leave to only WebExtensions, and that means that the addons will no longer be able to do what they are doing now. And that's too bad.

Seems as though someone wants to eliminate opportunities for writing add-ons with strong functionality.
Closing, based on the comments here that this is intended behaviour of webRequest.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
The comments indicated that the defect in the documentation. The title of the defect also testify to this.
I don't see a reason why this defect has been closed.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Component: Developer Tools → Add-ons
See Also: → 1301143
Note added to the MDN docs.

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest$compare?locale=en-US&to=1123045&from=1088315
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Typo: "OSCP checks"
See Also: → 1330124
From Bug 1330590
> The fact of the matter is that access to internal browser requests is incompatible with the WebExtension sandboxing model. There are things that legacy add-ons that require access to Firefox internals could do that will never be possible in WebExtensions.

It is the incompatibility of policy or technical incompatibility?
Do not succeed to change sanboxing that undoes this sandboxing if the extensions configured for it?


> If you need to continue doing them for some specific reason, you'll have to fall back to unsigned add-ons on a developer build, or system-level security software.

It makes FireFox unusable for the operation of extensions that blocks all requests unless specifically allowed in the whitelist. That may be important for privacy.

I think it's very important to solve this problem. Besides, some of the faults I use the requests lookup for updates and OCSP to determine the error.


I have the feel that Mozilla does not understand the importance of full access add-on to FireFox requests.
Flags: needinfo?(kmaglione+bmo)
It will be solved? To me it is important to know because without this bug I am not even going to attempt to rewrite my extension to WebExtensions.

Will be taken some reasonable solution for the permissions or I shouldn't waste time to learning WebExtensions?
I agree with Kris and David, this is incompatible with idea of WebExtensions.
It seems that the WebExtensions idea contrary to the idea of extensibility of the browser.
The WebExtensions functionality are lack.
Flags: needinfo?(kmaglione+bmo)
> this is incompatible with idea of WebExtensions.

By the way, I understand that there is no technical problem to implement the idea proposed by me in Bug 1330590 . WebRequests implemented using the same observers and everything else in FireFox.

It is only the desire of FireFox developers quit Firefox to make it impossible to control privacy of FireFox by add-ons.
I don't see any conceptual problems associated with the introduction of the permission for individual add-ons that need it.
In fact, there's only one explanation. Developers want to violate the FireFox privacy and to make it impossible the uncontrolled use of standard build. Quite a strange desire.
Flags: needinfo?(amckay)
Flags: needinfo?(amckay)
Should this bug be reopened? The behaviour of webRequest API is not well documented. The added documentation as a fix for this bug is vague in its current form in the API documentation. There is no common definition of a "sensitive" request. All the "sensitive" requests (hosts, types) should be listed in the API documentation.

Further, the behaviour of the webRequest API is misleading. The API should throw an exception for requests for which it doesn't grant access to. Currently the API accepts the webRequest.BlockingResponse silently but the action of it may be ignored for some "sensitive" requests unknown to the user of the API.
Hi, just bumped into this issue.

In document(In reply to Kris Maglione [:kmag] from comment #6)
> Traditional extensions had access to all requests because they ran with the
> full privileges of the browser. WebExtensions are designed to be sandboxed.
> They're not meant to have access to implementation details of the browser,
> and they're especially not meant to have access to security-sensitive
> requests such as update checks and OCSP checks.

Just trying to search anything in the address bar or search field near produces requests to 'https://www.google.com', 'https://safebrowsing-cache.google.com' and 'clients1.google.com' that do not fire webRequest events.

Do they really belong to update or OCSP checks requests?
At the same time we are able to set PAC script that will affect all requests in the browser (including update or OCSP checks requests and the ones mentioned above) and can just block them.

Is this intended behavior either?
You need to log in before you can comment on or make changes to this bug.