Maybe if they were more clear in their Wiki page, I wouldn't have been as concerned.
"The current implementation is of draft-14 with compression-09 [august 6 nightly] Firefox will only be implementing HTTP/2 over TLS"
"There is a separate, more experimental, build available that supports HTTP/2 draft-12 ... Sometimes this is known as opportunistic encryption."
To an outsider like myself not following every step of the draft process, that reads to me like opportunistic encryption was dropped between draft-12 and draft-14. I am glad to hear that's apparently not the case.
All the same, even self-signing isn't going to completely eliminate the overhead of needing to write or use TLS encryption libraries. It's going to complicate the requirements to create tools that talk over the web.
You can argue that this is a good thing and everyone should be using libraries and you may be right. But some of us oldschool programmers like the simplicity of talking to things like serial to the unbelievable complexity of things like USB.
There was something magic about HTTP where you could just open a socket, send it a header, recv the response, and you're done.
Now, there are of course ways to make opportunistic encryption this easy. If our libc copies were to gain something like AF_INET_OTLS, and the network stack would do the encryption transparently on your send/recv requests, that would be great. But I'd be willing to bet money they're instead just going to say, "oh well that's on you, the application developer. Just use OpenSSL or LibreSSL."
What you said sounds good.
Maybe if they were more clear in their Wiki page, I wouldn't have been as concerned.
"The current implementation is of draft-14 with compression-09 [august 6 nightly] Firefox will only be implementing HTTP/2 over TLS"
"There is a separate, more experimental, build available that supports HTTP/2 draft-12 ... Sometimes this is known as opportunistic encryption."
To an outsider like myself not following every step of the draft process, that reads to me like opportunistic encryption was dropped between draft-12 and draft-14. I am glad to hear that's apparently not the case.
All the same, even self-signing isn't going to completely eliminate the overhead of needing to write or use TLS encryption libraries. It's going to complicate the requirements to create tools that talk over the web.
You can argue that this is a good thing and everyone should be using libraries and you may be right. But some of us oldschool programmers like the simplicity of talking to things like serial to the unbelievable complexity of things like USB.
There was something magic about HTTP where you could just open a socket, send it a header, recv the response, and you're done.
Now, there are of course ways to make opportunistic encryption this easy. If our libc copies were to gain something like AF_INET_OTLS, and the network stack would do the encryption transparently on your send/recv requests, that would be great. But I'd be willing to bet money they're instead just going to say, "oh well that's on you, the application developer. Just use OpenSSL or LibreSSL."