Citing anonymous sources is not established ETHICAL practice, it's corruption of the system. The roll of the journalist is to get sources on the record, not let them evade accountability by hiding behind anonymity. Anonymity is something that should be RARELY granted, not routinely granted as some sort of "long established practice".

What is the justification for anonymity here? The anonymous source is oath bound not to reveal secrets, so what is so important here that justifies them violating their oath to comment on an ongoing investigation? That's what we are talking about, if they are not allowed to comment on an ongoing investigation, then it's a gross violation of their duty to do so. The journalist needs to question their motives for doing so.

We all know the answer here, that they actually aren't violating their duty. They aren't revealing some big secret like Watergate. They are instead doing an "official leak", avoiding accountability by hiding behind anonymity. Moreover, what the anonymous source reveals isn't any real facts here, but just more spin.

We can easily identify the fact that it's propaganda here by such comments about the SIM farms being within 35 miles of the UN. It's 35 miles to all of Manhattan. It's an absurd statement on its face.

For example, it explains the specific problem of technical debt on failing to mask of high order bits by casting the low part to (u16). Years from now, when this leads to a bug, you'll no longer be able to fix the macro because inevitable some code will by that time depend upon high order bits in the low part.

Comments URL: https://news.ycombinator.com/item?id=44877104

Points: 2

# Comments: 1

Such redirection is often done on a specific port basis, so that trying to access different ports might produce a different result, such as a RST packet coming back from port 1234 with a different TTL than port 443.

There is so much cheating going with Internet routing that the TTL is usually the first thing I check, to make sure things are what they claim.

They are technically `undefined` according to the C standard, but are the behavior of every mainstream compiler. So much of the world's open-source code depends upon these that it's unlikely to change.

Using clang version 15.0, the first 2 produce no warning messages, even with -Wall -Wextra -pedantic. Conversely, the last 3 produce warning messages without any extra compiler flags.

The behavior of the first two examples are practically defined even if undefined according to the standard.

Now, when programming for embedded environments, like for 8-bit microcontrollers, all bets are off. But then you are using a quirky environment-specific compiler that needs a lot more hand-holding than just this. It's not going to compiler open-source libraries anyway.

I do know C. I knowingly write my code knowing that even though some things are technically undefined in the standard, that they are practically defined (and overwhelmingly so) for the platforms I target.

Other things use Ethernet. Routers, when connected to each other, often use a local Ethernet network to communicate.

Think of the TCP/IP Internet as it's own network, ignoring how routers physically talk to each other. Sometimes it's a directly link, a wire. Sometimes it's carrier pigeons. Sometimes it's WiFi. Sometimes it's Ethernet. Whatever it is, it's local to between the routers and does not extend outside that.

The writers the OSI Model wrote a specific blueprint, not an "observation of natural laws". When they said "session", they didn't mean the same things you conceive of. Instead, they meant a very specific problem of connecting dumb terminals to simplex links.

What you now call "sessions" is what OSI called "associations", and OSI defined them to be part of the "Application Layer".

I'm not sure you've even read the OSI Model. For example, the "Presentation Layer" is not defined to do the data format translation, but only to NEGOTIATE a common represenation. The actual data translation is still done in the Application.

This is the problem. People have not read and understood the entire model. They've not heard of "associations" and believe the OSI's use of "sessions" means anything they might call "session". They believe OSI was written as theory when it was not. They believe anything OSI terms they don't understand mean something else, mean some sort of timeless theory.

They are seduced by their own ignorance of the model.

RFC 1122 is a retconned version of the Internet model that tried to change terminology to fit OSI.

The issue is about education. People teach the model, or some variation of it. It teaches misconceptsion, such as how Ethernet and the Internet are integrated in a single network stack rather than being independent networks. It leads to professionals in IT and cybersecurity who continue to hold this misconception.

Ethernet and the Internet both provide the function of forwarding packets through a network to the target destination address. The MAC protocol and IP protocol provide the same theoretical function.

Where they differ is that Ethernet was designed to a be a local network, whereas the Internet is designed to be an internetwork. All it demand from local networks is that they get packets from one hop to the other. Ethernet does this for the Internet, but so do carrier pigeons.

