The secret message hidden in every HTTP/2 connection(blog.jgc.org)
blog.jgc.org
The secret message hidden in every HTTP/2 connection
http://blog.jgc.org/2015/11/the-secret-message-hidden-in-every.html
126 comments
A funny joke, but a telling statement. Words so commonly used reflect attitudes and history. For instance most of the English-speaking world says Goobye ("God be with you") while the French use the more neutral AuRevoir (until we see again). Web browsers now greet websites with "PRISM", the equivalent of "the walls have ears".
I blogged on the usefulness of reading RFCs more only the other day:
https://zwischenzugs.wordpress.com/2015/11/26/the-it-crowd-w...
Personally, I trust the elders of the internet implicitly.
https://zwischenzugs.wordpress.com/2015/11/26/the-it-crowd-w...
Personally, I trust the elders of the internet implicitly.
For wisdom from the "elders", I recommend reading RFC 1925.
https://news.ycombinator.com/item?id=9045533 (footnote [2])
https://news.ycombinator.com/item?id=9045533 (footnote [2])
Great, so now all HTTP/2 traffic forever is going to start with a reference to an NSA program that was topical for about a week in 2013.
Maybe we could have waited a year and made the magic
Maybe we could have waited a year and made the magic
THE * HTTP/2.0
DRESS
KO * HTTP/2.0
NYThis is a pretty good way to remind ourselves ("Never Forget") why some things are the way they are. It stands out and is perhaps unexpected, giving a chance to have a discussion around the things we want to avoid or combat. That it shows up in the protocol gives relevance to a FAQ entry on the topic, vs just being a by-the-way FAQ entry that is easier to ignore.
It could just as well have been ECHELON [0], however PRISM has more recent, and documented, meaning and more mindshare specifically around/related to domestic spying.
[0] https://en.wikipedia.org/wiki/ECHELON
It could just as well have been ECHELON [0], however PRISM has more recent, and documented, meaning and more mindshare specifically around/related to domestic spying.
[0] https://en.wikipedia.org/wiki/ECHELON
While both "the dress" and prism appeared in the news, lets not forget some news is actually newsworthy and some is forgettable mind candy. Prism needs to be remembered and including it in the protocol message ensures it will be discussed for much longer than the dress -- as it should be.
I named my hobby HTTP2 server after that string in the connection header:
https://github.com/gregory144/prism-web-server
(obviously haven't had much time to work on it lately).
https://github.com/gregory144/prism-web-server
(obviously haven't had much time to work on it lately).
Leaving the specific letters aside, I wonder about this comment in https://github.com/http2/http2-spec/issues/101:
"And the experimental data we have (what there is of it) suggests that we need to make this look like an unknown HTTP/1.1 method (or two)."
Anyone know what experimental data this refers to, and why this helps? This gets encapsulated inside TLS; nothing should know about it except the endpoints, both of which need to understand HTTP/2.
"And the experimental data we have (what there is of it) suggests that we need to make this look like an unknown HTTP/1.1 method (or two)."
Anyone know what experimental data this refers to, and why this helps? This gets encapsulated inside TLS; nothing should know about it except the endpoints, both of which need to understand HTTP/2.
HTTP/2 is not TLS-only, even though major browsers will only use it over TLS. And even when over TLS, the TLS connection might terminate in a separate machine, it going cleartext the rest of the way.
> HTTP/2 is not TLS-only, even though major browsers will only use it over TLS.
Which in practice will (hopefully) make it TLS-only. As I recall, one of the original motivations to require TLS, and one of the reasons browsers plan to mandate TLS (apart from the obvious), was specifically to avoid broken "transparent" proxies.
> And even when over TLS, the TLS connection might terminate in a separate machine, it going cleartext the rest of the way.
If the server uses a TLS frontend device and passes cleartext to a backend, then apart from that being a really bad idea from a security perspective, they should know better than to allow that to pass through a broken transparent proxy.
Which in practice will (hopefully) make it TLS-only. As I recall, one of the original motivations to require TLS, and one of the reasons browsers plan to mandate TLS (apart from the obvious), was specifically to avoid broken "transparent" proxies.
> And even when over TLS, the TLS connection might terminate in a separate machine, it going cleartext the rest of the way.
If the server uses a TLS frontend device and passes cleartext to a backend, then apart from that being a really bad idea from a security perspective, they should know better than to allow that to pass through a broken transparent proxy.
Looking over https://www.ietf.org/mail-archive/web/httpbisa/current/msg14..., I'm not sure whether I'm reading this correctly. In light of PRISM, the author posed a few options:
1) We can try to add more encryption to fight back.
2) We can recognize that there needs to be hooks for duly authorized access.
3) We can change or at least influence the political objectives
Personally, I'd have assumed option one is the obvious answer, in addition to increasing adoption of encryption in other areas (though that may be outside the scope of their project). Unfortunately the author seems to conclude that there need to be (presumable CALEA-style) hooks for "duly authorized access". This is almost unbelievable that they are openly suggesting implementing backdoors in communications protocols. I expect this from LE and politicians, but I don't expect this from FreeBSD commiters.
1) We can try to add more encryption to fight back.
2) We can recognize that there needs to be hooks for duly authorized access.
3) We can change or at least influence the political objectives
Personally, I'd have assumed option one is the obvious answer, in addition to increasing adoption of encryption in other areas (though that may be outside the scope of their project). Unfortunately the author seems to conclude that there need to be (presumable CALEA-style) hooks for "duly authorized access". This is almost unbelievable that they are openly suggesting implementing backdoors in communications protocols. I expect this from LE and politicians, but I don't expect this from FreeBSD commiters.
This change was committed on Jun 14th 2013, about a week after the PRISM programme had been leaked by Edward Snowden. It is a clear reference to the programme but by this point it was already public knowledge.
I don't know the exact date that Snowden leaked PRISM but it was already being talked about as early as June 6th 2013 in the Washington Post http://www.washingtonpost.com/wp-srv/special/politics/prism-...
I don't know the exact date that Snowden leaked PRISM but it was already being talked about as early as June 6th 2013 in the Washington Post http://www.washingtonpost.com/wp-srv/special/politics/prism-...
It's a Pink Floyd reference, obviously.
Careful with that deep packet inspection, Eugene.
The real gold is Ilya Grigorik's comment on the commit. https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a...
platz(8)
[deleted]
I can see pretty much why FUBAR was switched to -----. I'm more curious as to what ----- stands for.
[Edit removed the secret message to keep the suspense ;)]
[Edit removed the secret message to keep the suspense ;)]
"PRISM" is obviously a reference to the surveillance program. HTTP/2.0 developers were well aware and worried about it. For example see this mail from PHK on the httpbis mailing list: http://www.ietf.org/mail-archive/web/httpbisa/current/msg142...
The HTTP/2 spec is done on https://github.com/http2/http2-spec, this particular change seem to be quietly introduced here:
commit ac468f3fab9f7092a430eedfd69ee1fb2e23c944
Author: Martin Thomson <[email protected]>
Date: Fri Jun 14 13:14:02 2013 -0700
Exercising editorial discretion regarding magic.
diff --git a/draft-ietf-httpbis-http2.xml b/draft-ietf-httpbis-http2.xml
index 58bbc27..f1e570d 100644
--- a/draft-ietf-httpbis-http2.xml
+++ b/draft-ietf-httpbis-http2.xml
@@ -385,9 +385,9 @@ Upgrade: HTTP/2.0
The client connection header is a sequence of 24 octets (in hex notation)
</t>
<figure><artwork type="inline">
-535441202a20485454502f322e300d0a0d0a52540d0a0d0a</artwork></figure>
+505249202a20485454502f322e300d0a0d0a534d0d0a0d0a</artwork></figure>
<t>
- (the string <spanx style="verb">STA * HTTP/2.0\r\n\r\nRT\r\n\r\n</spanx>) followed by a
+ (the string <spanx style="verb">PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n</spanx>) followed by a
<xref target="SETTINGS">SETTINGS frame</xref>. The client sends the client connection header
immediately upon receipt of a 101 Switching Protocols response (indicating a successful
upgrade), or after receiving a TLS Finished message from the server. If starting anThe commit on GitHub, for anyone interested: https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a...
Yea, looks like an inside joke / silent protest.
The date (14-Jun-2013) would fit.
"... The disclosures were published by The Guardian and The Washington Post on June 6, 2013. Subsequent documents have demonstrated a financial arrangement between ... "
[https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%...]
"... The disclosures were published by The Guardian and The Washington Post on June 6, 2013. Subsequent documents have demonstrated a financial arrangement between ... "
[https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%...]
Not too important but the article misses the FOO-BAR to FOO-BA to STA-RT transition, and the related issue (https://github.com/http2/http2-spec/issues/101)
In the communist days the writers of letters (in sealed envelopes) would routinely greet the censor or wish them merry Christmas and stuff like that.
Feynman's version of messing with the censors:
https://books.google.com/books?id=7papZR4oVssC&pg=PA114#v=on...
That book is absolutely fantastic and I would highly recommend it to anyone.
Lots of very interesting bits that made me laugh.
Lots of very interesting bits that made me laugh.
That page is not available to me - I can see 113 and 115, but not 114. Can someone tell me what's about?
Edit: Found a link for those that cannot see it either: http://litru.ru/book/?p=214644&page=24 . No idea why Google decided I cannot read that particular page.
Edit: Found a link for those that cannot see it either: http://litru.ru/book/?p=214644&page=24 . No idea why Google decided I cannot read that particular page.
Maybe you exhausted your 'allowed page quota'.
He came up with sending powder in envelopes? That's news to me.
The trick he played on Teller and then Teller seeing through it instantly, priceless.
The trick he played on Teller and then Teller seeing through it instantly, priceless.
Even though I just re-read that excerpt (lovely book indeed), for a moment there I thought you were talking about Teller from Penn & Teller, and how much I'd love to see those three talking or playing tricks on one another :) (well, without Teller talking, obviously)
I didn't quite get the desk/paper thing -- was it continuous feed paper, so Feynman grabbed the end and pulled it all out?
No, he just kept on pulling and then another paper would be within reach until the drawer just about emptied. Similar to how folded napkins are all separate but you can pull one out of a container and then the next one will be pulled into place by the previous one. That's on purpose and this is accidental but the mechanism would be much the same.
Wow this book is really interesting, thanks for the recommendation!
You also had that with military radio coms during the cold war, both sides would include messages to the other in their "internal" communications.
That's interesting, it's a pity none of those will likely ever see the light of day.
And that in turn reminds me of this:
http://www.wjpbr.com/wwixmas.html
Pity they didn't just pack up and go home after that.
And that in turn reminds me of this:
http://www.wjpbr.com/wwixmas.html
Pity they didn't just pack up and go home after that.
> Pity they didn't just pack up and go home after that.
Indeed. The public radio station in my town (in the U.S.) airs a special on the Christmas Truce every year around Christmastime. It's supposed to be uplifting, but I find it almost unbearably sad. The Europe out of which that spirit came was demolished during the war.
Indeed. The public radio station in my town (in the U.S.) airs a special on the Christmas Truce every year around Christmastime. It's supposed to be uplifting, but I find it almost unbearably sad. The Europe out of which that spirit came was demolished during the war.
I suspect those messages were never official, but more the local operators making the best of being posted during holidays. Thus they were likely never recorded anywhere.
reminds me of rms' post-snowden email header.
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Also, 2016 is almost here. Don't forget to post your annual "You are hereby notified that you are strictly prohibited from disclosing, copying, distributing, disseminating, or taking any other action against me with regard to this profile and the contents herein." status update to Facebook.
Haha, I find it amusing that people even think that's effective.
I wrote someone in prison a letter and included a greeting to the prison warden. It's very tempting somehow.
That's extraordinarily silly, because HTTP is already loaded up with much more useful runs of known plaintext.
Care to explain the relevance?
The relevance is that this text could ostensibly be used as the known plaintext to aid in breaking encryption, however, it's not going help much anyway.
For example, with HTTP 1.1, it is pretty much likely that an HTTP response would start with HTTP/1.1 200 OK, or that it would contain strings such as "Content-Type" or "Content-Length". 24 more known bytes won't make it much worse.
For example, with HTTP 1.1, it is pretty much likely that an HTTP response would start with HTTP/1.1 200 OK, or that it would contain strings such as "Content-Type" or "Content-Length". 24 more known bytes won't make it much worse.
Any strong cipher should be resistant to a known plaintext attack.
If your encryption is vulnerable to known plaintext you should upgrade.
If your encryption is vulnerable to known plaintext you should upgrade.
When you have an encrypted file (or a stream for that matter) and you know the first N bytes of the decrypted data, it might be easier to compute the encryption key if algorithm uses blocks smaller than N.
[deleted]
[deleted]
The author isn't implying that the NSA intentionally injected the word "PRISM" into the header of every HTTP/2 connection. Rather, that the members of the IETF that collaborated on the standard chose to change the existing dummy text to match those initials once the existence of the program was leaked to the public, presumably as a sort of inside joke/protest.
^ I figure I'd clarify that in case anyone else gets as confused as I did about what possible political or technical objectives the NSA might achieve by including a reference to a top-secret spy program in every HTTP/2 message (although it does seem like the sort of thing a comic-book evil intelligence organization would do :P).
^ I figure I'd clarify that in case anyone else gets as confused as I did about what possible political or technical objectives the NSA might achieve by including a reference to a top-secret spy program in every HTTP/2 message (although it does seem like the sort of thing a comic-book evil intelligence organization would do :P).
Wouldn't including a constant block at the beginning of every message of the plaintext help to break any ciphertext generated from the plaintext?
No, secure ciphers like AES are not vulnerable to known plaintext attacks
Hold on. AES is not intrinsically vulnerable to known-plaintext, like every modern cipher probably going back all the way to DES, but that doesn't mean AES constructions can't be attacked through known plaintext runs.
This particular text isn't a vulnerability (after all, HTTP is full of known plaintext), but I think you've overplayed your argument. :)
This particular text isn't a vulnerability (after all, HTTP is full of known plaintext), but I think you've overplayed your argument. :)
yeah, if knowing the leading 192 bits of the plaintext (24 octets, per article) lets an attacker break a session encrypted with 256-bit AES, you've got bigger problems than a known-plaintext attack, methinks. :)
Well, it eliminates most of the possible keys. Out of 2^256 possible keys, only 2^64 are now possible.
This would be serious if someone found a way to easily identify which keys were still possible. From there, you could find the real key simply by a process of elimination. It would be somewhat lengthy, but not unreasonably so. But so far as I know, nobody yet knows how to easily identify which keys are still possible.
Note: I'm ignoring IVs here, partly because I don't know if HTTP2 uses them. They may make the process of elimination impossible (at least in realistic amounts of time).
This would be serious if someone found a way to easily identify which keys were still possible. From there, you could find the real key simply by a process of elimination. It would be somewhat lengthy, but not unreasonably so. But so far as I know, nobody yet knows how to easily identify which keys are still possible.
Note: I'm ignoring IVs here, partly because I don't know if HTTP2 uses them. They may make the process of elimination impossible (at least in realistic amounts of time).
This looks like exactly the kind of vulnerability that Tony Arcieri is, correctly, saying doesn't happen with modern ciphers.
HTTP2 doesn't "use IVs" at all, in that encryption in HTTP2 is provided by TLS. TLS does use random IVs, and modern TLS uses them correctly.
HTTP2 doesn't "use IVs" at all, in that encryption in HTTP2 is provided by TLS. TLS does use random IVs, and modern TLS uses them correctly.
Isn't supposed to happen. It would be a break of AES if it were to be shown to be possible. However it would mean that such a break would be instantly exploitable, rather than having defense in depth by requiring multiple independent failures. Our crypto systems should not be so fragile...
No. As has been repeatedly pointed out: HTTP is positively loaded with much longer runs of known plaintext.
This may be true for a single session, but it would seem that having every session begin with the same long text could allow correlations to be drawn on large data sets, potentially leading to full recovery of the sessions.
Do you know of the proof that rules out such a possibility?
Do you know of the proof that rules out such a possibility?
No, that is not a realistic vulnerability. I am now regretting nerding out about AES upthread, since I seem to have created the impression that there is some risk to having every HTTP request start with a fixed string. There is not.
>I seem to have created the impression that there is some risk to having every HTTP request start with a fixed string
Every HTTP request does not start with a fixed string. Every HTTP2 request apparently does (if I have read correctly).
>There is not.
Why not? What allows AES to escape such an attack?
Every HTTP request does not start with a fixed string. Every HTTP2 request apparently does (if I have read correctly).
>There is not.
Why not? What allows AES to escape such an attack?
> Why not? What allows AES to escape such an attack?
What attack? A known plaintext attack is just a type of attack. There aren’t any such known attacks against AES currently. http://crypto.stackexchange.com/a/10837/7264 is related.
What attack? A known plaintext attack is just a type of attack. There aren’t any such known attacks against AES currently. http://crypto.stackexchange.com/a/10837/7264 is related.
Fair enough. Maybe there is some disagreement between the participants of this thread in what "known-known" means. I would say that without a proof that a known-plaintext attack cannot exist, one cannot say "There is not (a known-plaintext attack)." One could say, however, "I do not know of a known-plaintext attack against AES, however I do not know of a proof that rules one out."
Also, HTTP/2 traffic may be encrypted using another scheme (which may be vulnerable to large constant blocks in known locations). I don't think HTTP refers or deals at all with encryption. I'm not sure about HTTP2. My understanding is that they are application protocols only and that message integrity protocols occur at a different layer.
Also, HTTP/2 traffic may be encrypted using another scheme (which may be vulnerable to large constant blocks in known locations). I don't think HTTP refers or deals at all with encryption. I'm not sure about HTTP2. My understanding is that they are application protocols only and that message integrity protocols occur at a different layer.
> Also, HTTP/2 traffic may be encrypted using another scheme (which may be vulnerable to large constant blocks in known locations).
This isn’t really a situation worth caring about when designing a protocol. If you’re choosing to encrypt something with weak encryption, you had better be darn sure that its vulnerabilities don’t apply. (And… why would you do that to begin with? No compelling performance reasons, even.)
This isn’t really a situation worth caring about when designing a protocol. If you’re choosing to encrypt something with weak encryption, you had better be darn sure that its vulnerabilities don’t apply. (And… why would you do that to begin with? No compelling performance reasons, even.)
There is not. This is something the first few lectures in Boneh's Coursera class should address for you.
no of course I don't know such a proof. But I wouldn't say 192 bits is long, in any case! It's absolutely tiny.
If you use randomness (like in say CBC mode) that should suffice to give you IND-CPA security, no? And I believe GCM mode gives you IND-CCA2 security as well.
Actually CBC is a great mode for demonstrating how constructions built on secure primitives can introduce vulnerabilities. We can prepend a specific block to one with known plaintext in CBC mode to end up with garbage + plaintext we control.
There is a reason HTTP/2 requires GCM or other AEAD. TLS's MAC-before-encrypt is flawed because of these kinds of attacks.
>This particular text isn't a vulnerability (after all, HTTP is full of known plaintext).
This isn't quite a proof. You'd need to show that HTTP is not vulnerable to such an attack.
I don't think HTTP requires a starting block.
HTTP2 apparently requires a client's first message to be/start with:
Maybe I am reading things wrong?
This isn't quite a proof. You'd need to show that HTTP is not vulnerable to such an attack.
I don't think HTTP requires a starting block.
HTTP2 apparently requires a client's first message to be/start with:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
Maybe I am reading things wrong?
Not actually requiring something to start with a fixed string doesn't really mean anything when every message begins with a fixed string because it's just the way to do.
doesn't HTTP require "VERB URL HTTP/VERSION" ?
Yes, but there are many VERBs and URLs.
but "GET / HTTP/1.1" is likely the most common.
I'd believe it might be the most common (though, I'd guess "GET /favicon.ico HTTP/1.1" to be a real contender). I highly doubt either are anywhere more than a small fraction of the total HTTP requests though.
What is it about this particular text that makes it not vulnerable? That it is short?
[deleted]
As shown in the commit itself[1] (and implied by the original article), the connection header always started with a constant text block. It was just changed to include "PRISM" instead of "START".
[1] https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a... (as linked by others below)
[1] https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a... (as linked by others below)
The particular constant block may not matter much.
The curious thing here (for me at least) is all sessions beginning with a constant block of some length.
The curious thing here (for me at least) is all sessions beginning with a constant block of some length.
It seems like the thing an immature boy would do, but hey it just HTTP/2 protocol, no harm done!
I downvoted you, but I thought I'd explain why - I don't think it's reasonable to characterise this as childish. Government surveillance is something which our industry is the best positioned to speak out against. This type of thing seems to be clearly political speech, and not a prank.
It also is something that really hurts our industry, perhaps more so than any other industry out there.
Edit: To be clear, I mean the spying hurts our industry.
Edit: To be clear, I mean the spying hurts our industry.
Legit question, why?(in this case)
If you mean general lack of professionalism, sure, but in this case encoding this as a matter of protest seems appropriate.
Genuine question, how does it really hurt our industry?
You mean because "outsiders" will see us as childish or for some technical reason?
You mean because "outsiders" will see us as childish or for some technical reason?
I meant the spying hurts our industry as those who buy IT services lose trust in the confidentiality of their data.
Yes; the entirety of our internet infrastructure is...almost...hopelessly insecure. The OpenSSL team refuses to even use SSL/TLS on their website because "they don't want anyone to get the slightest illusion that it's secure" and want everyone to manually verify the SHA hashes.
> The OpenSSL team refuses to even use SSL/TLS on their website because "they don't want anyone to get the slightest illusion that it's secure"
Eh?
1) Visting http://www.openssl.org automatically redirects me to https://www.openssl.org .
2) The OpenSSL source code is stored in a git repo in GitHub. While this doesn't ensure that the code hasn't been tampered with, git does make it substantially easier to detect tampering than other VCSs do.
3) All of the release tarballs are PGP signed. Verification of the authenticity of these files is just about as automatic as it gets.
Eh?
1) Visting http://www.openssl.org automatically redirects me to https://www.openssl.org .
2) The OpenSSL source code is stored in a git repo in GitHub. While this doesn't ensure that the code hasn't been tampered with, git does make it substantially easier to detect tampering than other VCSs do.
3) All of the release tarballs are PGP signed. Verification of the authenticity of these files is just about as automatic as it gets.
I could be mistaken but I think, not too long ago, openssl.org used to redirect to openssl.net.
And if I recall correctly, it was http://openssl.net not https://.
Is it possible there have been some changes in recent years?
And if I recall correctly, it was http://openssl.net not https://.
Is it possible there have been some changes in recent years?
> Is it possible there have been some changes in recent years?
Well, I made my comment based largely on information that I verified a few minutes before I wrote the comment. I'm unaware of the site's history.
Well, I made my comment based largely on information that I verified a few minutes before I wrote the comment. I'm unaware of the site's history.
Have they posted their concerns regarding SSL/TLS? It would make interesting reading. I am assuming the issue is the certificate issuance hierarchy and correspondent lack of transparency, but that's just a guess.
Of course if those hashes are also served via plaintext, then comparing them also doesn't matter, and using them as verification is akin to praying to not be compromised
The OpenSSL team uses TLS on www.openssl.org. I don't know where you found that quote.
As part of the in-group I can think it's kind of funny in a "stick it to the man" kind of way. But considering that much of what let's the NSA do what it does is because of the failure of organizations like the IETF (and bystanders like ourselves not to put more pressure on them) to make secure technologies prevalent, it's not that funny anymore.
This is exactly what the NSA wants. That you feel like you're on the right side and "sticking it to the man" while they laugh all the way to their long term data storage.
This is exactly what the NSA wants. That you feel like you're on the right side and "sticking it to the man" while they laugh all the way to their long term data storage.
It might be political speech, but it's also childish.
What is it intended to accomplish? What is the actual statement being made, and who is the intended audience? Not the government - they already know what PRISM is. Also not the common internet user. If it had the potential to be effective at influencing or censoring political dialogue, I would be upset at the attempt to bake propaganda (however sympathetic the tech community might be to it) into what should be a politically neutral protocol. But it does seem more like a prank than anything else.
What is it intended to accomplish? What is the actual statement being made, and who is the intended audience? Not the government - they already know what PRISM is. Also not the common internet user. If it had the potential to be effective at influencing or censoring political dialogue, I would be upset at the attempt to bake propaganda (however sympathetic the tech community might be to it) into what should be a politically neutral protocol. But it does seem more like a prank than anything else.
> This type of thing seems to be clearly political speech
So it's your assertion that a thing cannot be both "childish" and "political speech" at the same time?
So it's your assertion that a thing cannot be both "childish" and "political speech" at the same time?
Apparently Feynman is pretty "childish" too: https://news.ycombinator.com/item?id=10650175
I don't think Feynman would have disagreed with that.
If IETF members were all immature boys, the Internet (along with many other things) would probably be a lot worst than it is today.
I disagree! I think there's a pretty good case to be made that if the IETF is not in fact comprised of immature hobbyists, its overall behavior is well described by a reversion to that lowest common denominator.
There are some great IETF success stories (mostly from a long time ago), but most of the best IETF products are the result of forceful and expert engineering done by just one or two people, carefully documented. You can see how much better that kind of work is than the IETF collaborative process by looking at the v2's and v3's of standards that started out the other way.
It's not a crazy observation to make. Think about the culture of heavily-engaged Wikipedia volunteers. Wikipedia is an amazing resource, probably the most impressive thing on the entire Internet, but most HN commenters would have no trouble calling it out for immaturity, insularity, and frivolity.
There are some great IETF success stories (mostly from a long time ago), but most of the best IETF products are the result of forceful and expert engineering done by just one or two people, carefully documented. You can see how much better that kind of work is than the IETF collaborative process by looking at the v2's and v3's of standards that started out the other way.
It's not a crazy observation to make. Think about the culture of heavily-engaged Wikipedia volunteers. Wikipedia is an amazing resource, probably the most impressive thing on the entire Internet, but most HN commenters would have no trouble calling it out for immaturity, insularity, and frivolity.
You disagree with the statement:
> If IETF members were all immature boys, [...]
and then you go on to make a point that agrees with OP, pointing out that IETF members are very mature engineers that are trying to solve hard problems.
> If IETF members were all immature boys, [...]
and then you go on to make a point that agrees with OP, pointing out that IETF members are very mature engineers that are trying to solve hard problems.
No. You've misread me. I do not like the IETF, and feel like even though there are lots of well-intentioned and highly-competent engineers working within it, its process and current overall membership produces results that are sometimes indistinguishable from "immature hobbyists".
Specifically, I think the argument that the success of the modern Internet is evidence that the IETF is "mature" is dubious and worth debating.
(Hey: just to be totally clear: I do not think the string "PRISM" is evidence of immaturity.)
Specifically, I think the argument that the success of the modern Internet is evidence that the IETF is "mature" is dubious and worth debating.
(Hey: just to be totally clear: I do not think the string "PRISM" is evidence of immaturity.)
[deleted]
The Internet is apparently in its "infantile" brain stage. Would we notice when the Internet's "memory" (the Web) becomes a cantankerously irreverent mentally unstable adolescent?
And we're imprisoned in this madness!
And we're imprisoned in this madness!
It's called "satire". It's truth speaking to power.
BTW, "I'm rubber and you're glue..."
Updated: And what's gender got to do with it?
BTW, "I'm rubber and you're glue..."
Updated: And what's gender got to do with it?
"Martin" is usually a boy's name.
Next up: a FOIA request for documents relating to the NSA's MOZILLA program in the mid 1990s.
http://mechanical-sympathy.blogspot.co.uk/