Open sebdeckers opened 4 years ago
Opened corresponding issues at:
@annevk Thanks! How/where is implementer interest established? I'm not familiar with the procedure; the spec note merely says: "If there are schemes that ought to be added, please send feedback." So I did. 😅
For reference, previous discussion in 2012:
... resulted in the current note (d97799a2a1b4eb08a71d2e0c655ed160a4a182c5):
https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
This list excludes any schemes that could reasonably be expected to be supported inline, e.g. in an iframe, such as http or (more theoretically) gopher. If those were supported, they could potentially be used in man-in-the-middle attacks, by replacing pages that have frames with such content with content under the control of the protocol handler. If the user agent has native support for the schemes, this could further be used for cookie-theft attacks.
Could inline Gopher support still "reasonably be expected" today?
Similarly, "8.9.1.3.1 Security and privacy":
https://html.spec.whatwg.org/multipage/system-state.html#security-and-privacy
Custom scheme handlers can introduce a number of concerns, in particular privacy concerns.
Hijacking all Web usage. User agents should not allow schemes that are key to its normal operation, such as an HTTP(S) scheme, to be rerouted through third-party sites. This would allow a user's activities to be trivially tracked, and would allow user information, even in secure connections, to be collected.
The latter section does not explicitly refer to Gopher however.
It was pointed out by @classilla that Firefox re-added support for gopher
to its Extensions API about 3 years ago. This is used in the OverbiteWX extension to handle gopher:
URLs using a web-to-Gopher proxy (Floodgap).
Several Gopher/HTTP proxies exist. This change would allow them to register as a
gopher://
URL handler.https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers