I have a better idea. Vote with your eyeballs.
With some regret, I'm moving more and more to other sites (e.g., SoylentNews) as
I know, it would be much better to get back to the "good old days," but that's not (IMHO) going to happen.
Do you hear that,
Citations please. How many municipalities have created their own local last-mile implementations? How many have gone bankrupt? You're talking out of your ass and it smells that way too.
A quick search found Municipal broadband expansion blocked in many states. I'm not claiming that the municipalities are going bankrupt (like what happened with Provo, UT and why Google was able to buy their fiber for $1), but I know that's the reasoning being presented to the state legislatures. I wouldn't be surprised if a lobbyist could go before your average state representative and say "Municipalities are doing X, and going bankrupt over it. You'd better stop X in your state so you won't have to bail out your Municipalities", and the representative wouldn't spend time double checking the reality of the situation. They just know that they wouldn't want to deal with a budget crises where all of their municipalities are going bankrupt.
That such arguments are being made may very well be the case. It's certainly plausible that those with vested interests would make such an argument. I'm not going to waste my time reviewing transcripts of debates in 20+ statehouses to determine if it is, in fact, the case.
That said, just because such an argument may be made, doesn't mean it's true.
You contradict yourself by first saying:
I believe that states have started passing laws against municipalities laying their own fiber because the states are tired of bailing out bankrupt municipalities who have done so. [emphasis added]
and when asked to justify your beliefs, you say:
I'm not claiming that the municipalities are going bankrupt
So. Which is it? Is there evidence on either side? If you wish your argument to be taken seriously, you should be able to back it up with some evidence. If not, it's hand waving at best and dishonesty at worst.
The idea behind the "increase power" and "repeat as necessary" parts was that if you increase power *enough*, you'll end up with line-of-sight, even if you didn't have it to start with. (i.e.: You'll burn a hole through any intervening materials.)
This is also known as brute-force data transmission, and is akin to the old-fashioned, much lower bandwidth LART known as the 'clue-by-four'.
It's also basic physics.
Pro tip: The earth is round.
Grammar Nazi FAIL, motherfucker. Report to the gas chambers pronto! You are not one of us!
Not a fail at all. GP nailed it. Perhaps the OP will learn an important lesson: 'tis better to remain silent and be thought a fool, than to speak and remove all doubt.'
And your use of "motherfucker" is kind of strange. Actually, any use of that is kind of strange, IMHO. Most of us are motherfuckers and proud of it. As is anyone who has sex with a female who has given birth. I would hope you will still fuck your wife after she bears a child, especially if you want more children. It does work that way you know. Making sure because you seem to be ignorant in so many other ways. Oh, wait, I get it. You don't have a wife, in fact you never get to fuck anything other than your secondhand fleshlight. And since the only female you ever interact with is *your* mom, that must seem rather inappropriate.
Things are so much clearer now. Kisses, sweetie!
Upgrade the Municipality to FIOS service to a COLO facility.
I believe that states have started passing laws against municipalities laying their own fiber because the states are tired of bailing out bankrupt municipalities who have done so.
Citations please. How many municipalities have created their own local last-mile implementations? How many have gone bankrupt? You're talking out of your ass and it smells that way too.
Or it will never happen until you can figure out how to pay for it. Higher taxes? Higher fees?
Paying for it is not a big deal. Pay for it the way all public works projects are paid for, with a twist.
1. Create a non-profit corporation to implement and manage infrastructure owned by the local government.
2. Issue bonds to pay for the infrastructure.
3. Sell access to the infrastructure to ISPs who sell internet access and compete on price/service/features.
4. Use the revenue for maintenance, bond repayment and upgrades.
5. Profit^H^H^H^H^H^H High speed last mile with lots of competition.
Well, that was easy. Next!
Well, in the US, rather than tons of red tape, bureaucracy, and regulations...how about simple rules one at a time as needed.
1. You can't price based on traffic..all traffic is treated the same.
Oh, you mean Title II classification?
Distinction Without a Difference - The assertion that a position is different from another position based on the language when, in fact, both positions are exactly the same -- at least in practice or practical terms.
To clarify once again. The distinctions drawn are not based on nomenclature. There are specific and important technical differences which have real impact on the discussion.
As I read your post again, I'm sorely tempted to respond in kind. However, I understand that you thought I was assigning ignorance of this particular area of knowledge to you as an insult (although you did do so in your original reply -- note that I simply repeated what you said first), rather than as a simple statement of fact. In your position, I would likely have responded similarly.
My apologies. I mis-stated both what you and I posted. The above paragraph should read:
As I read your post again, I'm sorely tempted to respond in kind. However, I understand that you thought I was assigning ignorance of this particular area of knowledge to you as an insult, rather than as a simple statement of fact. In your position, I would likely have responded similarly.
Distinction Without a Difference - The assertion that a position is different from another position based on the language when, in fact, both positions are exactly the same -- at least in practice or practical terms.
To clarify once again. The distinctions drawn are not based on nomenclature. There are specific and important technical differences which have real impact on the discussion.
As I read your post again, I'm sorely tempted to respond in kind. However, I understand that you thought I was assigning ignorance of this particular area of knowledge to you as an insult (although you did do so in your original reply -- note that I simply repeated what you said first), rather than as a simple statement of fact. In your position, I would likely have responded similarly.
Your provided links show that "packet sniffing" and "traffic flow analysis" are not different concepts in practice. The difference is in how the collected data is analyzed or for what purpose.
This is an incorrect conclusion. Packet sniffing and Netflow analysis are significantly different in both theory and practice, both from the standpoint of data collected, as well as the method(s) of collection. Granted, if you are sniffing packets, you can perform a similar analysis, but that's both completely impractical (and in the context of the research) self-defeating. Attempting to sniff all packets off an IX Node requires mirroring all packets. Which would almost certainly cause serious congestion problems and be detected almost immediately. Collecting Netflow data from same wouldn't have a noticeable effect on the IX Node's network links.
Just to clarify that point. Collecting Netflow (or similar management protocol) data is significantly and demonstrably different (in the attack mechanisms posited by and the methodology employed by the researchers) in both theory and practice.
Yes, in a scenario with network links that carry much less data and both endpoints are known, packet sniffing and Netflow data collection *can* provide similar analytical results (I've done both myself), identifying data flows across large portions of the Internet (i.e., encompassing all or at least a significant fraction of Tor entry nodes -- in that the goal is identification of a device at an unknown location anywhere in the world) is a completely different animal.
I could go on, but those are the high points. The above should be obvious to anyone who has a reasonable amount of experience with IP networking. Perhaps I should have been more explicit, but given that this is a tech site and the article concerns a scholarly paper about networking, I assumed a certain level of working knowledge. My mistake.
There is no need to be rude or presumptive about my level of education. I shall explain what I meant in more depth to clear up any misunderstandings. OP said: "So if you can spy on the traffic from the user to the tor entry node, and can spy on the traffic leaving the tor exit node at the same time... then you can tell that the traffic you saw going to the entry node is linked to the traffic leaving the exit node" You said: "If you can correlate the server-->exit node flow to a specific entry node-->client flow, you've just identified the client outside of Tor." Distinction Without a Difference - The assertion that a position is different from another position based on the language when, in fact, both positions are exactly the same -- at least in practice or practical terms. Your provided links show that "packet sniffing" and "traffic flow analysis" are not different concepts in practice. The difference is in how the collected data is analyzed or for what purpose. For the purposes of this discussion where analysis of collected packets is for identical purposes, this is also a distinction without a difference. "A packet analyzer...is a computer program or a piece of computer hardware that can intercept and log traffic passing over a digital network or part of a network." "NetFlow is a feature that was introduced on Cisco routers that provides the ability to collect IP network traffic as it enters or exits an interface." If you feel I have misinterpreted your statements, I would appreciate additional feedback.
My points were literal, rather than pejorative. Sniffing packets is gathering the *actual* packets. Netflow collects statistics about packets being transmitted/received. Do you see the difference?
GP stated "Good luck being able to sniff traffic on *both* ends." Firstly, traffic isn't being "sniffed." Secondly, With Netflow, it's not necessary to have packet sniffers on the specific links used in order to gather packet statistics.
What is more, since context is everything, GP was responding to my assessment of the paper (you know, the point of the article) and misunderstood the methodology used by the researchers. I explained.
If I (here and in my original post) have been unable to explain to you both the difference between packet sniffing and Netflow analysis and/or why GP misunderstood the methodology employed by the researchers, I suggest you read the paper yourself.
TL;DR : Packet sniffing != Netflow. Methodologies have impact on results and should be understood.
Should you want to criticize me, my reasoning or my (or at least your interpretation of it) tone for any other reasons? By all means, go right ahead.
Your interesting anecdotes do not in any way contradict the FACTS. I was using SysV in the early 80s. So what.
You might as well point out that BSD's first release was in 1977. Doesn't in any way change the 1.0 dates for FreeBSD and Linux.
And your fetish about 1.0 versions doesn't change the facts either. Those facts being listed in the posted link. Have a lovely day!
It seems to me that you just said the same thing as the parent post.
It seems to me, that you don't know the difference between packet sniffing and traffic analysis using Netflow and similar tools.
The links are there for your edification. You're welcome.
According to the latest official figures, 43% of all statistics are totally worthless.
