Skip to content

Commit

Permalink
Deprecate <keygen> and appcache
Browse files Browse the repository at this point in the history 
<keygen> is not supported by Edge. Chrome and Firefox are in the
process of removing it.

Appcache is superseded by service workers.
  • Loading branch information
@annevk
annevk committed Aug 28, 2015
1 parent a0dd046 commit 1b43806
Showing 1 changed file with 11 additions and 0 deletions.
11 changes: 11 additions & 0 deletions source
View file
Original file line number Diff line number Diff line change
Expand Up @@ -49876,6 +49876,10 @@ Daddy">&lt;/textarea></pre>
</dd>
</dl><!--TOPIC:HTML-->

<p class="critical">This feature is in the process of being removed from the Web platform. (This
is a long process that takes many years.) Using the <code>keygen</code> element at this time is
highly discouraged.</p>

<p>The <code>keygen</code> element <span>represents</span> a key pair generator control. When the
control's form is submitted, the private key is stored in the local keystore, and the public key
is packaged and sent to the server.</p>
Expand Down Expand Up @@ -82116,6 +82120,10 @@ dictionary <dfn>PageTransitionEventInit</dfn> : <span>EventInit</span> {
<!--TOPIC:Offline Web Applications-->
<h3 id="offline">Offline Web applications</h3> <!--APPCACHE-->

<p class="critical">This feature is in the process of being removed from the Web platform. (This
is a long process that takes many years.) Using any of the offline Web application features at
this time is highly discouraged. Use service workers instead. <ref spec=SW></p>

<!-- v2 ideas for appcache:

* A way to limit what gets download when the user agent is updating the application cache and
Expand Down Expand Up @@ -116276,6 +116284,9 @@ INSERT INTERFACES HERE
<dt id="refsSVG">[SVG]</dt>
<dd><cite><a href="http://www.w3.org/TR/SVGTiny12/">Scalable Vector Graphics (SVG) Tiny 1.2 Specification</a></cite>, O. Andersson, R. Berjon, E. Dahlstr&ouml;m, A. Emmons, J. Ferraiolo, A. Grasso, V. Hardy, S. Hayman, D. Jackson, C. Lilley, C. McCormack, A. Neumann, C. Northway, A. Quint, N. Ramani, D. Schepers, A. Shellshear. W3C.</dd>

<dt id="refsSW">[SW]</dt>
<dd><cite><a href="https://slightlyoff.github.io/ServiceWorker/spec/service_worker/">Service Workers</a></cite>, A. Russell, J. Song, J. Archibald. W3C.</dd>

<dt id="refsTIS620">[TIS620]</dt>
<dd><cite><a
href="http://www.nectec.or.th/it-standards/std620/std620.htm">UDC 681.3.04:003.62</a></cite>. Thai Industrial Standards Institute, Ministry of Industry, Royal Thai Government. ISBN 974-606-153-4.</dd>
Expand Down

7 comments on commit 1b43806

@Hixie
Copy link
Member

@Hixie Hixie commented on 1b43806 Aug 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<keygen> has been deprecated since it was invented. I don't think we're going to make it go away until we provide a better API.

@annevk
Copy link
Member Author

@annevk annevk commented on 1b43806 Aug 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main reason I did this is because Chrome is actively trying and Firefix is about to.

@bblfish
Copy link

@bblfish bblfish commented on 1b43806 Sep 1, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Chrome's attempting to deprecate is pretty controversial as can be seen from this long thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack

Nearly no arguments are given in support, and there is hand waving towards FIDO alliance. Why not wait until the FIDO alliance code is deployed in actual devices that can be tested with keygen? Then it will be clear whether or not keygen actually needs to be deprecated.

Some key arguments in that thread are:

Essentially:

  • removing keygen removes the only currently existing way for browsers to have strong symmetric key based crypto identity. Keygen allows browsers to be the sole owners of a private key, which can be used for different purposes.
  • the current JS crypto standard allows the browser to make a private key, but since it can only store the private key in local storage which is available to all JS of the same origin, this collapses to JS usage of the key being indistinguishable from the server using the key.

Actual uses:

  • Keygen and client certificate authentication allows one client to create certificates cheaply which the client can then use to authenticate to multiple sites using for example protocols such as webid TLS or more usual CA certificate schemes.
  • Currently the only standard use keys generated with keygen is to authenticate with TLS. But clearly others could be developed.

It may be worth asking why this the usage of public key crypto is limited to TLS at the moment. My guess is that this can be explained by the TAG's rule of least power: TLS is a minimal crypto language with very limited features meaning it is possible to build browser chrome around it. There seems to be no reason why this could not be extended to authentication at the HTTP layer too.

@bblfish
Copy link

@bblfish bblfish commented on 1b43806 Sep 1, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened #67 to track this and other similar commits.

@csarven
Copy link

@csarven csarven commented on 1b43806 Sep 3, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While the discussions are taking place, evidence is being gathered, appropriate tangible alternatives have yet to appear, warning or note would be an appropriate class than critical.

@bblfish
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The W3C TAG have a report entitled "Keygen and Client Certificates" edited by
Microsoft's Travis Leithead, that forms a balanced and principled review of
the discussion:

http://w3ctag.github.io/client-certificates/

@Hixie
Copy link
Member

@Hixie Hixie commented on 1b43806 Feb 23, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What matters here is just whether browsers support it and the direction of that support. If Chrome and Firefox remove support then the spec should remove it. Arguing about the technical aspects of this feature misses the point.

Please sign in to comment.