Extensions shouldn't get access to topsites.services.mozilla.com
Categories
(WebExtensions :: Request Handling, enhancement)
Tracking
(Not tracked)
People
(Reporter: mikedeboer, Assigned: mikedeboer)
References
Details
Currently WebExtensions can attach content scripts to topsites.services.mozilla.com and listen to traffic using the webRequest API. That means an extension could intercept your user name and password for that site.
We should add this domain to the extensions.webextensions.restrictedDomains
pref.
Assignee | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•4 years ago
|
||
How is that different from any other website that has a login form?
I don't think we should add more sites to that pref. Data can be retrieved using other ways, and legitimate add-ons (like password managers) don't work, which is an inconvenience for user that can also impact their safety, if they have to type/fill credentials manually.
Assignee | ||
Comment 3•4 years ago
|
||
topsites.services.mozilla.com is a service internal to Mozilla that is essential in making sure we monetize clicks on sponsored Top Site tiles and sponsored searches.
Anything we allow to tamper with these request will have an impact on our revenue.
Comment 4•4 years ago
|
||
I don't think that warrants a blank ban of that domain for webextensions. Domains like google.com also affect our revenue and we don't restrict those either.
Are there any add-ons that tamper with requests to the topsites domain? We should evaluate them and see what their use case is. We could also look into flagging add-ons for review that request access to that domain.
Comment 5•4 years ago
•
|
||
It is not exactly clear from this bug what topsites
is, and how it functions with regards to usernames, passwords and cookies.
(In reply to Mike de Boer [:mikedeboer] from comment #0)
That means an extension could intercept your user name and password for that site.
Who is expected to have a username/password on this website? Is this a significant portion of our users?
Comment 6•4 years ago
|
||
Clearing priority because we never saw this bug in our triage.
Comment 7•4 years ago
|
||
Why isn't this just a system request? I only see XHR/Fetch requests in JSM files, I don't understand how a content script could be attached to those requests. This needs more information.
Assignee | ||
Comment 8•4 years ago
|
||
Yeah, I think we can resolve this as invalid, since we can turn this into a system request.
Description
•