Closed Bug 1590438 Opened 6 years ago Closed 5 years ago

firefox continue request the url 127.0.0.1:9614/sync

Categories

(External Software Affecting Firefox :: Other, defect, P3)

Product:
External Software Affecting Firefox
Component:
Other
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: livehack2019, Unassigned, NeedInfo)

Details

Attachments

(1 file)

firefox.png
214.21 KB, image/png
Details
Attached image firefox.png —

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

Steps to reproduce:

i just capture the request with the burpsuite and i get the firefox contionus send get request to 127.0.0.1/sync

Actual results:

i am unable capture other request they contiounse sending too much request to 127.0.0.1:9614/sync without user knowldge

Expected results:

mozilla firefox not like to send the particarler request as contiouns while i am using the firfox , so that i can able to get the other request on it

Doesn't look like a security bug. Looks like some add-on or whatever doing lookups. Can you reproduce on a clean profile? ( https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles )

Group: firefox-core-security
Flags: needinfo?(livehack2019)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Sync

Doesn't look like sync requests.

Component: Sync → Untriaged

I googled around for the URL and response text and I believe this is caused by the "Xtreme Download Manager" addon, which seems to spawn a local server on port 9614 and has a default list of blocked hosts that match the one in your screenshot.

Also mentioned in this thread on burp suite: https://support.portswigger.net/customer/portal/questions/17286895-trouble-with-configuring-burp-with-firefox that sounds similar to what you're describing.

Andreas, when you're back, can you contact the developer of XDM about this? Thanks.

Component: Untriaged → Other
Flags: needinfo?(awagner)
Product: Firefox → External Software Affecting Firefox

Could anyone provide the ID of the add-on please?
Also, what are we asking of the developer? The add-on might be a companion to a native application and thus might need to make those requests?

Flags: needinfo?(awagner)

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #6)

Could anyone provide the ID of the add-on please?

I'm 99% sure this is https://addons.mozilla.org/en-GB/firefox/addon/xdm-browser-monitor/ . The github repo has '{ab940e94-02b8-4ff5-a53e-3f581e69ec94}' as an ID but I dunno if the AMO version has the same ID or no.

Also, what are we asking of the developer? The add-on might be a companion to a native application and thus might need to make those requests?

It shouldn't need to make the same request several times per second.

Thanks Gijs. The ID you provided is actually an unlisted variant for the listed add-on you mentioned. I reached out to the developer for the unlisted add-on.

Do we usually keep bugs like this open?

Flags: needinfo?(awagner)

The developer replied that they will try to avoid it, but hasn't submitted new versions. What would be the next steps here? Is this issue severe enough to block the add-on?

Flags: needinfo?(awagner)

I don't know who would make that call.

Do we see significant performance impact from that request, or the logic around it?
How often is that request being made?

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #12)

Do we see significant performance impact from that request, or the logic around it?
How often is that request being made?

It's made once per second, so yeah, I think it's safe to say that impacts performance, probably significantly on slower machines, but even on faster machines I'd expect it to uselessly use some CPU and impact other pageloads (on the order of milliseconds, perhaps, but still.)

Thanks Gijs!

