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.
https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94
HTH,
* OFF TOPIC *
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.
* BACK ON TOPIC *
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.
