Open Bug 1757307 Opened 3 years ago Updated 7 months ago

Give Add-ons the permissions to access navigator.connection (or provide Add-ons API with similar functionality)

Categories

(GeckoView :: Extensions, defect, P3)

Product:
GeckoView
Component:
Extensions
Version:
Firefox 99
Platform:
Unspecified
Android
Type:
defect

Tracking

(Not tracked)

People

(Reporter: Manuel.Spam, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [design-decision-needed])

Since the "fix" for Bug 1637922 landed, "navigator.connection" is undefined not only for websites but also for Add-ons. There are reasons why Add-ons want to know which kind of connection currently is available to do filtering based on this information.

I'm developing a pretty simple Add-on which does this:
https://github.com/M-Reimer/mobilemediablocker
https://addons.mozilla.org/firefox/addon/mobilemediablocker/

The idea of this Add-on is to block all media requests if the connection is of cellular type. This is very useful for most data plans in Germany as we pay a fortune for just a few 100 megabytes of data. If the wifi connection dies for whatever reason and the phone reconnects using the cellular network, then it regularly happened to me that I kept surfing using cellular data without really noticing and ending with no data volume left for the month.

So please either allow the privileged Add-on Javascript to have access to a "non crippled" navigator.connection or add a new WebExtensions API to provide similar functionality.

For now I had to re-enable dom.netinfo.enabled

Blocks: 1755852

Let's ask what Rachel thinks about it?

Flags: needinfo?(rtublitz)

In Firefox 69 we introduced a networkStatus WebExtensions API which is currently only available to extensions signed as privileged (Bug 1550605, introduced for Firefox Private Network).

The networkStatus API reference and permission isn't currently included in MDN doc pages, because the API isn't yet available to third party extensions, but (the API JSONSchema data can be helpful to double-check what level of detail it would provide compared to navigator.connection.

If the networkStatus WebExtensions API as is would fill the gap we should at least follow up with:

  • evaluate if the details provided by this API are sensible enough to require the permission to be listed in the permissions doorhanger at install time
  • lift the privileged signature restriction in Firefox (and confirm if it does require any change also on the addons-linter side)
  • list the permissions on MDN and add API reference doc pages.
  • add the API to the mdn/browser-compat-data metadata github repository

Seems like this part
https://searchfox.org/mozilla-central/source/toolkit/components/extensions/schemas/network_status.json#32
is exactly what I need for my use case of blocking specific "bigger content" on volume limited connection types.

So if it would be possible to lift the restriction so I can use this API, then my problem would be solved.

Flags: needinfo?(rtublitz)

(I was looking at this bug and inadvertently removed my ni? without responding~ :( Fixing that now...)

Luca - thanks for providing a bit of extra context here, and a possible path forward!

So we can make a decision quickly in the event we need to uplift to make FX 99:

Luca/Karl:

  • What is the risk of lifting the privileged signature restriction for networkStatus in Firefox? Do we know who is best suited to answer this question?

Karl:

  • Assuming we move forward here with Luca's suggestion, is your team able to make these changes in Firefox to lift the signature restriction? We are able to provide support for reviews at the moment, however the team is currently working on another major effort that is high priority for this group.

Mike:

  • We may want to assess current usage of navigator.connection here to help assess the impact here related to 1637922 as it rolls out with FX 99. If you agree, can you help coordinate here?
Flags: needinfo?(mconnor)
Flags: needinfo?(lgreco)
Flags: needinfo?(kdubost)

(In reply to Rachel Tublitz [:rachel] from comment #4)

(I was looking at this bug and inadvertently removed my ni? without responding~ :( Fixing that now...)

Luca - thanks for providing a bit of extra context here, and a possible path forward!

So we can make a decision quickly in the event we need to uplift to make FX 99:

Luca/Karl:

  • What is the risk of lifting the privileged signature restriction for networkStatus in Firefox? Do we know who is best suited to answer this question?

Based on what I see in ext-networkStatus.js:

  • the details that the API provides doesn't seem to sensible

  • I'm not sure if the networkID may be unique enough to make it possible to use it for fingerprinting users
    (but to be fair through a combination of all the other API already provided I think that an extension has also many other way to fingerprint users and so I'm not sure that we can consider that an actual concern in the context of the extensions, as we would if it was exposed to the webpages).

  • another "risk" that we may want to consider is about the underlying component used to implement the API (nsINetworkLinkService):

    • exposing the API to all extensions will also mean that, if the team responsible for that component is planning to deprecate it, its removal will need to go through a deprecation plan that takes into account of the third party extensions. For that reason I think we should also ask someone from the "Core :: Networking" bugzilla component to chime in to provide their perspective / thumb up or down on exposing it to third parties.

In addition:

  • I think we should also touch base with Add-ons Ops (e.g. with Andreas) to get an Add-on reviewers perspective about exposing a new API (not because this is that much concerning but more as a good practice in general when we are considering to expose new APIs to all extensions).
  • if everyone is ok to proceeed, both Add-ons Product and Add-ons Ops to help to evaluate if the networkStatus permission should be prompted to the user at install time or not.

Karl:

  • Assuming we move forward here with Luca's suggestion, is your team able to make these changes in Firefox to lift the signature restriction? We are able to provide support for reviews at the moment, however the team is currently working on another major effort that is high priority for this group.

Once we are reached an agreement, the change itself should be pretty straightforward (I think as straightforward as it could be a mentored good first bug, we may also consider to mark it as a good first bug):

There may be some other small other thing that I may be forgetting right now, but there shouldn't be any other complex steps besides what I summarize in the list above.

Flags: needinfo?(lgreco)
Severity: -- → S3
Priority: -- → P3
Whiteboard: [design-decision-needed]

mconnor is going to look into what we should expose for the use case since the existing private api is a reflection of the internal one. The use case is valid, we just want to have a good api for making it public.

(In reply to Rachel Tublitz [:rachel] from comment #4)

Karl:

  • Assuming we move forward here with Luca's suggestion, is your team able to make these changes in Firefox to lift the signature restriction? We are able to provide support for reviews at the moment, however the team is currently working on another major effort that is high priority for this group.

I'm asking dennis and ksenia if they can.
Thanks.

Flags: needinfo?(kdubost)

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(mconnor)
You need to log in before you can comment on or make changes to this bug.