We can block add-ons that "cause severe stability and performance issues in Firefox" (https://extensionworkshop.com/documentation/publish/add-ons-blocking-process/#blocking-criteria)

I sent another message to the developer. I am not sure whether the issue qualifies as severe.

Hi Andreas,

This is the developer of the add-on XDM browser monitor.
This add-on is a companion for Xtreme Download Manager desktop application (for more info please visit: https://sourceforge.net/projects/xdman/ and https://github.com/subhra74/xdm). The version mentioned (1.5) does makes requests to the native app on 1 sec interval. However considering http keep alive this should be similar to web socket pings, also XDM native app always runs on background as that's the main requirement for the add-on to use in the first place. If there is no one to listen at localhost:9614 then simply the add-on is of no use. Its necessary for the add-on to be in constant touch with the native app to function properly, thus the frequent pings.
Still I have publish a newer version 2.1 and increased the sync interval to 5 seconds now. In future this http ping will be replaced with web socket or native messaging, but it requires huge changes in the native app, which is not possible at the moment.
Please revert if that's OK, or you feel that this solution is still not enough.

Regards,
Subhra Das Gupta

Increasing the interval to 5 seconds sounds ok to me. You should probably increase the interval gradually if a sequence of pings aren't successful.

Gijs, what do you think?

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to subhradasgupta64 from comment #15)

Hi Andreas,

This is the developer of the add-on XDM browser monitor.
This add-on is a companion for Xtreme Download Manager desktop application (for more info please visit: https://sourceforge.net/projects/xdman/ and https://github.com/subhra74/xdm). The version mentioned (1.5) does makes requests to the native app on 1 sec interval. However considering http keep alive this should be similar to web socket pings,

It's not the same as web socket "considering http keep-alive", because you keep making requests over that http pipeline, so the cpu etc. have to compose the request, other http listeners in the browser run on it, etc. etc.

The old-fashioned solution (ie before web sockets) here would be "long polling" (you can search for this phrase to find longer explanations): the app/server would wait for something close to reliable keep-alive (which used to be just under 60 seconds, but given this is all on localhost you could probably even use 3-5 minutes - experiment!) before responding at all. Then the connection stays open without any further work for client or server/app code, and each request takes a few minutes to complete - unless new data needs passing back to the extension, in which case it can respond sooner. When the server/application responds, the client renews the request after a second or two, and then another 3-ish minutes pass. This means the server can respond immediately when new data needs pushing to the client, but also that you don't need constant messages to verify if there is new data.

also XDM native app always runs on background as that's the main requirement for the add-on to use in the first place. If there is no one to listen at localhost:9614 then simply the add-on is of no use. Its necessary for the add-on to be in constant touch with the native app to function properly, thus the frequent pings.

As Andreas suggested, you should use a back-off - if the app is not running and you thus (presumably) get an error from the request, back off progressively (e.g. if you were making requests after 5 seconds, next do 10, 20, 60, 5 minutes, 10 minutes). Settle on checking every 10 minutes. Perhaps (depending on the usecase of your app/extension) even indicate to the user that the app is not running by displaying a different extension icon. If you're in this "back off" period and the user clicks the icon, you can check immediately at that point.

Still I have publish a newer version 2.1 and increased the sync interval to 5 seconds now. In future this http ping will be replaced with web socket or native messaging, but it requires huge changes in the native app, which is not possible at the moment.

websocket or native messaging would be better, but as noted above I think even right now you could do better still. :-)

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to :Gijs (he/him) from comment #17)

(In reply to subhradasgupta64 from comment #15)

Hi Andreas,

This is the developer of the add-on XDM browser monitor.
This add-on is a companion for Xtreme Download Manager desktop application (for more info please visit: https://sourceforge.net/projects/xdman/ and https://github.com/subhra74/xdm). The version mentioned (1.5) does makes requests to the native app on 1 sec interval. However considering http keep alive this should be similar to web socket pings,

It's not the same as web socket "considering http keep-alive", because you keep making requests over that http pipeline, so the cpu etc. have to compose the request, other http listeners in the browser run on it, etc. etc.

The old-fashioned solution (ie before web sockets) here would be "long polling" (you can search for this phrase to find longer explanations): the app/server would wait for something close to reliable keep-alive (which used to be just under 60 seconds, but given this is all on localhost you could probably even use 3-5 minutes - experiment!) before responding at all. Then the connection stays open without any further work for client or server/app code, and each request takes a few minutes to complete - unless new data needs passing back to the extension, in which case it can respond sooner. When the server/application responds, the client renews the request after a second or two, and then another 3-ish minutes pass. This means the server can respond immediately when new data needs pushing to the client, but also that you don't need constant messages to verify if there is new data.

This is a really good idea using long polling, but unfortunately this would require almost same effort as web socket in the native app.

also XDM native app always runs on background as that's the main requirement for the add-on to use in the first place. If there is no one to listen at localhost:9614 then simply the add-on is of no use. Its necessary for the add-on to be in constant touch with the native app to function properly, thus the frequent pings.

As Andreas suggested, you should use a back-off - if the app is not running and you thus (presumably) get an error from the request, back off progressively (e.g. if you were making requests after 5 seconds, next do 10, 20, 60, 5 minutes, 10 minutes). Settle on checking every 10 minutes. Perhaps (depending on the usecase of your app/extension) even indicate to the user that the app is not running by displaying a different extension icon. If you're in this "back off" period and the user clicks the icon, you can check immediately at that point.

The idea to use back off time naturally comes to mind, also it's applicable for most scenarios, but for XDM this would cause bad user experience.
If XDM is not running for a while and due to back off time the next retry interval becomes more than 5 - 10 seconds, user will have to click on some button on the addon to make it aware that the native app is up now. User might get confused why the add-on is not working as expected, even after he has started the application. Native messaging will solve all this issues, so I will go for it.

Still I have publish a newer version 2.1 and increased the sync interval to 5 seconds now. In future this http ping will be replaced with web socket or native messaging, but it requires huge changes in the native app, which is not possible at the moment.

websocket or native messaging would be better, but as noted above I think even right now you could do better still. :-)

(I'm going to assign a priority here to avoid emails about this bug being untriaged)

Priority: -- → P3

Should this bug remain open? as the issue is not with Firefox, and initial fix for the addon has already been provided.

Let's resolve this per comment #20.

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

Attachment

General

Creator:
Created:
Updated:
Size: