Re: [whatwg] possible new parameters to ?

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.
> HTH,


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.

Received on Tuesday, 1 November 2016 12:41:25 UTC