On 09/19/2016 07:41 AM, Simon Pieters wrote:

There is always room for adding convenience APIs, it's a matter of
demonstrating that it's a common enough need to make it worth the cost
of adding it.




Going off topic but an excellent example of what can happen when those things in the link aren't considered are the ramifications of adopting of Google's HPKP (RFC 7469)

* Even though TLS is used over a wide range of protocols, it is specific to one protocol - HTTP. The Internet is bigger than the web, a proper solution to a problem that exists across protocols isn't limited to just one protocol.

* It is blind trust on first use, which means the pins have to be cached for a relatively long time (to reduce window when that blind trust can be exploited)

* Thus you have to have at least one spare private key before deploying, so that its keypin can be cached by browsers as well.

* That spare private key can't be kept as the same place as the main key because if the main key is stolen via file access, the spare key will likely be compromised too.

* In addition to needing to keep the spare key in a separate place that is secure, it ties you in to specific technology because of the long cache life. Thus if your private key is compromised because of a zero day that only works on RSA keys you can't switch to ECDSA unless your spare key is already ECDSA.

* Puts you at the mercy of the browser vendors. What happens if you were using secp521r1 when Chrome decided to drop it? I hope people had backup keys that weren't secp521r1/

* If an employee leaves a company that potentially had access to private keys, it means you can't immediately rotate all the private keys to shiny new ones.

All those problems exist because it was implemented (initially in Chrome) without careful consideration. Rich companies like Google can do that. And it has hampered the adoption of a better technology (DANE) that doesn't have any of those issues.

So yes, adding new features really does require very careful thought.


That being said, I like the attribute idea for audio and suspect it may have less accessibility issues than using JavaScript might have, notably it being easier for software to notify the user what the start and stop times are by reading them directly from the audio tag attributes.

So I like the idea.

Reply via email to