Native messaging only reports generic errors
Categories
(WebExtensions :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: tobiasdiez, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
Steps to reproduce:
Use browser.runtime.sendNativeMessage with a non-working setup. For example, assume that the path in the registry to the native manifest file is wrong.
Actual results:
The error handler of sendNativeMessage is called with the generic error message "Attempt to postMessage on disconnected port". No further error information is contained in this error, but the browser console reports the helpful additional information
Error reading native manifest file <path>: file is referenced in the registry but does not exist
Expected results:
The error in the failure callback of sendNativeMessage should contain the details of what went wrong. Only in this way extension developer could provide a meaningful and helpful error to the user. Currently, one has to refer the user to the browser console which is not user-friendly at all.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
This is working as intended. The errors are intentionally generic so that add-ons cannot infer information from the installed native messaging hosts unless the native messaging host is correctly registered. The browser console is the documented way for getting information to support debugging: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging#troubleshooting
|
Reporter | |
Comment 3•3 years ago
|
||
Thanks for your answer.
However, I fail so see how this is a security feature. What would be so bad to tell an extension where the native manifest file were supposed to be but isn't?
This design makes it impossible for extensions to give details to the user about the nature of the issue. And from my experience there is a lot of stuff that could go wrong, especially if you factor in different distribution ways like snap etc. The browser console is a good solution for devs, but not for the average user.
Could this please be reconsidered, and maybe find a middle way between protecting sensitive data vs helpful error messages. Thanks!
|
|
||
Comment 4•3 years ago
|
||
Debugging information can contain sensitive information, such as file paths and names of native messaging hosts that did not opt in to being exposed to extensions. Exposing this is a privacy risk. Even just the knowledge of the existence of a native app registration can be abused to fingerprinting users. It is therefore not an option to expose this information to APIs by default.
Those who may potentially understand the debugging messages should be able to open the Browser Console. And when they do, they do hopefully understand the (privacy) risks of reading/sharing the exposed information.
Description
•