The same is true for HTTP. Instead of thinking of it as a component of the network, think of it as something that rides independently on top of the network. In a hypothetical future whe we've replaced the Internet with some other technology, the web would still function.

For example, I describe how the OSI Model claims that layer #2 and #3 describe different functionality in the same network stack. I claim the opposite, how they describe roughly the same functionality in differnet networks.

Namely, both Ethernet and the Internet forward packets based upon addresses. The difference is that Ethernet does this locally while the Internet does this locally. Otherwise, the theoretical concept of packets, forwarding, and addresses are the same.

I claim that by 1981, the OSI Model was already obsolete and that it didn't fit well, that was not a good teaching tool, that it has done more to beffudle than enlighten students. The problem being is that if you learned according to the modle, you are not aware of what you misundertood.

It's not about people who already deal with this, like Nanog or systems programmers. Whatever model they've started with, they've developed a better one in their heads based upon their own expertise and experience.

It's about educators who continue to teach out-dated concepts.

Take Presentation Layer #6 as an example. It was created because in the 1970s, every computer model had a different character-set, and every terminal model different command-codes. It was therefore assumed that translating among these different formats would be a property of the network, that a fundamental step would be negotiating some common representation, like it is with FTP and Telnet.

This is no longer true today. Everything's Unicode. A PDF file on an EBDIC IBM mainframe is still encoded as UTF-8. Data representation is a property of the DATA not a property of the NETWORK. But people are slow to adapting to this paradigm shift.

As for "layering violations", I propose an alternative model where there are no layering violations. If real world conflicts with your model, the model needs updating.

You mean, you don't know the agenda. The "point" was data, namely: - the Washington game that leads to unreliable journalism - the fact that all Huawei's competitors have the same law enforcement backdoors, the same support contracts, and there's no evidence or even accusation that Huawei is doing anything different - my own personal experience watching Huawei support engineers using their "backdoor" "sidedoor" "frontdoor" access to gain intelligence information.

> implying it's reporting is inaccurate

Unreliable, not really inaccurate. It's clearly bad journalism violating clearly expressed ethical standards. That doesn't mean it's wrong, it doesn't mean the government official's accusations are false. It instead means that we can't rely upon them.

> straw-man argument that all telco manufacturers/operators do similar things for law enforcement so we shouldn't be concerned about Huawei's practices

I'm not sure you read the article. I make it clear that we should be concerned about Huawei even if their hardware, software, and support access are no different than any other vendors, because the Chinese government can lean on them in ways democratic governments cannot lean on their own vendors.

> comes off as blatant astroturfing

One of us does not understand "astroturfing". This is clearly an anti-Huawei piece that nonetheless tries to understand things from Huawei's point of view. I haven't worked with Huawei's engineers, I was working on a mobile companies systems when I saw Hauewei's support people log in via their VPN and gather national intelligence information.

The point is that everything can be true: Huawei can in fact be no different any competitor, doing at least as good a job preventing backdoors, and yet still be a national security threat due to backdoors. I believe it's good policy to forbid Huawei equipment in 5G deployments even if I doubt they have any special technical backdoors.

ZCash was built upon the Bitcoin codebase. This inherits a lot of bad decisions. Moral purity, demanding they start over again from scratch, just isn't practical.

The bug in question could have been solved had the simply compiled with minimal static analysis -- by which I mean -Wall.

C/C++ is memory safe if you turn on dynamic checking. Sure, it's twice as slow as C/C++, but still tons faster than nonsense languages like Ocaml or Haskell.

Here's how a business model works: you try a business model. If it works, great. If it doesn't, move on and try the next business model. You are either growing, dieing, or the zombie of living death. If it's the last two, get out now.

If you are a skilled person, then you can always get another job elsewhere, especially now that you've got "startup experience" on your resume. Conversely, if you aren't skilled, then that's probably causing your startup's failure, and that's not going to change.

Being overly optimistic is great when starting a company. You have to believe, against all odds, that you are going to succeed. But optimism death AFTER starting up, hanging on hoping things will change when they won't.

Growing companies have a chance of success. Dieing companies really don't. Zombie companies are even worse. Get out.