Please tell me what your relatives have been up to, I am preparing your tattoo.
3,123 karma · joined December 15, 2013
Where did I make the claim that logic could be used to cure alcoholism?
> The use of surrender is to admit you don't know how things work. At least not to the point to actually cure yourself of addiction.
Which doesn't make a Zagnut bar an agent that has power, does it?
So, you think that a candy bar is a power, in any way whatsoever?
> A lot of people let them selves get hung up on the higher power bit because they can't abstract the idea of surrendering to a non quantifiable or tangible thing
Because it's nonsense?
> (hence the Zagnut bar for those who can't surrender to the idea of love or the ideas of forces of nature)
Which makes it only more nonsensical?
> Believe me, I was one of those people for a long time. But my suffering got so great that I eventually had to admit to myself that I cannot do it on my own and I need to find something I hold sacred and dear.
... and then you did it yourself, thus demonstrating that you were simply wrong about not being able to do it yourself.
> It's better to believe a Zagnut bar could restore me to sanity, then to continue to kill myself with alcohol and drugs.
Only if that actually "restores you to sanity". And if it does, it was still you who "restored yourself to sanity".
> Again, the point is surrender. I am in no way saying the Zagnut bar is doing anything but inspiring hope in the alcoholic
Yes, you are. You are saying it's "a higher power". It's not. It's a candy bar. Possibly a candy bar that is inspiring hope in an alcoholic.
> And you are 100% correct that the work comes from inside, not a candy bar.
So, why all this dishonest mumbo-jumbo about a "higher power"? Mind you, this is not a therapeutic setting, this is a discussion about scientific evidence of efficacy.
No, of course, noone does, that's the point. Possibly, some people somehow think that they do (and even that seems a bit unlikely to me), but it just is a nonsense concept: You can, as a matter of semantics, not surrender to something that doesn't exercise power. You might as well be saying that you need to wash yourself, but you can also do so by looking at a horse. Looking at a horse makes you washed as much as following instructions of a candy bar makes you do anything, for lack of any washing effect in one case, for lack of any instructions in the other.
> I think the point is that you need some sort of mind hack to escape the paradigm of will vs. desire which has been a losing battle thus far for most addicts. it is ultimately your will that prevails, but you have to trick yourself otherwise for it to work.
That might well be the case, yep. And I see two big problems with not clearly stating that that is what's (likely) going on: In more than one place, it seems to cause harrassment of atheists, and I am not so sure it's actually helpful for mental health when people externalize the credit for the work that they have done themselves. And also, even if that's a hack that is needed in the "therapeutic context", a discussion about the scientific evidence of the efficacy certainly is not a place for such intentionally onfuscating language.
No, I have obviously not.
> Criticize ideas and policies; not groups of people.
Why? What, in your mind, is the problem with criticizing abusive religious people as a group?
The point here is that there is no "higher power" involved. It's other people or you yourself, or possibly both, neither of which in any meaningful sense qualifies as a "higher power", and either of which has a completely unambiguous, non-confusing term to refer to it: "Other people" and "yourself". The point is that it is dishonest to then pretend that somehow a Zagnut bar could plausibly be an agent helping you instead of simply saying the obvious: It's most certainly not the Zagnut bar, so what's left is you yourself and/or other people.
So, either you actually believe that a Zagnut bar is an agent that can help you out of your desparate situation by using its special powers. Or you are intentionally obfuscating the rather obvious fact that indeed, people do not need to surrender to anything or anyone, because obviously it's not the Zagnut bar doing the work, but rather exclusively they themselves.
Then you presumably aren't aware of how abusive religious people can be towards atheists, and that includes in AA groups.
Ending an abusive relationship is always an option.
That doesn't change your net worth, so it's a nonsensical example.
> I'm not saying your wrong, but can you provide a link to a reputable site such as CDC/WHO that supports your claim?
How does that need much of a "reputable site"?! It's an infectious disease with long incubation, infectiousness for a bit while not having symptoms, no vaccine and no cure ... what do you think would happen if we didn't do anything to prevent spreading?
Current R0 estimates seem to be around 3, so you would need 66% immunity to drop that below 1, currently the only likely way to get immunity is through infection and survival, so that's 200 million americans infected before infected cases shrink naturally.
In general, sure, but in any particular case? Essentially what I said before: It's not useful to exclude one or the other a priori, but it seems perfectly sensible to end up with purely technological solutions to some problems and with purely legal solutions to some others. Or phrasing it differently: It's not useful to set the balance of technological vs. legal solutions a priori. For some problems, a 99% technological/1% legal solution might be the right balance.
> My understanding is that EMV cards have a unique keypair stored on them, in which case it's not a big stretch to imagine a process that encrypts the exact record of what you bought with the card's private key, so it's a technical impossibility to decrypt without your consent.
Well, I'm not sure that that's the case currently, but given that they are smart cards, that sure would be a possibility. But it wouldn't really help much anyway, because that (a) doesn't hide who paid how much when to which vendor, which is already a huge privacy risk and (b) can not prevent collusion between vendors and banks. The vendor knows what they sold you in that transaction, there is no real way to force them to forget that. And also, if it's a card handed to you to your bank, how do you know they don't know the key? The only way to reliably enforce privacy there is to make the payment anonymous the way cash does.
Of course, one could maybe build something like digital cash, but that would probably look closer to bitcoin than to credit cards or bank transfers.
The point here is: It's not helpful to just say "solve this with crypto" if you can't really explain how crypto would actually solve the problem while sort-of dismissing the actual technological solution to the problem: cash.
> I'm a bit baffled - it seems pretty clear to me that legal changes have been a major part of our general progress as a society,
Well, yeah, sure!?
> and have in most cases been part resolving social problems.
Have they? That seems questionable to me, and also pretty difficult to even quantify. And also, it doesn't really get you to your claim anyway if is't just "most cases", does it?
> Sometimes we change the law to get to a desired solution, sometimes we change the law to enshrine an established solution.
And sometimes neither of those because technology simply makes the problem disappear?
I mean, I don't have any objection to legal solutions to problems, I just don't see how it makes sense to say a priori that legal measures must be a part of the solution to some problem, instead of looking at the effectiveness of various approaches and choose a good approach based on that. If legal rules regarding personal data are basically unenforceable and we have strong evidence that the ones we already have are constantly being ignored, then maybe the technical solution of using a payment system that doesn't give anyone even the chance to collect personal data to abuse is the effective solution? Why should we prefer a (more) legal solution when all the evidence suggests that it doesn't work?
I guess another way to look at this is to consider that legal solutions without some sort of technological foundation can actually not work for anything. What I mean by that is: Writing down a bunch of rules alone does not solve any problems. Only when there is some structure that ensures that those rules are actually being followed does a legal solution become effective. Which thus also means that if you make rules where it is impossible in practice to ensure that they are being followed, you do not actually have a solution at all.
How is that "of course"? Not excluding one or the other a priori is one thing, but why would it be the obviously right choice to always use a combination of both?
> Ban sharing of purchase data (legal measure) and also build systems to the data is encrypted with your on-card key (technical measure).
How would that "encrypting with your on-card key" thing work?
> Of course legal restrictions don't work well without technical measures, but anything privacy-related is a social problem first and foremost, so it needs legal solutions in addition to the technical ones.
How does it follow that when you have a social problem, you need a legal solution? That seems like a complete non-sequitur to me.
Oh, so how do you interface with your IP router for this?
There is some hope here ... that there will be new rules to ignore?
Like, how do you think such rules could ever be enforced effectively and in a way that the public can actually trust that it is being enforced effectively (to avoid chilling effects)? Plus, how do such rules prevent data leaks due to security problems?
It's like you want to build a system that is maximally vulnerable to abuses and then just declare that using those vulnerabilities is theoretically not allowed instead of using the technology that we know reliably preevents all those problems. How isn't that completely naive at best? Next we'll remove all authentication from IT systems and just make it illegal to log into systems without authorization? How well do you think that would work?
But also, in any case it's still a bad idea because the payment provider has the ability to just disobey your payment orders, and regulation doesn't help with that but rather potentially makes it even more likely "for security reasons". Payment providers use secret methods to decide whether your payment order is considered a security risk and then will prevent you from spending your own money based on their secret decision making process, or at least make you jump through unpredictable hoops before they allow you to spend your own money. That's a major security risk for you, in addition to all the security risks due to the well-known terrible IT security practices of banks as well as/in combination with the privacy risks of leaving a digital trail of your locations and purchases.
So, exactly what people always say exactly up to the point where someone demonstrates the exploit chain?
> and an attacker skilled enough to compromise an entire ISP to the point they can start doing these sorts of things has far better options available to them than anything we're talking about here.
So ... exactly what people always say exactly up to the point where someone launches some malware?
> There's a huge difference between mass-deployed malware and complex targetted attacks, which is a point you seem to continually miss in this thread.
Except there really isn't. Yes, obviously there is a difference, but you can't measure how well an attack can be scaled based on how well it has been scaled. Now, deploying rogue DSLAMs sure is really impractical to scale, so that's not a concern other than for targeted attacks. But abusing misconfigured ISP networks might very well be easy to scale under the right circumstances. Mind you that the attacker doesn't have to be an actual neighbour, it might very well be enough to compromise one machine in a neighbourhood and then start attacking the neighbourhood from there, and if this is a misconfiguration of a large ISP, you might be able to just leverage an existing bot net to compromise large parts of their customer base.
> More verbosely this could have been expressed as "NAT prevents inbound connections unless you have a NAT device that for some reason accept incoming packets for which it has no session
May I rephrase this slightly for clarity?
"NAT prevents inbound connections unless it doesn't happen to be paired with a stateful firewall."
Erm ... yeah, thanks for making my point for me? Except the actually non-confusing way to put this is "NAT does not prevent inbound connections, but stateful firewalls do", obviously.
> and pick a device on the private network to route these packets to
Could it be that you just don't even understand the attack? This sounds like you think that the owner of the router would have to explicitly configure a target that could be attacked or something? If that's how you understand it, you might want to brush up on how IP routing works.
> This "unless" is not normally needed though, as this is widely regarded to be a sufficiently difficult thing to achieve it's not worth mentioning.
Erm ... in other words: People are generally mistaken about this? Yeah, I agree.
> On every consumer firewall/NAT box I've ever seen, it was possible to configure firewall rules.
As in, if you want to make some internal service publicly reachable, you have to separately set up a "port forwarding rule" and a "firewall rule"? That sure is how professional equipment/software does it, but not something I have seen in home routers in a long time.
> I also note that although you've presented a couple of ways you might be able to send arbitrary packets at the public IP of the NAT device
No, I haven't. I have been talking about sending packets to the private IP addresses, the public IP address is completely not involved in any of this.
> this isn't yet sufficient to manage to connect to arbitrary machines behind the NAT device - you must also find a way to force the NAT device to accept packets for which it has no existing session.
Yeah, it seems like you don't understand IP routing or how the attack works.
No, you don't. You just don't. That's not how NAT works or how IP works. Unless there is a stateful firewall on that device, in which case removing the NAT does not change anything about being able to establish inbound connections.
To take the example of a common VLAN with your neighbours: What you need is the MAC address of the WAN interface of your neighbour that you want to attack. You might be able to just guess it, or you could find it via an ARP request, or maybe you just can see some random packets leaking from the switch. Then, you send an IP packet with your public IP address as the source IP address and your MAC address as your source MAC address to their MAC address as the destination MAC address and their internal IP address as the destination IP address. Their router, being an IP router with NAT but without a stateful firewall, will check their NAT state for the connection, not find it, check NAT rules, not find any either, therefore not rewrite anything, then do a routing table lookup which says that it should be delivered on the LAN interface, and then, potentially after an ARP lookup, deliver it to the LAN. That just is how IP works. Again: unless there is a stateful firewall on the device.
That's not really a useful measure, though, because this can be said about every single vulnerability used in a mass compromise up to the second when that mass compromise happens. The difference between "extreme levels of paranoia" and "common sense security practice" is someone somewhere deciding to use that particular vulnerability in some malware because random circumstances made a bunch of vulnerabilities that individually are kinda useless align to make an exploit chain.
> If you have sufficiently motified and skilled adversaries that they are prepared to start hijacking your DSL connection, you're probably screwed before you start.
Yes, that is probably true. But for one, that's not the only option I listed, and also, it doesn't change that the blanket statement "NAT prevents inbound connections" is not true and is easily misapplied by people who do not understand the details. Notice how noone ever says "NAT prevents inbound connections well enough for low-value targets, kinda"? And so, people actually believe that it does and then set up vulnerable company networks.
> The added protection NAT offers is that even if an inexperienced user accidentally opens up too much in their firewall, it's unlikely that this will make their internal home network publically accessible because ordinarily attackers aren't going to be able to send packets there.
Talking about contrived examples ... in consumer devices, you rarely can actually configure firewall rules? What you can configure is "port forwarding", and that then automatically implies that tt is actually open not not just NATted. So, at best that applies to inexperienced users setting up somewhat professional equipment, presumably in a context where security matters a bit more and targeted attacks are more likely, and where the belief that "NAT prevents inbound connections" now actually puts them at risk?
edit: And not only does it put them at risk, it also makes it hard for them to notice that they are vulnerable. If you have a firewall without NAT, it's trivial to check that inbound connections are refused. If a random access from anywhere on the internet is rejected, then your default DENY rule is probably effective. With NAT, not so much.
The threat model is really simple: If it's not under your control, then you shouldn't needlessly rely on it for security. And from the point where the wires leave your house, it's not under your control.
A random selection of possible attack scenarios:
- Hooking up a DSLAM to your DSL somewhere along the path to the CO.
- Compromising your ISP's edge routers through vulnerabilities/hard-coded passwords.
- If your router happens to also announce its RFC1918 prefix to the outside world and your ISP's misconfigured edge routers propagate those routes in their access network, being your neighbour might be enough.
- If your ISP is incompetent at configuring VLANs so you end up in the same VLAN as other customers in your area, again, being your neighbour might be enough.
(And yes, those are things that have happened.)
> It's perhaps worth pointing out that this discussion is very much in the context of a home network,
Except it really isn't. For one, the context was the home network of someone who would prefer to assign a public prefix on their home network. That is probably very much not the kind of stereotypical home network that is generally meant when you speak about "a home network" (i.e., a bunch of consumer devices on a WiFi). And also, the distinction really is only relevant in so far as specific home networks generally are not targeted, but that doesn't really change that it's still a bad idea to completely unnecessarily have a NAT run without a stateful firewall (the NAT needs to keep all the state that the firewall needs to keep anyway), and that as soon as you do have that firewall, NAT does not add anything at all.
So, yes, it might be that in some particular setups NAT without a stateful firewall is good enough for your particular needs. But that doesn't change that the general idea that "NAT prevents inbound connections" needs to die, because it is (a) far from true in the general case and (b) even where/in so far as it is true, you are almost always better off with a stateful firewall instead, so it's a bad rule of thumb both because you actually have to understand the limits of where it applies to not end up vulnerable and because the alternative actually works better with no downsides, except in rare circumstances, and even then, it's only an economical downside (namely: buying a new device that does things properly instead of using what you already have).
By sending a packet to them that has the destination address 192.168.1.20?
You seem to be making the assumption that the only way to send a packet to the WAN interface of a NAT router is through the public internet. While being able to do that widens the attack surface, it absolutely is not the only way, and your threat model is broken if you assume that it is.
> I realise NAT is unpopular with networking purists, but trying to claim that it doesn't prevent inbound connections seems to be overstating your case quite severely.
No, that belief is one of the big myths that keeps people configuring insecure networks.
> I'd also note that if your firewall is stateful or not is irrelevant for the point you were trying to make - oldfashioned stateless firewalls can also block inbound connections just fine.
That's true and it's not. Of course, you can block all connections with a stateless firewall, and thus obviously also block all inbound connections. But a stateless firewall is very limited in selectively blocking specifically inbound connections across random protocols, and especially so if it doesn't know detailed information about your network and services to infer what constitutes a packet establishing a connection, while with a stateful firewall you can essentially just say "drop inbound connections" without any further details about your networks, and it'll do a good job at it.
Plus, you could argue about whether, for example, dropping TCP SYNs but forwarding all other TCP packets actually counts as "blocking inbound connections", given that tons of potential "inbound packets" will be forwarded to your internal systems and you really rely on your internal systems not accepting any of them as "establishing a connection" or possibly just being vulnerable to those "inbound but not establishing a connection" sort of packets.
First, NAT is not necessarily stateful, just the common home router PAT or the telco CGNAT varieties of NAT are.
Second, NAT does not filter, that is what a firewall does. NAT only rewrites addresses. If there is no state for a connection in a stateful NAT, it looks up whether there are any rules for how to rewrite that connection, then adds a NAT state entry that specifies how to rewrite that connection (including, potentially, not at all), and in any case the (potentially rewritten) then gets forwarded--unless a firewall drops it.
Erm ... no, it's obviously not? Or at least not in a way that is relevant to this discussion. I am obviously not objecting to specifying languages that give you a lot of freedom in how you format things, so what is the point of bringing up that you could interpret the robustness principle to mean just that? I am obviously objecting to accepting input that does not conform to the respective relevant specification, and the fact that making languages more flexible in their formatting is often useful has no relevance to that whatsoever.
You interpret some term to mean a broad range of things, I point out that one of those things is a bad idea, and your defense is that one of the other things is good ... how is that even an argument? How does that change that what I pointed out is a bad idea?
> The alternative is strict adherence to whitespace then no need for a formatter, just have the compiler reject it and put the burden on the programmer.
No, the alternative is strict adherence to the language specification. Or, really, it's not an alternative at all, because there is zero contradiction between specifying a language with flexible whitespace grammar (or separator grammar or whatever) and then strictly enforcing that grammar (and thus obviously avoiding interoperability problems).
> Again your opinion is not shared historically, ECN is held up as an example of the robustness principle having been followed in most stacks, with some problem ones that did not causing some issues [1].
In other words: You position is unfalsifiable? If there are no interoperability problems due to everyone interpreting messages identically, then that is obviously due to the robustness principle, and if there are interoperability problems because implementations deviate in how they interpret messages, then that is also obviously a success of the robustness principle? Is there any scenario where that robustness principle would not count as successful?
> Then your points are just irrelevant? We can play this game forever. Just the fact the you are using HTML and not XHTML and TCP under that to write these should make some relevant point that you can't seem to see.
How is the fact that I am using something in any way relevant to the question of whether an alternative would have avoided interoperability problems and vulnerabilities?
> Or more likely all these developers weren't incompetent including myself, just when given the choice the strictness of XHTML lost to the liberalness of HTML proving Postels law again. Messy and robust won over clean and fragile again, that's the point, get it?
How is it relevant that HTML won? How do you connect from "technology X won over technology Y" to "therefore, technology Y would not have had fewer interoperability problems and vulnerabilities than technology X"?
Why do you answer every question as to technical properties of a technology with "it lost" or "it won" while completely failing to say anything at all about the technical property being discussed?
NOONE DENIES THAT HTML WON OVER XHTML.
Also, it seems you almost completely ignored the central explanation of my previous post, simply to repeat your previous points as if I never had said anything. I am happy to read your explanation as to where my analysis is wrong, but I am completely uninterested in reading over and over points that I repeatedly explained why I don't agree with them with no insight at all into how my reasoning is wrong.
Erm ... you do understand that, you know, there is feedback involved in this? That I am obviously not saying that noone would ever have typed broken HTML into a file if browsers had rejected broken HTML from the start?
I mean, it's even the norm for implementations of other computer languages to be rather strict about syntax, and it doesn't hinder their popularity with the same audience. The exact same people who produce garbage HTML do so using Perl or PHP or Ruby or ... whatever. And whatever you otherwise think about those languages, none of them will just make shit up when there is a syntax error in your program, they will simply reject it. And no, that does not mean that I am claiming that noone has ever made a syntactical mistake when writing code in those languages. But, you know, people are actually capable of fixing those mistakes when they are pointed out to them.
> So you never heard of ECN? The ECN bits being set where technically incorrect depending on how pedantic you where in the interpretation and some stacks rejected packets if the bits weren't set to zero. Due to he robustness principle most stacks ignored these bits allowing others to use them for ECN, allowing a graceful update to the spec. The stacks that took your stance however and rejected where simply roadblocks in the adoption.
Erm ... what? That's almost fractally wrong!?
None of the ECN problem was one of pedantry, it was simply one of a broken specification, namely the TCP specification. "Reserved for future use. Must be zero." is simply a bad specification. If you specify an extension mechanism, you have to always specify how the extension mechanism is supposed to work. What you call the pedantic interpretation is a perfectly valid interpretation of what the text says. You are just looking at it in hindsight, with the idea that it's supposed to support the operation of ECN, and then it's obviously a problem--but people who implemented TCP stuff before there was ECN could not possibly know that that is how people would expect to use this if the TCP specification doesn't specify that. There is nothing wrong with extension mechanisms that work by having the recipient discard messages with flags it doesn't know. That's just not what ECN chose to do, but that is kinda ECN's fault. You might just as well have ended up with a situation where someone would have tried to build an extension that assumes that recipients discard segments with unknown flags, and everyone would have been pointing fingers at those who chose to ignore the flags instead, and how they were pedantic to ignore the flags just because the specification does not explicitly say that such segments are invalid. It's just an accident of history that most implementations chose to ignore unknown flags, and therefore people now point to the exception, without any basis other than them being the majority.
Also, obviously, the "robustness principle" did not allow for a graceful update to the spec. The fact that a graceful update was not possible is the whole reason why you mentioned ECN at all. And that is not necessarily a result of failing to follow the robustness principle, as the robustness principle really doesn't tell you anything useful. All you can do with it is to point at things in hindsight and say "if everyone had built this the same way, then things would be compatible now!" But the robustness principle is useless for actually achieving that. For any format specification, there is an almost infinite number of ways you can deviate from the specification where humans could look at any individual one of those deviations and come to an agreement as to how that deviating message could reasonably be interpreted. And any one of those deviations could in principle be implemented as part of the corresponding parser. But implementing a parser that "correctly" interprets all of those possible deviations is at the very least a major undertaking, and usually even impossible due to contradictions between various deviations when they appear in combination.
And that is why hindsight is misleading: In hindsight, you only see one particular (small set of) deviation(s) causing interoperability problems, and it would almost always have been possible to make every parser coherently interpret those deviations just fine, and if everyone had done that, then you would not have any interoperability problems. But that isn't the perspective of someone who initially builds the implementation. They can only either strictly follow the spec (which works perfectly if everyone does so and the spec isn't broken) or they can increase complexity of and effort required for their implementation an order of magnitude or more to accept close to anything that could happen (which noone does for obvious reasons) or they can implement a random selection of deviations they like (which then leads to interoperability problems and the view in hindsight that everyone else could easily have done the same, which, of course, they couldn't, because they couldn't know what others were doing). Of course, there is a simple solution to that last approach: If you want to implement deviations from the agreed-upon spec but you don't want to run the risk of creating interoperability problems, you could get together with all the other implementers and talk about which deviations everyone is going to implement. But obviously, that's just the first approach in disguise: After you have agreed on the deviations, they aren't deviations anymore, you have simply created a new spec, and everyone then strictly follows that new spec.
Essentially, what is happening here is that you see one interpretation of something that the spec doesn't actually specify as obvious. And then you claim that the solution to interoperability problems is that everyone does the obvious thing. But you fail to recognize that the whole problem we are trying to solve with specifications in the first place is that what seems obvious is different for different people. Which is why this (a) can not work and (b) obviously in practice does not work. You can not solve the problem of people having different approaches to problems by simply saying "they should just all have the same approach" while at the same time saying that methods to create agreement (i.e., specifications) should not be taken too seriously.
> I'm not ignoring anything, I am just pointing out reality, the real world is messy and the stacks that try to keep working under messy conditions seem to be prevailing. Its not pretty and I don't deny the issues that arise, but here we are communicating on the largest most successful computer network ever built using a protocol and a markup language built with Postels law in mind.
Then your points are just irrelevant? I never said that broken systems can not be successful, did I? Yes, there clearly are evolutionary advantages to externalizing costs, and taking risks can pay off. But there are also other parties who have to pay those externalized costs, and taking risks can also end in a catastrophe. Externalizing costs is still an asshole move (and is generally frowned upon by society when people understand that that is what is happening) and whether the risks taken by the web, for example, have actually paid off is far from obvious.
Also, possibly all of this was built with Postel's law in mind. But what I would be interested in is whether that was to our benefit. Just because something was a factor in creating a certain overall positive situation does not mean that therefore that factor made that situation better than if it hadn't been there. In particular, evolutionary success does not mean that a different approach would not have produced a better result.
> I think most who know the history there would disagree with this opinion [1], it was obvious to me at the time why XHTML would fail even though I thought it a cleaner solution, I realized thats what was holding it back. It was much better to see your page come up with maybe a weird rendering artifact than just have the browser render nothing and throw an error if some small part was malformed.
How does that contradict what I said? Yes, it was obvious that XHTML would fail due to the massive incompetence of developers ... your point being?!
> Uh gee I don't know maybe Postel's law is kinda relevant when discussing TCP because Postel wrote the spec you know like what you asked in the post before? What kind of game are you playing here?
I am not sure what kind of game you are playing, but I had the impression like you were trying to make a point and not just state the historical fact that that's where Postel formulated the "robustness principle". Yeah, I agree, that's what he did. And it was a bad idea.