7 ms·
Why can't you code you implementation to safely ignore new protocol elements? They aren't asking you to support the new elements, just ignore them.
by Narkov 8y ago
Why can't you code you implementation to safely ignore new protocol elements? They aren't asking you to support the new elements, just ignore them.
- namibj 8y agoYou can. But who is going to make sure you don't skip this part and make more profit than your competitor?
- saghm 8y agoGoogle, apparently
- pdkl95 8y agoAnybody that doesn't want to introduce crashing/fatal bugs that disrupt productivity? Skipping checks[1] and making assumptions about input[2] is an irresponsible disregard for basic security. This is about basic programmer competence, not time a consuming feature that might impact your development costs relative to your competitor. You are not going to make more profit by leaving out the "default:" case to your switch/case statements that skips parsing for unrecognized elements. [1] https://archive.org/details/The_Science_of_Insecurity_ https://archive.org/details/The_Science_of_Insecurity_ [2] https://media.ccc.de/v/31c3_-_5930_-_en_-_saal_6_-_201412291400_-_funky_file_formats_-_ange_albertini https://media.ccc.de/v/31c3_-_5930_-_en_-_saal_6_-_201412291...
- TeMPOraL 8y ago"Basic programmer competence" is not something you can consistently expect from people in the industry. Be it a bad day, general carelessness, or business pressures - there are many reasons to cut corners.
- caf 8y agoThe problem isn't leaving out the 'default' case. The problem is coding it as default: return DROP_CONNNECTION_AND_BAIL;
- pdkl95 8y agoYes, which is why I really like the idea of proactive enforcement with random expected-to-be-ignored tags/parameters. I'm arguing against the idea that leaving out the last part of this for (item = params->head; item; item = item->next) { switch (item->type) { case KNOWN_PARAM_TYPE_FOO: // do normal stuff break; /* ... etc ... */ IGNORE_KNOWN_PARAM_TYPE_BAR: // fallthrough - BAR explicitly uses default handling default: continue; // skip unknown parameters } } is evidence of incompetence, not a strategy that will "make more profit than your competitor". Also, as the BAR constant suggests, you probably already have code that skips unrelated fields. While the difference in programmer time is almost always trivially small, sometimes it might be zero.
- mathw 8y agoUnfortunately incompetence can sometimes lead to increased profits in the short term. Why else is there so much horrendous software out there?
- namibj 8y agoYou can trust in basic programmer competence when there is a certification the programmer has to loose if he displays incompetence, like done for other engineers and also doctors and lawyers and many more. Until then, you have to make the financial incentives in the short and long term such that they lead to desirable behavior, e.g., producing non-barfing middleware in this case.
- tedunangst 8y agoCrashing on unknown extensions doesn't seem like a profitable differentiator.
- sanxiyn 8y agoIf there is no unknown extensions in the wild for years it can be.
- namibj 8y agoWho's gonna notice your miss-handling of not-yet-used-in-the-wild parts of the protocol? If the answer is no one, then it doesn't matter for your profits, and not caring about this case when coding increases your profits. Google now tries to answer with chrome users.
- tedunangst 8y agoAgain, the development costs of "goto drop" and "/* ignore */" are quite similar, so it's unclear where these profits are coming from.
- namibj 8y agoNot spending time thinking about handling those, not debugging anything related to them, etc. The code might look almost the same, but it's always a cost of how to get there. And the code in these middleboxes not rarely smells.
- lotyrin 8y agoThey come from the cost savings made by a pointy-hair telling that smart aleck code monkey that bothered actually reading the spec that his concerns aren't going to delay the ship date or go into the budget for developer time -- but you know maybe in six months (every six months, it'll be six months out) we can totally revisit that. Then it ends up in production in too many customer sites with IT that avoid updating stuff (because the updates frequently break things, which is a pain) that it's too late to fix it now. The concerned forward-thinking developer moves on to (slightly) greener pastures to rinse and repeat and the project gets handed to an off-shore team who don't comprehend the difference between current behavior and specified behavior of a product - yet another bold cost-saving measure for pointy-hair to use to argue for his bonus.
- kevincox 8y agoThey tried this. This effort is explicitly because current implementations failed to correctly ignore new features. Since the previous approach was shown not to work in practice they are trying this approach which is intended to make incorrect implementations more obvious.
- cesarb 8y agoSome middleboxes treat new protocol elements as a sign of a hack attempt, and drop the connection. It's not a coding error, they're doing it on purpose. Which is why the current push to have as much as possible in the encrypted portion of protocols: so these crazy middleboxes can't prevent protocol evolution.
- marshray 8y agoIf the standard says a message can be up to 4096 bytes long, but for 15 years the message in practice is always under 250 bytes, there are going to be some implementations that just use a fixed size buffer smaller than 4096 bytes.