-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
We previously deprecated keygen in 1b43806. It was never implemented in Edge, and Chrome is moving to remove all key types and thus all UI, per blink-dev.
Last time this was discussed I was told Firefox was also interested in deprecating and removing. @smaug----, @bzbarsky, any thoughts there? While we're at it, any thoughts from WebKit, @rniwa @cdumez?
We should discuss whether we want to remove support for keygen entirely, similar to what is slated for <applet>
in #1399. This would mean:
- No longer submitting it in the form data set at all, instead of submitting an empty string
- Removing the HTMLKeygenElement API (keygen elements would become HTMLUnknownElement)
- Removing it from the various form-associated things, so e.g. it would not show up in
form.elements
- (Optional, but see below) Removing parser support for it
We have tentative support for doing this from @sleevi on the blink-dev ("that would make logical sense"), and of course Edge does not implement support at all---except for parsing, it appears. See http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4685. Note that Firefox's current parsing is bizarre; it transforms it into a <select _moz-type="mozilla-keygen">
element. So maybe there is some flexibility there. But in the past (e.g. for applet) we've decided to not change the parser when removing elements.
What I'd like to get out of this thread is:
- Are more browsers than Chrome and Edge interested in neutering keygen's functionality by making it never support any key types?
- Are more browsers than Chrome and Edge interested in removing keygen entirely?