add WE API to DNS cache and add possibility to reconfigure DNS for request
Categories
(WebExtensions :: General, defect)
Tracking
(Not tracked)
People
(Reporter: fdsc, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID: 20170125094131 Steps to reproduce: 1. If the network fails or the DNS fails the FireFox frequently cannot connect to the server. F5 does not help to reset incorrect DNS records in the cache. 2. The DNS leak leakage of privacy is due to the fact that FireFox are using the default DNS settings. Expected results: 1. Need to reset the DNS cache by WebExtensions API 2. For each request FireFox must have handler, which could specify what DNS to use to resolve a hostname from the request.
|
||
Updated•8 years ago
|
|
||
Comment 1•8 years ago
|
||
To be discussed at the WebExtensions Triage meeting on March 21. Agenda: https://docs.google.com/document/d/1xM6iKOSGo9cDWw3ZA27PT-AVlx1Mvd79sxC6pYNhBqU/edit?usp=sharing
|
||
Comment 2•8 years ago
|
||
Ad 2: It would be fantastic if WE API provided a way to query for more than A record (eg. A and TXT) Having additional info from DNS TXT before ANY request is made enables interesting possibilities. For example add-on could decide to modify/redirect HTTP requests based on information from TXT record. Real life example: "dnslink" from IPFS: https://github.com/ipfs/examples/tree/master/examples/websites
|
||
Comment 3•8 years ago
|
||
It's not in the scope of webextensions to mess with network/os level stuff.
According to the WebExtension FAQ[1][2], Mozilla didn't originally put this limitation on WebExtensions: > We don't want to limit what add-ons can do in Firefox. We will work with every developer who is interested to make their add-on work in Firefox, and work to provide the functionality required in as many cases as possible. This process is designed to allow developers to extend Firefox in ways that are less brittle than the current XUL/XPCOM system, and to allow Firefox itself to transition away from XUL/XPCOM. Could you provide a more substantiated reasoning to why this is out of scope for WebExtensions? Is he requesting the wrong API to provide what he needs? The project was announced with the goal to provide a more stable API, without limiting add-ons in any way. I hope that this is a mistake/miscommunication and that Mozilla hasn't drifted away from this goal, and does not want to limit add-on capabilities. [1] https://wiki.mozilla.org/WebExtensions/FAQ#Which_add-ons_will_stop_working_when_XUL.2FXPCOM_is_deprecated.3F [2] Here's an archived version of today: https://archive.fo/rK7t0
|
||
Comment 5•8 years ago
|
||
I think we should update the FAQ you reference to paint a more realistic view. Those words were written 18 months ago.
Those words were a promise from Mozilla towards add-on developers and users that this whole XUL/XPCOM deprecation wouldn't hurt them. The transition would cost a lot of work, but when the finish line is an actual better world to live in, it is worth it. If in the end we end up with an add-on system that is a glorified version of Chrome's, it is not. Note that I don't want to dismiss the work you are doing in any way. Having WebExtensions is a very good thing, and it is positive that Mozilla does want to move beyond what Chrome is offering, but it is not what you promised. Mozilla's community is built on a two-way trust between Mozilla itself and its users. You can't expect to soothe the community with nice words, and later act like you never said them. When Firefox 57 lands, lots of popular add-ons won't be available, and multiple of them won't even be portable at that point. Mozilla has promised to offer a decent alternative, and while you are working very hard, it isn't there yet, and dismissing API requests with "It's not in the scope of WebExtensions" is not the way to go. *At least* provide a decent explanation, and preferably an alternative. "We won't do this, because you better do it like this or that" would be a perfect reason for a WONTFIX. But there are add-on developers who need this API, and you are denying it to them, explicitly making some range of add-ons impossible that were possible before. Which is, as I mentioned, not what you have announced/promised. Firefox has historically been *the* browser that's open for anyone to adapt to their liking. Let's try to keep it this way, please. P.S. I am aware that a bug report is not the correct place for this conversation, so I will soon post an extended version of this comment on the dev-addons mailing list. We should continue the discussion there.
|
||
Updated•6 years ago
|
|
||
Comment 7•4 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #3)
It's not in the scope of webextensions to mess with network/os level stuff.
Is this still the case? Especially with DoH deployment now, capturing DoH (and DNS over UDP) in webRequests events would have significant advantages for more advanced extensions.
|
|
||
Comment 8•4 years ago
|
||
(In reply to Matthew Finkel [:sysrqb] from comment #7)
(In reply to Shane Caraveo (:mixedpuppy) from comment #3)
It's not in the scope of webextensions to mess with network/os level stuff.
Is this still the case? Especially with DoH deployment now, capturing DoH (and DNS over UDP) in webRequests events would have significant advantages for more advanced extensions.
That comment was too long ago for me to have retained the context behind it, and there were no notes on the discussion unfortunately. Reading it at this point I would interpret it as we were not going to make modifications to the underlying platform network code that would only be done for a feature in extensions that are not cross-browser. DoH was not a thing (iow released and in use) at that time either.
webRequest is specifically about http connections, not a socket layer api for udp interception, so that would never fit. It is possible that DoH requests could go through webRequest, but I suspect those are system requests which are explicitly disallowed. I'd also have security concerns around that, it would need to have an ok from the security team.
|
|
||
Comment 9•4 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #8)
(In reply to Matthew Finkel [:sysrqb] from comment #7)
(In reply to Shane Caraveo (:mixedpuppy) from comment #3)
It's not in the scope of webextensions to mess with network/os level stuff.
Is this still the case? Especially with DoH deployment now, capturing DoH (and DNS over UDP) in webRequests events would have significant advantages for more advanced extensions.
That comment was too long ago for me to have retained the context behind it, and there were no notes on the discussion unfortunately. Reading it at this point I would interpret it as we were not going to make modifications to the underlying platform network code that would only be done for a feature in extensions that are not cross-browser. DoH was not a thing (iow released and in use) at that time either.
webRequest is specifically about http connections, not a socket layer api for udp interception, so that would never fit. It is possible that DoH requests could go through webRequest, but I suspect those are system requests which are explicitly disallowed. I'd also have security concerns around that, it would need to have an ok from the security team.
Thanks (and I understand a lack of context after multiple years). Would opening a new ticket as an enhancement request be more productive than resurrecting this one? I understand the security concerns, however, at the same time this functionality would also provide a framework for experimenting more web security enhancements (like DoH) which aren't possible with the current API.
|
|
||
Comment 10•4 years ago
|
||
Thanks (and I understand a lack of context after multiple years). Would opening a new ticket as an enhancement request be more productive than resurrecting this one? I understand the security concerns, however, at the same time this functionality would also provide a framework for experimenting more web security enhancements (like DoH) which aren't possible with the current API.
I don't see us implementing a public api for experimenting. There is an experimental api capability that could be used to test out ideas. In any case, if you want further consideration is always better to open a new bug, referencing the prior closed bug.
Description
•