We recently had to move a client over to IPv6 faster than intended because we couldn't get a block of clean IPv4 static addresses from the ISP. That problem is only going to get worse over time.
Meanwhile, I have the opposite problem with Eclipse internet. One of my customers needed a new internet connection (we're talking 100Mbps leased line, not a poxy ADSL), so we recommended they check the prospective ISPs supported IPv6. "Yes, we support it " says Eclipse, so they went with them. When it actually got installed, Eclipse sent through the IPv4 details, so I replied asking for the IPv6 details too... they replied saying they didn't offer IPv6 to customers yet. When pressed further, they said "Our network fully supports IPv6, but we don't offer the service to our customers" - what a complete waste of time. (Of course, the customer doesn't see it as important enough to make a big fuss about, but if it were me I would be fuming about having been missold a reasonably expensive connection).
I don't know for a fact, but I'm willing to bet that computer in the college dorm room used NAT.
I'm willing to bet it didn't. Certainly when I was at university, everything had an unfirewalled global scope IP (this was not that long ago, but still before the days of evil on the internet that required everyone to have a firewall).
Why get rid of NAT?
Because its an almighty pain in the arse. It breaks all sorts of things, and if you haven't discovered that yet, you presumably have never managed a moderately complex network or done anything other than plain old web browsing.
I use NAT for my home intranet. It's easy - two lines in my iptables config file. And everything works fine.
No it doesn't - the things you use it for presumably work fine, but there's all sorts of technologies that really struggle to work through NAT (and for good reason, not just because of a flawed protocol design). Throwing NAT out is a good thing - it makes networks less complex and more reliable.
"Google clamps down on Spam, Intrusive Ads In Apps from competitors
I can't think of any Google applications on Android that even use ads...
In any case, I'm happy to see all the apps that include AirPush get banned from Google Play - I have no time for any developer who thinks its a good idea (especially since they never warn you that they are using AirPush when you install the app).
I'm not sure about jelly bean.. but my older android phone has all sorts of crapware put on by the carrier, that I cannot uninstall I have a notification every single day about updates being available for them.. I have never used them, see lots of comments about the update causing problems, and no way to uninstall.. can I at least tell it to stop checking for updates?
If you remount/system as readwrite (requires root) you can just uninstall the bundled apps in the usual way.
No fragmentation issues either device capabilities, or OS version issues.
I don't see that ever happening. This would require all devices to have exactly the same capabilities - Apple managed that with the origional iPhone by virtue of there only being one device. However, the original iPhone was far too lacking in features to be of use to many of us, and all iPhones have been far too expensive for many (that's largely down to Apple's inflated pricing - the iPhone 4 and Nexus S are pretty much identical hardware, but the iPhone 4 was almost twice the price when these phones were reasonably new. However, if you dictate that all hardware is going to be the same, even without artificially inflated pricing that means people are going to end up paying for hardware far more capable than what they actually need). As soon as Apple released later generations of the iPhone, there were multiple iPhone devices in the wild with different hardware capabilities - the only way to avoid this would be to have only produced the original iPhone rather than providing an upgrade path.
So no, we're never going to be in a situation where there are no fragmentation issues WRT to device capabilities - if your software requires a device with gyroscopes then its not going to work on a device that hasn't got gyros, for example. There will always be a new technology around the corner in the next generation phones and unless everyone upgrades there will be fragmentation caused by the older generation still being around. And I may be unusual, but after spending £300+ on a phone, I tend to use it until it breaks rather than upgrading it every 6 months.
There is, however, confusion caused by the wide variety of hardware on the market, largely because no one seems to publish any kind of information on what you can expect the hardware to do - I can look at the specs for a phone, which tell me how much RAM it has, how many CPU cores and what speed they run at, etc. but even as a techie I can't actually tell you what you can expect the phone to be capable of - sure, more is better, but when you come to balancing spec against cost it would be nice to have some indication about where the spec becomes "good enough" for what you're planning on using it for. There _is_ a market for low-spec phones, and there is a market for high spec phones, and these markets should continue to give people the choice, but it would be nice to have some good information about what limitations going for a lower spec device will place on you.
Native code and complete platform API
I was under the impression that Android had a native API? (Note: I've done no Android development, so have no first hand experience of this)
Same code executable on desktop
Technically you could do this by providing an interface library, much the same as Wine does for Windows applications. However, at the moment I think this is of limited value. The UI paradigms for mobile and desktop are currently very different. In the past, MS has tried to push a desktop UI onto mobile devices, with reasonably disasterous results. Now MS are trying to do the opposite - they are pushing Metro (a mobile/tablet UI) onto the desktop and I expect to see similarly disasterous results (I have briefly used Metro, and frankly I found it unusable to the point where I had to ctrl+alt+delete to get task manager up and actually kill the applications since I couldn't figure out how the hell to actually exit back to the "start menu").
I do believe that a UI that is shared between all devices (phones, tablets, desktops, etc.) is possible and even desirable, but the current efforts don't achieve that because they push the limitations of one device upon all devices. For example, a small screen device usually runs everything in full-screen mode, but this is the last thing I want t
No one else offers ubiquitous computing with full functioning business productivity software available on every device a person owns. No one else is even trying.
Thats because the smart developers ensure their software uses open standards so that they don't need to make their software available on every device a person owns - other people will do it for them, and the various softwares from different vendors will interoperate. MS, on the other hand, try to lock up all their standards so no one can write interoperable software, which means that MS have to support all types of device (note: all _types_ of device, not all devices - I can't get Windows Phone for my Samsung Captivate Glide, I would have to buy a new device).
Personally, I prefer to have a choice of application and device, rather than the data format / protocol on one device dictating that all my other devices must run software from the same vendor in order to interoperate.
I remember it distinctly, because I was waiting for them to screw up and claim he invented the internet. They never made that mistake, but it appears that Mr. Boyle did, since he had his lovestruck teens thanking him for their cell phones.
I don't know anything about Korean law, but aren't they liable as well if they purchase goods that are stolen, or have a reasonable likelihood of being stolen?
My experience here in the UK is:
I used a popular car insurance comparison website when I was shopping around for cheaper car insurance. On this website I had to enter various personal details such as name, address, date of birth, claim history, etc. Soon afterwards I started receiving cold-calls in connection with the accidents in my claim history. These calls usually started by claiming to be from "the insurance company" and implying they were my insurer, without actually providing the name of the insurer. Initially I wondered if "the insurance company" might actually be the other party's insurer rather than mine (so I was very wary), but when pressed for more detail they put up various BS claims about how they couldn't give me the information I asked for because of the data protection act - I do know my rights under the DPA and I pushed further and eventually it turned out they were actually personal injury lawyers. They wanted me to make a personal injury claim, and still encouraged me to make a claim even after I pointed out that no one was injured, and in fact no one was even in the car when the accident happened (it was parked, someone drove into it).
Some time later, I started getting calls from other companies (this time in connection with PPI, which isn't even targetted advertising any more since I've never had PPI). They insisted that they didn't need to screen calls against the telephone preference service because I had "agreed" to receive them (the ICO has confirmed that this is not true - they still need to screen against TPS). Eventually, after a lot of correspondance with these cold-calling companies (who were surprisingly cooperative), I discovered that some of the information had come from a marketing company that I had never heard of, but this company had very clearly acquired my details from the insurance comparison site (they even ran their oen insurance comparison site, although this wasn't the one I used).
Unfortunately, things pretty much stop here - the company that has been selling my details claims that they phoned me and I verbally agreed to receive promotional material from "partner companies". I can neither confirm nor deny whether they phoned me, but I am certain I would never have agreed to this. Unfortunately they have so far declined to provide any evidence to support their position, I have no evidence to support mine, so it's my word against theirs. As far as I can tell, they have taken my details and illegally sold them to a bunch of people, who have then sold them to a bunch of people, etc. The people they sold them to believe that the details the bought were authorised by me, the people further down the chain have even less reason to believe that the information is being distributed illegally.
In short: 1. Although the company responsible for illegally selling off my details could probably notify everyone they've sent the data to, they have no inclination to do so. 2. The data has been bought and sold so many times that there's no way to remove it from everyone's possession - it will continue to be bought and sold and there's nothing I can do to bring it back under my control. 3. The ICO seems disinclined to help, probably because they already know there's no way to stop the dissemination of this data now it has spread so far and wide.
The situation in SK would likely be similar - the original marketing companies may well have bought the datsa in good faith, and have now sold it to a bunch of other companies, who have sold it to more companies, etc. There's no way to retract this information now - its been spread too far and wide and the people lower down the chain won't have any idea WTF it came from originally.
The only solution to these kinds of problem that I can see is to outlaw the transfer of personal data between companies wit
Who cares? Most of the DirectTV channels are complete crap anyway. When I had directTv, I only watched twelve channels to begin with. DirectTV literally has thousands of channels.
I dropped Sky here in the UK when I realised that I was only watching 4 channels - BBC 1, BBC 2, S4C and Sky One. The only stuff I was watching on Sky One was House and Eureka, which I can buy on DVD for less than I was paying for my subscription. BBC channels and S4C are free anyway...
I can't in good conscience recommend using Skype to any business for communications, which can often be sensitive, as long as Microsoft is putting in backdoors. Need to find another platform.
I've been recommending SIP solutions for business for years. The Grandstream phones work very well when paired with Asterisk servers.
To be honest, I don't know how this news changes anything WRT Skype - its always been a closed system where the security is completely unverifyable (and the software has been designed to make discovering what its doing really hard), if you trusted it before you were an idiot.
Port forwarding has to be triggered by the *downstream* host.
Until that host makes an *outbound* connection the NAT doesn't know or care about who to send inbound stuff to.
Correct. This is identical, whether you are using TCP or UDP - in order for a host outside the NAT to send anything to a host inside the NAT, the inside host has to have already sent data to the outside host (within a reasonable time period). So as I originally explained, using TCP in this situation provides no benefit over UDP with respect to NAT traversal.
And UDP forwarding has to be triggered by an outbound UDP packet just the same as with TCP forwarding, by an outbound connection, which means that unsolicited inbound connections or UDP packets not associated with a preexisting outbound connection have no way of finding the host they are meant for.
Correct again. And again, this is identical whether you're using TCP or UDP (as you've just said yourself)... so I don't quite understand what you're arguing about:
If you are behind a NAT, in order for a host outside the network to contact you, you must have already contacted it (so that the NAT knows where to forward the traffic). This is true whether you use UDP or TCP - TCP offers no advantage(*) for NAT traversal over UDP since in both cases, your internal host must have already "connected" with the external host in order for the external host to send any data.
Stop being a moron and learn how NAT actually works in the real world
I do understand how NAT works, this is what I do for a living. Nothing in your post has disputed my original point, all you've done is screamed about how I'm a "moron" and then agreed with my original comments. If you feel this is incorrect, please put together a concise reply that describes exactly what you think I got wrong rather than resorting to name calling.
typical broadband consumers where the NAT device is under the control of an ISP that has every incentive to not cooperate with consumers who want to run a personal server of sorts.
Typical broadband customers (at least in the UK) have control of their own routers. But this is beside the point - no reconfiguration of a typical NAT is required in order to use UDP in the way in which I have described.
Treating it as a stateful firewall only works when the NAT is under the same administrative control as the host behind it.
No. A NAT fundamentally requires stateful packet inspection. You cannot reasonably have NAT without stateful packet inspection, so treating a NAT like a stateful firewall is entirely reasonable in this circumstance. Note that I made no comment about the need to reconfigure the SPI since this is not necessary, therefore who's administrative control it is under is irrelevant.
I'm saying it's bad for people behind the NAT because it prevents them from receiving inbound connections...unless they want to beg the ISP for a business grade connection.
No, it doesn't. As I said, UDP will traverse a NAT just the same as TCP - NAT employs the same techniques as a stateful firewall.
The crap is that it is going to be bad for the whole planet, just like the japanese fiasco was.
Sorry, could you explain how Fukushima was "bad for the whole planet"? The radioactive fallout was certainly nowhere near a global scale (_trace_ amounts were observed globally, not dangerous amounts). Radioactive material from the accident has been found in food produced within a 200 mile radius - yes, a significant accident but you'd be hard pushed to say its affected peoples' lives globally.
In fact, the only real global effects Fukushima has had on peoples' lives has been down to idiots overreacting: people on the opposite side of the planet unneccessarilly taking iodine tablets shortly after the accident (causing medical side effects as well as a shortage of iodine tablets for people who actually needed them), Germany spontaneously deciding to shut down manu of its nuclear power stations (which has caused crippling price rises for the population as the country has had to buy electricity from foreign nuclear power stations).
Overreaction, rather than safety, is basically the problem with nuclear power - there's no such thing as completely safe large scale power generation, and nuclear *is* safer than the alternatives (compare the environmental damage and number of people killed by nuclear accidents compared to those killed by dam failures, coal slurry spills, coal and gas combustion emissions, oil spills, etc.). Unfortunately the public mindset seems to be that anything involving radiation is far more scary and disasterous than any other accidents. As a point of comparison, the chemical industry deals with far more dangerous and toxic materials than a nuclear power station, and with far less regulation. And coal fired power stations are pumping all kinds of crap directly into the environment - sure, extremely occasionally there is a nuclear spill, but that's only newsworthy because we normally contain the waste generated by nuclear power stations; if we bothered to contain the waste from fossil power stations then a spill there would be newsworthy too...
Don't get me wrong, I think building new, safer, reactors is the only sensible idea rather than extending the lives of the ancient designs, but even the old designs aren't as dangerous as people seem to make out. In over 60 years of nuclear power generation there have only been 2 really significant disasters - Chernobyl (which hasn't caused anywhere near as much environmental damage as expected, and whilst there were serious medical problems caused by it, the vast majority of them were actually psychological rather than physiological), and Fukushima. Many people cite Three Mile Island as a huge disaster, but if you actually investigate the TMI accident and understand what happened, you'll quickly come to realise that its a good example of everything going to hell whilst causing very little environmental damage - i.e. it's a pretty good example of the safety of nuclear power in that even when things go very wrong it doesn't necessarilly mean a huge environmental disaster.
It's hard to do echo cancellation if your processing pipeline is much longer than the echo:-) Latency in Win32 audio (or Linux audio of most common stacks) is between awful and unusable.
All good points, but I was under the impression that Skype managed it reasonably well (note: I've never actually used Skype so can't confirm or deny this myself).
They are not mere passive shufflers of ports and addresses.
They are active gatekeepers that have omnipotent power to decide which inbound ports get forwarded to which hosts, and which will flat out reject an inbound connection without even ASKING which of the downstream hosts wants to handle it.
It not only does not know who the connection is meant for, it actively refuses to care.
I'm not sure if your post is saying this is a good thing or a bad thing (for the record, its a bad thing and doesn't help security on any competently put together network).
I suggest you read my comment where I talk about the user not having a way to open a hole back through the firewall. Why you assumed I meant "...except for the use of a stateful firewall" I have no idea, but I didn't, and if I had, that's what I would have written.
If the firewall isn't going to allow any returning UDP traffic, it can be considered broken - even basic stuff like DNS isn't going to work in that situation. There's no reason why anyone would ever want such a device. Yes, you can cook up far fetched reasons involving unusably broken equipment why using TCP is the only option, but back in the real world, if you have a firewall that broken you won't be able to do a lot else on the internet either so you would replace the firewall with one that works.
Uh what? No. UDP has no backchannel, so it certainly won't work in that situation. Packets go out, no packets come back.
I suggest you read up on how stateful firewalls work. When a UDP packet egresses through the firewall, it will remember the (source IP, source port, destination IP, destination port) tuple for a period of time (often 30 minutes or so) and automatically allow response packets matching the reverse of that tuple back through.
If you think companies are going to let all their systems talk to the internet at large just because they use IP6 then you're off with the pixies. Its almost certain that most corps will limit ip6 devices to link local only addresses and use some form of address translation as a "security" measure. The only thing IP6 will gain us is huge increase in general network complexity.
Ok, who said anything about "companies" here? The discussion was a general "why can't we do VoIP without any middle-men?", not a specific "why can't we do VoIP without any middle men in a highly restricted corporate network?".
So lets divide this up into the three markets:
Home users: Currently these usually have an RFC1918 network and do NAT and ingress firewalling at the point they connect to the ISP. Usually there is no egress firewalling. These people want devices they plug into their network to Just Work without wanting to faff with router settings, configuring their own servers, etc. So phones on these networks have to deal with a firewall and a NAT - this means they are going to have to use an external server to mediate and relay traffic in order to be reliable. In the future we'll hopefully have IPv6 everywhere, which means no more NAT - you'll still have an ingress firewall (unless you're insane), so you still need an external server to relay the signalling*, but the lack of NAT means that you can send the media stream peer-to-peer (yes, this will work even through a stateful firewall). (* ok, you can poke a hole in the ingress firewall for port 5060 and use DNS to find the phone, but that involves more fiddling than post people want to do).
Small businesses: These are frequently very similar to home users. They may choose to have their own servers either inside or outside their LAN, but for the most part we can say these businesses are like the home user.
Large corporates: Large corporates currently tend to have RFC1918 networks internally and use a combination of NAT and proxying on the border. They also have ingress and egress firewalls. It is common for SIP/RTP proxies* to be used at the border - anyone outside the network can treat the proxy as if it were actually a phone. The proxy relays the SIP and RTP traffic to/from the real phones, and since the proxy has a global scope IP address there is no NAT to deal with. The proxy could be considered a "middle-man", but since it is under the corporation's control it isn't really a problem (and yes, it may do intercept - e.g. my business's phone system automatically records calls made to our support lines so that the recordings can be attached to the customers' support tickets for future reference). Once IPv6 appears, you can bet that this practice will continue, but without the NAT bit - the internal networks will be global scope addresses and the border will use ingress/egress firewalling and proxying, so corporates are the least affected by the change to IPv6 since they weren't really having to deal with NAT for this stuff anyway. (* The term "proxies" is quite loose here - for ingress phone calls, a back-to-back user agent, such as Asterisk, is often used instead of a true proxy, since it affords the flexibility of a true phone exchange (e.g. call groups, IVRs, etc.) rather than a dumb relay).
Large corporates are only going to be using address translation "for security" if they have a completely incompetent network administration team - there is no real security afforded by NAT and anyone who thinks otherwise has no business being in charge of network security anywhere. Whether your network is IPv4 or IPv6, you still need decent firewalling at the border, and once you've got that you gain no additional security by having NAT.
The thing is, it won't get the job done reliably. Google "head of line blocking" - if you drop a voice packet you want to make do without it (phones usually try and predict what would've been in the packet to fill the gap - that tends to be "good enough" to make your brain think there wasn't much disruption most of the time). Holding up the entire media stream until you arrange for a packet that's already too late to be retransmitted (thereby making a lot more of the packets too late) is the worst thing you can do. If you're having to jump through these kinds of hoops because your ISP has decided its sensible to block all non-TCP traffic then its time to change ISP, its not going to work reliably any other way.
routing tcp over upd is silly only until it's the only way to route data from the app you want to where you want, then it becomes just a question of if it's fast enough or not.
Firstly we're not talking about TCP tunnelled inside UDP, we're talking about UDP tunnelled in TCP.
Secondly, no, its not about whether its "fast enough" - TCP has certain properties that make it extremely unsuitable for carrying realtime voice/video media, irrespective of speed. This is especially true in high-jitter / low reliability networks, such as cellular networks, which is exactly what this misfeature seems to be aimed at.
But if you're calling someone else who's also using the internet, it shouldn't require anything more than software running on the two end machines, with strong end to end encryption
That works well right up until someone wants to set up a firewall and/or NAT between the two end machines...
Slashdot Mirror
We recently had to move a client over to IPv6 faster than intended because we couldn't get a block of clean IPv4 static addresses from the ISP. That problem is only going to get worse over time.
Meanwhile, I have the opposite problem with Eclipse internet. One of my customers needed a new internet connection (we're talking 100Mbps leased line, not a poxy ADSL), so we recommended they check the prospective ISPs supported IPv6. "Yes, we support it " says Eclipse, so they went with them. When it actually got installed, Eclipse sent through the IPv4 details, so I replied asking for the IPv6 details too... they replied saying they didn't offer IPv6 to customers yet. When pressed further, they said "Our network fully supports IPv6, but we don't offer the service to our customers" - what a complete waste of time. (Of course, the customer doesn't see it as important enough to make a big fuss about, but if it were me I would be fuming about having been missold a reasonably expensive connection).
The real power of IPv6 is that it allows us to eliminate NAT.
Which is a bad idea for home users.
Umm, why?
I don't know for a fact, but I'm willing to bet that computer in the college dorm room used NAT.
I'm willing to bet it didn't. Certainly when I was at university, everything had an unfirewalled global scope IP (this was not that long ago, but still before the days of evil on the internet that required everyone to have a firewall).
Why get rid of NAT?
Because its an almighty pain in the arse. It breaks all sorts of things, and if you haven't discovered that yet, you presumably have never managed a moderately complex network or done anything other than plain old web browsing.
I use NAT for my home intranet. It's easy - two lines in my iptables config file. And everything works fine.
No it doesn't - the things you use it for presumably work fine, but there's all sorts of technologies that really struggle to work through NAT (and for good reason, not just because of a flawed protocol design). Throwing NAT out is a good thing - it makes networks less complex and more reliable.
"Google clamps down on Spam, Intrusive Ads In Apps from competitors
I can't think of any Google applications on Android that even use ads...
In any case, I'm happy to see all the apps that include AirPush get banned from Google Play - I have no time for any developer who thinks its a good idea (especially since they never warn you that they are using AirPush when you install the app).
I'm not sure about jelly bean.. but my older android phone has all sorts of crapware put on by the carrier, that I cannot uninstall I have a notification every single day about updates being available for them.. I have never used them, see lots of comments about the update causing problems, and no way to uninstall.. can I at least tell it to stop checking for updates?
If you remount /system as readwrite (requires root) you can just uninstall the bundled apps in the usual way.
Angry birds is the reason I installed an ad blocker... I'm all for ad supported free stuff, but not when the ad actually gets in the way.
Apps distributable outside of appstore
Android gives you that already.
No fragmentation issues either device capabilities, or OS version issues.
I don't see that ever happening. This would require all devices to have exactly the same capabilities - Apple managed that with the origional iPhone by virtue of there only being one device. However, the original iPhone was far too lacking in features to be of use to many of us, and all iPhones have been far too expensive for many (that's largely down to Apple's inflated pricing - the iPhone 4 and Nexus S are pretty much identical hardware, but the iPhone 4 was almost twice the price when these phones were reasonably new. However, if you dictate that all hardware is going to be the same, even without artificially inflated pricing that means people are going to end up paying for hardware far more capable than what they actually need). As soon as Apple released later generations of the iPhone, there were multiple iPhone devices in the wild with different hardware capabilities - the only way to avoid this would be to have only produced the original iPhone rather than providing an upgrade path.
So no, we're never going to be in a situation where there are no fragmentation issues WRT to device capabilities - if your software requires a device with gyroscopes then its not going to work on a device that hasn't got gyros, for example. There will always be a new technology around the corner in the next generation phones and unless everyone upgrades there will be fragmentation caused by the older generation still being around. And I may be unusual, but after spending £300+ on a phone, I tend to use it until it breaks rather than upgrading it every 6 months.
There is, however, confusion caused by the wide variety of hardware on the market, largely because no one seems to publish any kind of information on what you can expect the hardware to do - I can look at the specs for a phone, which tell me how much RAM it has, how many CPU cores and what speed they run at, etc. but even as a techie I can't actually tell you what you can expect the phone to be capable of - sure, more is better, but when you come to balancing spec against cost it would be nice to have some indication about where the spec becomes "good enough" for what you're planning on using it for. There _is_ a market for low-spec phones, and there is a market for high spec phones, and these markets should continue to give people the choice, but it would be nice to have some good information about what limitations going for a lower spec device will place on you.
Native code and complete platform API
I was under the impression that Android had a native API? (Note: I've done no Android development, so have no first hand experience of this)
Same code executable on desktop
Technically you could do this by providing an interface library, much the same as Wine does for Windows applications. However, at the moment I think this is of limited value. The UI paradigms for mobile and desktop are currently very different. In the past, MS has tried to push a desktop UI onto mobile devices, with reasonably disasterous results. Now MS are trying to do the opposite - they are pushing Metro (a mobile/tablet UI) onto the desktop and I expect to see similarly disasterous results (I have briefly used Metro, and frankly I found it unusable to the point where I had to ctrl+alt+delete to get task manager up and actually kill the applications since I couldn't figure out how the hell to actually exit back to the "start menu").
I do believe that a UI that is shared between all devices (phones, tablets, desktops, etc.) is possible and even desirable, but the current efforts don't achieve that because they push the limitations of one device upon all devices. For example, a small screen device usually runs everything in full-screen mode, but this is the last thing I want t
No one else offers ubiquitous computing with full functioning business productivity software available on every device a person owns. No one else is even trying.
Thats because the smart developers ensure their software uses open standards so that they don't need to make their software available on every device a person owns - other people will do it for them, and the various softwares from different vendors will interoperate. MS, on the other hand, try to lock up all their standards so no one can write interoperable software, which means that MS have to support all types of device (note: all _types_ of device, not all devices - I can't get Windows Phone for my Samsung Captivate Glide, I would have to buy a new device).
Personally, I prefer to have a choice of application and device, rather than the data format / protocol on one device dictating that all my other devices must run software from the same vendor in order to interoperate.
I remember it distinctly, because I was waiting for them to screw up and claim he invented the internet. They never made that mistake, but it appears that Mr. Boyle did, since he had his lovestruck teens thanking him for their cell phones.
Cell phones do the web these days...
No, it's not. If they have no proof you agreed, they are clearly in violation of your rights.
I didn't say "they have no proof", I said "they haven't provided any proof". In any case, it hardly matters - the ICO has no interest in prosecuting.
I don't know anything about Korean law, but aren't they liable as well if they purchase goods that are stolen, or have a reasonable likelihood of being stolen?
My experience here in the UK is:
I used a popular car insurance comparison website when I was shopping around for cheaper car insurance. On this website I had to enter various personal details such as name, address, date of birth, claim history, etc. Soon afterwards I started receiving cold-calls in connection with the accidents in my claim history. These calls usually started by claiming to be from "the insurance company" and implying they were my insurer, without actually providing the name of the insurer. Initially I wondered if "the insurance company" might actually be the other party's insurer rather than mine (so I was very wary), but when pressed for more detail they put up various BS claims about how they couldn't give me the information I asked for because of the data protection act - I do know my rights under the DPA and I pushed further and eventually it turned out they were actually personal injury lawyers. They wanted me to make a personal injury claim, and still encouraged me to make a claim even after I pointed out that no one was injured, and in fact no one was even in the car when the accident happened (it was parked, someone drove into it).
Some time later, I started getting calls from other companies (this time in connection with PPI, which isn't even targetted advertising any more since I've never had PPI). They insisted that they didn't need to screen calls against the telephone preference service because I had "agreed" to receive them (the ICO has confirmed that this is not true - they still need to screen against TPS). Eventually, after a lot of correspondance with these cold-calling companies (who were surprisingly cooperative), I discovered that some of the information had come from a marketing company that I had never heard of, but this company had very clearly acquired my details from the insurance comparison site (they even ran their oen insurance comparison site, although this wasn't the one I used).
Unfortunately, things pretty much stop here - the company that has been selling my details claims that they phoned me and I verbally agreed to receive promotional material from "partner companies". I can neither confirm nor deny whether they phoned me, but I am certain I would never have agreed to this. Unfortunately they have so far declined to provide any evidence to support their position, I have no evidence to support mine, so it's my word against theirs. As far as I can tell, they have taken my details and illegally sold them to a bunch of people, who have then sold them to a bunch of people, etc. The people they sold them to believe that the details the bought were authorised by me, the people further down the chain have even less reason to believe that the information is being distributed illegally.
In short:
1. Although the company responsible for illegally selling off my details could probably notify everyone they've sent the data to, they have no inclination to do so.
2. The data has been bought and sold so many times that there's no way to remove it from everyone's possession - it will continue to be bought and sold and there's nothing I can do to bring it back under my control.
3. The ICO seems disinclined to help, probably because they already know there's no way to stop the dissemination of this data now it has spread so far and wide.
The situation in SK would likely be similar - the original marketing companies may well have bought the datsa in good faith, and have now sold it to a bunch of other companies, who have sold it to more companies, etc. There's no way to retract this information now - its been spread too far and wide and the people lower down the chain won't have any idea WTF it came from originally.
The only solution to these kinds of problem that I can see is to outlaw the transfer of personal data between companies wit
Who cares? Most of the DirectTV channels are complete crap anyway. When I had directTv, I only watched twelve channels to begin with. DirectTV literally has thousands of channels.
I dropped Sky here in the UK when I realised that I was only watching 4 channels - BBC 1, BBC 2, S4C and Sky One. The only stuff I was watching on Sky One was House and Eureka, which I can buy on DVD for less than I was paying for my subscription. BBC channels and S4C are free anyway...
I can't in good conscience recommend using Skype to any business for communications, which can often be sensitive, as long as Microsoft is putting in backdoors. Need to find another platform.
I've been recommending SIP solutions for business for years. The Grandstream phones work very well when paired with Asterisk servers.
To be honest, I don't know how this news changes anything WRT Skype - its always been a closed system where the security is completely unverifyable (and the software has been designed to make discovering what its doing really hard), if you trusted it before you were an idiot.
And, Failing that, you can always have the conversation converted to text and then ROT13 it. Oh, wait...
ROT-13 is insecure these days, better to use double-ROT-13
Port forwarding has to be triggered by the *downstream* host.
Until that host makes an *outbound* connection the NAT doesn't know or care about who to send inbound stuff to.
Correct. This is identical, whether you are using TCP or UDP - in order for a host outside the NAT to send anything to a host inside the NAT, the inside host has to have already sent data to the outside host (within a reasonable time period). So as I originally explained, using TCP in this situation provides no benefit over UDP with respect to NAT traversal.
And UDP forwarding has to be triggered by an outbound UDP packet just the same as with TCP forwarding, by an outbound connection, which means that unsolicited inbound connections or UDP packets not associated with a preexisting outbound connection have no way of finding the host they are meant for.
Correct again. And again, this is identical whether you're using TCP or UDP (as you've just said yourself)... so I don't quite understand what you're arguing about:
If you are behind a NAT, in order for a host outside the network to contact you, you must have already contacted it (so that the NAT knows where to forward the traffic). This is true whether you use UDP or TCP - TCP offers no advantage(*) for NAT traversal over UDP since in both cases, your internal host must have already "connected" with the external host in order for the external host to send any data.
Stop being a moron and learn how NAT actually works in the real world
I do understand how NAT works, this is what I do for a living. Nothing in your post has disputed my original point, all you've done is screamed about how I'm a "moron" and then agreed with my original comments. If you feel this is incorrect, please put together a concise reply that describes exactly what you think I got wrong rather than resorting to name calling.
typical broadband consumers where the NAT device is under the control of an ISP that has every incentive to not cooperate with consumers who want to run a personal server of sorts.
Typical broadband customers (at least in the UK) have control of their own routers. But this is beside the point - no reconfiguration of a typical NAT is required in order to use UDP in the way in which I have described.
Treating it as a stateful firewall only works when the NAT is under the same administrative control as the host behind it.
No. A NAT fundamentally requires stateful packet inspection. You cannot reasonably have NAT without stateful packet inspection, so treating a NAT like a stateful firewall is entirely reasonable in this circumstance. Note that I made no comment about the need to reconfigure the SPI since this is not necessary, therefore who's administrative control it is under is irrelevant.
I'm saying it's bad for people behind the NAT because it prevents them from receiving inbound connections...unless they want to beg the ISP for a business grade connection.
No, it doesn't. As I said, UDP will traverse a NAT just the same as TCP - NAT employs the same techniques as a stateful firewall.
The crap is that it is going to be bad for the whole planet, just like the japanese fiasco was.
Sorry, could you explain how Fukushima was "bad for the whole planet"? The radioactive fallout was certainly nowhere near a global scale (_trace_ amounts were observed globally, not dangerous amounts). Radioactive material from the accident has been found in food produced within a 200 mile radius - yes, a significant accident but you'd be hard pushed to say its affected peoples' lives globally.
In fact, the only real global effects Fukushima has had on peoples' lives has been down to idiots overreacting: people on the opposite side of the planet unneccessarilly taking iodine tablets shortly after the accident (causing medical side effects as well as a shortage of iodine tablets for people who actually needed them), Germany spontaneously deciding to shut down manu of its nuclear power stations (which has caused crippling price rises for the population as the country has had to buy electricity from foreign nuclear power stations).
Overreaction, rather than safety, is basically the problem with nuclear power - there's no such thing as completely safe large scale power generation, and nuclear *is* safer than the alternatives (compare the environmental damage and number of people killed by nuclear accidents compared to those killed by dam failures, coal slurry spills, coal and gas combustion emissions, oil spills, etc.). Unfortunately the public mindset seems to be that anything involving radiation is far more scary and disasterous than any other accidents. As a point of comparison, the chemical industry deals with far more dangerous and toxic materials than a nuclear power station, and with far less regulation. And coal fired power stations are pumping all kinds of crap directly into the environment - sure, extremely occasionally there is a nuclear spill, but that's only newsworthy because we normally contain the waste generated by nuclear power stations; if we bothered to contain the waste from fossil power stations then a spill there would be newsworthy too...
Don't get me wrong, I think building new, safer, reactors is the only sensible idea rather than extending the lives of the ancient designs, but even the old designs aren't as dangerous as people seem to make out. In over 60 years of nuclear power generation there have only been 2 really significant disasters - Chernobyl (which hasn't caused anywhere near as much environmental damage as expected, and whilst there were serious medical problems caused by it, the vast majority of them were actually psychological rather than physiological), and Fukushima. Many people cite Three Mile Island as a huge disaster, but if you actually investigate the TMI accident and understand what happened, you'll quickly come to realise that its a good example of everything going to hell whilst causing very little environmental damage - i.e. it's a pretty good example of the safety of nuclear power in that even when things go very wrong it doesn't necessarilly mean a huge environmental disaster.
It's hard to do echo cancellation if your processing pipeline is much longer than the echo :-) Latency in Win32 audio (or Linux audio of most common stacks) is between awful and unusable.
All good points, but I was under the impression that Skype managed it reasonably well (note: I've never actually used Skype so can't confirm or deny this myself).
NAT doesn't just make things unpredictable.
They are not mere passive shufflers of ports and addresses.
They are active gatekeepers that have omnipotent power to decide which inbound ports get forwarded to which hosts, and which will flat out reject an inbound connection without even ASKING which of the downstream hosts wants to handle it.
It not only does not know who the connection is meant for, it actively refuses to care.
I'm not sure if your post is saying this is a good thing or a bad thing (for the record, its a bad thing and doesn't help security on any competently put together network).
I suggest you read my comment where I talk about the user not having a way to open a hole back through the firewall. Why you assumed I meant "...except for the use of a stateful firewall" I have no idea, but I didn't, and if I had, that's what I would have written.
If the firewall isn't going to allow any returning UDP traffic, it can be considered broken - even basic stuff like DNS isn't going to work in that situation. There's no reason why anyone would ever want such a device. Yes, you can cook up far fetched reasons involving unusably broken equipment why using TCP is the only option, but back in the real world, if you have a firewall that broken you won't be able to do a lot else on the internet either so you would replace the firewall with one that works.
Uh what? No. UDP has no backchannel, so it certainly won't work in that situation. Packets go out, no packets come back.
I suggest you read up on how stateful firewalls work. When a UDP packet egresses through the firewall, it will remember the (source IP, source port, destination IP, destination port) tuple for a period of time (often 30 minutes or so) and automatically allow response packets matching the reverse of that tuple back through.
Yes, in fact, it does offer an advantage. It can work if one party doesn't have any ability to open incoming ports. That is significant.
You know that UDP will work in that situation too don't you?
If you think companies are going to let all their systems talk to the internet at large just because they use IP6 then you're off with the pixies. Its almost certain that most corps will limit ip6 devices to link local only addresses and use some form of address translation as a "security" measure. The only thing IP6 will gain us is huge increase in general network complexity.
Ok, who said anything about "companies" here? The discussion was a general "why can't we do VoIP without any middle-men?", not a specific "why can't we do VoIP without any middle men in a highly restricted corporate network?".
So lets divide this up into the three markets:
Home users:
Currently these usually have an RFC1918 network and do NAT and ingress firewalling at the point they connect to the ISP. Usually there is no egress firewalling. These people want devices they plug into their network to Just Work without wanting to faff with router settings, configuring their own servers, etc. So phones on these networks have to deal with a firewall and a NAT - this means they are going to have to use an external server to mediate and relay traffic in order to be reliable. In the future we'll hopefully have IPv6 everywhere, which means no more NAT - you'll still have an ingress firewall (unless you're insane), so you still need an external server to relay the signalling*, but the lack of NAT means that you can send the media stream peer-to-peer (yes, this will work even through a stateful firewall).
(* ok, you can poke a hole in the ingress firewall for port 5060 and use DNS to find the phone, but that involves more fiddling than post people want to do).
Small businesses:
These are frequently very similar to home users. They may choose to have their own servers either inside or outside their LAN, but for the most part we can say these businesses are like the home user.
Large corporates:
Large corporates currently tend to have RFC1918 networks internally and use a combination of NAT and proxying on the border. They also have ingress and egress firewalls. It is common for SIP/RTP proxies* to be used at the border - anyone outside the network can treat the proxy as if it were actually a phone. The proxy relays the SIP and RTP traffic to/from the real phones, and since the proxy has a global scope IP address there is no NAT to deal with. The proxy could be considered a "middle-man", but since it is under the corporation's control it isn't really a problem (and yes, it may do intercept - e.g. my business's phone system automatically records calls made to our support lines so that the recordings can be attached to the customers' support tickets for future reference). Once IPv6 appears, you can bet that this practice will continue, but without the NAT bit - the internal networks will be global scope addresses and the border will use ingress/egress firewalling and proxying, so corporates are the least affected by the change to IPv6 since they weren't really having to deal with NAT for this stuff anyway.
(* The term "proxies" is quite loose here - for ingress phone calls, a back-to-back user agent, such as Asterisk, is often used instead of a true proxy, since it affords the flexibility of a true phone exchange (e.g. call groups, IVRs, etc.) rather than a dumb relay).
Large corporates are only going to be using address translation "for security" if they have a completely incompetent network administration team - there is no real security afforded by NAT and anyone who thinks otherwise has no business being in charge of network security anywhere. Whether your network is IPv4 or IPv6, you still need decent firewalling at the border, and once you've got that you gain no additional security by having NAT.
it's not silly if it gets the job done.
The thing is, it won't get the job done reliably. Google "head of line blocking" - if you drop a voice packet you want to make do without it (phones usually try and predict what would've been in the packet to fill the gap - that tends to be "good enough" to make your brain think there wasn't much disruption most of the time). Holding up the entire media stream until you arrange for a packet that's already too late to be retransmitted (thereby making a lot more of the packets too late) is the worst thing you can do. If you're having to jump through these kinds of hoops because your ISP has decided its sensible to block all non-TCP traffic then its time to change ISP, its not going to work reliably any other way.
routing tcp over upd is silly only until it's the only way to route data from the app you want to where you want, then it becomes just a question of if it's fast enough or not.
Firstly we're not talking about TCP tunnelled inside UDP, we're talking about UDP tunnelled in TCP.
Secondly, no, its not about whether its "fast enough" - TCP has certain properties that make it extremely unsuitable for carrying realtime voice/video media, irrespective of speed. This is especially true in high-jitter / low reliability networks, such as cellular networks, which is exactly what this misfeature seems to be aimed at.
But if you're calling someone else who's also using the internet, it shouldn't require anything more than software running on the two end machines, with strong end to end encryption
That works well right up until someone wants to set up a firewall and/or NAT between the two end machines...