Errm, I'm sorry, but if I have a webserver running then the firewall will have to allow traffic to that webserver - the firewall won't be examining the traffic and looking to see if it matches any known attack (and even if it did, since the attack is known the webserver can be fixed). So someone can compromise that web server whether there is a firewall or not.
If you mean that the attacker could install code listening on any other port then a firewall running on the machine itself isn't going to help you - there's nothing stopping the attacker from shutting down the firewall while they're installing a rootkit. Even if the firewall is on a different machine there's still nothing stopping the attacker from crashing the service their compromising (or any other service on the box) and firing up their own service to listen on that port.
"do busses need seatbelts?" - yes, but not many have them "do trains need seatbelts?" - probably, but they don't have them "do motorcycles need seatbelts?" - dunno, but I don't see many the them:)
If you have ANY device connected to a network, it should be protected (firewalled) from evil-doers.
No - if your device is set up _correctly_ then insecure and unnecessary services shouldn't even be listening for connections from the big bad internet, so you don't need a firewall.
IMHO the _only_ reasons to have a firewall on a system set up by someone with a clue are: 1. controlling forwarded traffic if the device is routing network traffic for other machines 2. as a fail safe incase you accidentally enable a service you didn't intend to.
Even if you do open up CRTs and PSUs, why should you need to pay $55 for a certificate which only certifies that you paid $55? If there is a reason to be certified then you need a test to say you can do it rather than just letting anyone hand over some money.
Wow all of that sounds awfully different from your orginal post of...
"I don't understand how this is enforcable - VoIP is an end-to-end system - no middlemen are needed. How are they going to stop me doing VoIP over an IPSEC connection?"
From you orginal post it sounded to me like you were questioning how they were going to enforce it, when you believed that there were no middlemen involved. Which is what I was arguing. Now it sounds like you think that they want to ban encrypted VoIP communication.
By "middlemen" I was *never* talking about the internet infrastructure - I'm talking entirely about VoIP infrastructure (yes, yes, VoIP runs over the internet - I don't see why that's especially relevent - your ISP does not need to know and frankly doesn't care what you're doing with your connection in the same way as the people who make the copper wires your POTS line uses don't care what you're using them for).
As soon as you call an IP enabled phone that is external to your control, then the traffic is going to be transmitted via IP on other peoples network and/or the Internet.
I'm still not seeing how that's relevent - the people at the _end points_ of the VoIP connection (or infact any IP conversation) choose the application layer protocol, not the ISP - the ISP does not need to know what you're doing - why does it matter to them if you're doing VoIP or playing Quake? Once you start regulating what protocols private individuals are even allowed to use over the internet (and forcing the ISPs to identify those protocols and filter them, whcih isn't exactly easy) you're on a really slippery slope.
The FCC regulation ownly wants to make it possible to tap the conversation, just like they can tap a normal phone call. How that is going to be accomplished if you encrypt it I do not know. I'm just speculating now, but if they can capture the packets, I would believe that it would not be to hard to get a court order to make you surrender your encryption keys to decrypt the conversation.
They could already do this anyway - it seems to me the only reason to get such legislation is to prevent people using (to all intents and purposes) unbreakable encryption on their phone conversations, whcih seems to me completely unenforcable unless people are gatewaying to the PSTN (where the communication is in the clear anyway).
In any case, it's *exceptionally* easy to get around the court order to force you to hand over your keys - if you use public key cryptography then you can rekey frequently without worrying about how you distribute the keys. Generate a key pair, publish the public key, use the key pair to encrypt your phone conversation and then completely destroy your keys. The next time you make a phone conversation you just need to create a new key pair. If you are ordered to relinquish the keys, well too bad - you already destroyed them. If you want to get really paranoid you could rekey even more frequently - like every minute or something.
I think somewhere along the line we diverged from my arguement:
1. You cannot legislate against what protocols private individuals use over their internet connection, only what protocols *VoIP service providers* use - if I want to use an encrypted VoIP protocol to talk to my mates directly over the internet how can they stop me? I'm not going via any 3rd party VoIP providers so noone can dictate any protocols to me.
2. Even if you can legislate what protocols I may use when connecting to machines owned by other private individuals, it's unenforcable to say "you may not do encrypted VoIP" - if I choose to encapsulate my VoIP traffic in IPSEC then it may be illegal but theres no way the authorities could tell that it was VoIP traffic I'm encapsulating. It would be like saying "letters written on green paper may not be enclosed in an envelope" - how are you going to tell that the contents of an envelope isn't a letter written on a bit of green paper (assuming that opening the envelope is impossible).
3. Legislating about what protocols a VoIP service provider can use is possible, but the only reason to use a 3rd party VoIP service provider is if you need to gateway VoIP traffic onto the PSTN. In which case the traffic is tappable as soon as it gets onto the PSTN anyway.
So the legislation seems moot. And before you start telling me that I do use 3rd party providers to carry my traffic, yes - I use an ISP, I am talking specifically about people providing VoIP services, not general internet connections and I cannot see how you can legislate that no ISP is allowed to carry any encrypted traffic of any description (whcih is essentially what you'd need to stop private individuals from being able to transmit encrypted VoIP traffic between them).
Ok, maybe I should've been clearer - they don't dictate what application layer protocols I can use.
Yes they do, it is called SMTP
Err, no they don't - the ISP's router doesn't know anything about SMTP. For all the ISP knows I could be running a frickin' web server on port 25.
Who say's that they have to be sniffing for encrypted mail. You have an MX record for your email server don't you? You can sniff for traffic based the IP address that is being sent to or sent from and capture the raw data. After that, you have a copy of the raw data that can be rebuilt and hacked against to break the encryption. Just for fun put a Snort box right outside of your email server and see what you get.
Yes, they could sniff the traffic, but they're not going to be blocking it - if the backbone routers start blocking traffic then the internet is frankly doomed. If the backbone routers start parsing traffic to work out what to filter they would fall over from the load. And if my ISP starts filtering my traffic then I'll damned well find an ISP with a clue.
Your are still looking at it at to high of a level. VoIP is still nothing more than data encapsulated into an IP packet. Once the data is transmitted via IP it can be sniffed and captured.
Yes, and as my original message said - how are they going to stop me encapsulating it in IPsec? I wasn't arguing that you couldn't sniff VoIP traffic (indeed you can and there are utilities that will output a wav file of the conversation if you feed them tcpdump logs), my arguement was that it's completely unenforcable because they can't stop people using whatever the hell protocol they want - encryption or no.
Capturing IP packets is trivial. Sincce VoIP is nothing but IP encapsulated data, sniffing and capturing phone conversations should be just as trivial as long as you have the resources to rebuild the voice and break the encryption.
Ok, I'll hand you an IPSEC encrypted VoIP stream and you tell me what the conversation was about - if they have the technology to break encryption they wouldn't need to have legislation saying that the protocol allows for them to listen in would they?
My ISP, but they are not a telephone provider and will not be dictating what protocols I can and can't use, nor will they be charging me on a per-second basis for my phone calls (ok, eventually we might each end up paying for the bandwidth we use, but the bandiwdth used by voice calls is tiny compared to the bandwidth used for surfing the web and downloading pr0n so the bandwidth cost of telephony will be largely irrelevent).
When people send email to your server from somewhere else, there are lots of middleman involved.
Yes, but again, they are not going to be dictating what protocols I can use - some random router on the internet isn't going to sit there sniffing TCP traffic on port 25 and reject it because I'm sending an encrypted email - only the mail relays are in a position to do that.
That is the hole concept behind routing. When I said "provider" I was meaning your data provider or better known as ISP.
By "end-to-end" I meant that the protocols don't rely on there being lots of VoIP relays understanding the protocol and routing it - the source VoIP server connects directly to the destination server, the routers between just do IP routing and don't know/care what protocol I'm using over IP. The backbone routers are not in a position to be stopping me using whatever protocols I want.
I'm not entirely sure who the "providers" are you're talking about - doing VoIP over the internet involves 2 endpoints talking to eachother. I don't see why you need any telephone "providers" involved at all. It's the same as email - I don't pay an "email provider" to route my mail for me (and maybe charge per mail or something), I run a mail server on the end of my DSL line and people wanting to email me send to there, no middlemen involved.
For eaxmeple, lets say that I am using provider A, and make a VoIP call to a subscriber that uses provider B. Don't my packets travel from my phone to provider A's network, bounce around in their until they are routed to provider B's network, bounce around their until they get routed to the other VoIP phone that I am calling.
As far as I'm concerned, you have an IP phone plugged into your internet account and you dial another IP phone either by entering an IP address, DNS name or real phone number (translated by an ENUM DNS lookup). What are these providers doing? Why do you need them? Do you subscribe to an "SSH provider" to route your SSH sessions to the right server?
If you do that (which is probably a good idea) you'll need to weight it based on the amount of code written by that author that _could_ contain a security hole. Otherwise the stats will just show that the authors who write 99% of the complex network-facing code are responsible for most security holes.
Another way of killing the problem is using the NX (I hope I got that correct) instruction/bit in newer CPUs and simply separate code and data, and not allow execution in a data segment. Win SP2 does this, I am sure Linux does/will soon
Yep, Fedora Core 2 has done this since one of the early kernel revisions (I think it was when they went from 2.6.5 to 2.6.6)
You don't want to go around remembering the ip v6 for all your friends
There's a thing called DNS, it lets you use easy to remember names instead of IP addresses... Or do you email people using their IP addresses?:)
At least that's my unqualified gues since I don't "know" the VoIP systems in the US.
I'm in the UK, but I don't see why this is different anywhere else - I have Asterisk running on my server which handles my IP phones. My server also has an FXO card in it that lets me make and receive calls over my POTS line. The only 3rd-parties involved are: 1. My telco when I make PSTN calls over my POTS line (but that's just like having a plain POTS phone) 2. e164.org - for translating phone numbers into VoIP addresses using DNS (this is _lookups_ only, no actual voice traffic involved here) 3. VoipUser who provide some incoming PSTN DDIs for me over the internet
So the only "tappable" third parties there are only involved when I'm making calls via the PSTN - VoIP calls are always made directly. I honestly can't see a place for any VoIP service providers except VoIP-PSTN gateways and maybe voicemail providers, etc in the event your internet connection breaks or your server goes down.
We are only talking about centralized networks. This is not likely to pertain to or be enforceable regarding decentralized or private networks.
This is going a bit offtopic, but maybe you can explain why anybody even needs centralised VoIP networks? The nature of VoIP is that it is end-to-end - the only time you need middlemen doing any VoIP gatewaying is when you need to gateway VoIP traffic to the PSTN. You don't pay for an "email provider", you run your own server instead - how is VoIP any different?
And if you're saying you need a VoIP provider to connect your phone to on a pay-per-minute basis and then they work out what needs to go over the PSTN and what goes over the internet (in a you-don't-need-to-know kind of way), that isn't at all the case - the ENUM system is designed to map normal phone numbers to VoIP servers using DNS. So your VoIP server can make a DNS lookup for the phone number you're calling - if it resolves then your VoIP server makes a direct connection (costing you only bandwidth) and if it doesn't resolve then you need to call over the PSTN, either by routing VoIP via a PSTN gateway (and paying them accordingly) or by having your VoIP server connected to the PSTN itself and paying your normal telco for placing the call.
In the next few years, I think we can expect to see the PSTN slowly vanish in favor of doing everything over the internet - we probably need a bit more infrastructure such as MX-style DNS records, but in the long run I can't see how we will actually need any "telephone providers" - all calls can be made directly over IP without using any middlemen.
I don't understand how this is enforcable - VoIP is an end-to-end system - no middlemen are needed. How are they going to stop me doing VoIP over an IPSEC connection?
I believe that's technically incorrect. If your speedometer shows 70 and you're going 76, it's still within the tolerance permitted by the MoT test, and I understand that you're not speeding.
AFAIK that's not the case - as I understand it there is a 10% tollerance on the MoT but no such tollerance on the actual law (so technically to be definately within the limit you should be cruising at 63mph, which is downright stupid). However, all the cars I've travelled in always have the speedo read over (according to the GPS) - when I'm doing 70mph my speedo is reading about 74mph, so cruising with the speedo reading 70mph is quite safe.
I do, however, wish that they would raise the speed limit to 80mph on the motorways and then properly inforce it with SPECS cameras.
They also keep putting in GATSO cameras despite plenty of evidence that they actually increase the number of fatalities (people cruise down the road and slam on the brakes when they see the camera... the guy who's tailgating behind them promptly slams into the back of them.) The answer is SPECS cameras, which do a good job (they average your speed over sections of road rather than just looking at your speed at one particular point, so if you accidentally creep over the limit for a second you don't get fined). Of course SPECS cameras actually effectively make people slow down so the police won't put them in since they can't issue as many fines.
The very silly thing is there are a few stretches a road in the UK with so many cameras on them that if you speed down the stretch of road you can lose your licence within a couple of miles - there should be some laws stopping that situation, people with a clean driving licence shouldn't be able to get banned for driving just by going 10mph over the limit for 2 miles.
An excellent example of why GATSOs shouldn't be used is Bournemouth - I go through it fairly frequently, I know exactly where the cameras are. The speed limit is 50mph, the road is reasonably straight, but if I wanted to (I don't) I could do 90mph down that stretch of road, just braking down to 50 for each camera.
Slashdot Mirror
That's the silliest thing I've ever heard.
Umm, yah, that would be why there was a smiley on the end of the line...
Errm, I'm sorry, but if I have a webserver running then the firewall will have to allow traffic to that webserver - the firewall won't be examining the traffic and looking to see if it matches any known attack (and even if it did, since the attack is known the webserver can be fixed). So someone can compromise that web server whether there is a firewall or not.
If you mean that the attacker could install code listening on any other port then a firewall running on the machine itself isn't going to help you - there's nothing stopping the attacker from shutting down the firewall while they're installing a rootkit. Even if the firewall is on a different machine there's still nothing stopping the attacker from crashing the service their compromising (or any other service on the box) and firing up their own service to listen on that port.
and built for botnets? no way, are you disconnected with reality? building a botnet with these would be total idiocy.
I dunno - great way to run up people's GPRS bills.
"do busses need seatbelts?" - yes, but not many have them :)
"do trains need seatbelts?" - probably, but they don't have them
"do motorcycles need seatbelts?" - dunno, but I don't see many the them
If you have ANY device connected to a network, it should be protected (firewalled) from evil-doers.
No - if your device is set up _correctly_ then insecure and unnecessary services shouldn't even be listening for connections from the big bad internet, so you don't need a firewall.
IMHO the _only_ reasons to have a firewall on a system set up by someone with a clue are:
1. controlling forwarded traffic if the device is routing network traffic for other machines
2. as a fail safe incase you accidentally enable a service you didn't intend to.
Just wait - soon you'll need to download 70MB patches over GPRS :)
Even if you do open up CRTs and PSUs, why should you need to pay $55 for a certificate which only certifies that you paid $55? If there is a reason to be certified then you need a test to say you can do it rather than just letting anyone hand over some money.
've been fixing computers for people for a long while, and have never had to open a CRT or power supply.
You're telling me you've never opened a PSU to swap the fan when the bearings have died? It's a fairly regular occurance for me.
I was going to buy Althlon MP's except for the fact that USB was broken and they never fixed it.
Err, WTF has USB got to do with the CPU? Sounds like a chipset issue to me, not a CPU problem...
Besides, the whole USB1.1 spec is badly designed - USB causes me so many problems in *all* motherboards I've tried.
Wow all of that sounds awfully different from your orginal post of...
"I don't understand how this is enforcable - VoIP is an end-to-end system - no middlemen are needed. How are they going to stop me doing VoIP over an IPSEC connection?"
From you orginal post it sounded to me like you were questioning how they were going to enforce it, when you believed that there were no middlemen involved. Which is what I was arguing. Now it sounds like you think that they want to ban encrypted VoIP communication.
By "middlemen" I was *never* talking about the internet infrastructure - I'm talking entirely about VoIP infrastructure (yes, yes, VoIP runs over the internet - I don't see why that's especially relevent - your ISP does not need to know and frankly doesn't care what you're doing with your connection in the same way as the people who make the copper wires your POTS line uses don't care what you're using them for).
As soon as you call an IP enabled phone that is external to your control, then the traffic is going to be transmitted via IP on other peoples network and/or the Internet.
I'm still not seeing how that's relevent - the people at the _end points_ of the VoIP connection (or infact any IP conversation) choose the application layer protocol, not the ISP - the ISP does not need to know what you're doing - why does it matter to them if you're doing VoIP or playing Quake? Once you start regulating what protocols private individuals are even allowed to use over the internet (and forcing the ISPs to identify those protocols and filter them, whcih isn't exactly easy) you're on a really slippery slope.
The FCC regulation ownly wants to make it possible to tap the conversation, just like they can tap a normal phone call. How that is going to be accomplished if you encrypt it I do not know. I'm just speculating now, but if they can capture the packets, I would believe that it would not be to hard to get a court order to make you surrender your encryption keys to decrypt the conversation.
They could already do this anyway - it seems to me the only reason to get such legislation is to prevent people using (to all intents and purposes) unbreakable encryption on their phone conversations, whcih seems to me completely unenforcable unless people are gatewaying to the PSTN (where the communication is in the clear anyway).
In any case, it's *exceptionally* easy to get around the court order to force you to hand over your keys - if you use public key cryptography then you can rekey frequently without worrying about how you distribute the keys. Generate a key pair, publish the public key, use the key pair to encrypt your phone conversation and then completely destroy your keys. The next time you make a phone conversation you just need to create a new key pair. If you are ordered to relinquish the keys, well too bad - you already destroyed them. If you want to get really paranoid you could rekey even more frequently - like every minute or something.
I think somewhere along the line we diverged from my arguement:
1. You cannot legislate against what protocols private individuals use over their internet connection, only what protocols *VoIP service providers* use - if I want to use an encrypted VoIP protocol to talk to my mates directly over the internet how can they stop me? I'm not going via any 3rd party VoIP providers so noone can dictate any protocols to me.
2. Even if you can legislate what protocols I may use when connecting to machines owned by other private individuals, it's unenforcable to say "you may not do encrypted VoIP" - if I choose to encapsulate my VoIP traffic in IPSEC then it may be illegal but theres no way the authorities could tell that it was VoIP traffic I'm encapsulating. It would be like saying "letters written on green paper may not be enclosed in an envelope" - how are you going to tell that the contents of an envelope isn't a letter written on a bit of green paper (assuming that opening the envelope is impossible).
3. Legislating about what protocols a VoIP service provider can use is possible, but the only reason to use a 3rd party VoIP service provider is if you need to gateway VoIP traffic onto the PSTN. In which case the traffic is tappable as soon as it gets onto the PSTN anyway.
So the legislation seems moot. And before you start telling me that I do use 3rd party providers to carry my traffic, yes - I use an ISP, I am talking specifically about people providing VoIP services, not general internet connections and I cannot see how you can legislate that no ISP is allowed to carry any encrypted traffic of any description (whcih is essentially what you'd need to stop private individuals from being able to transmit encrypted VoIP traffic between them).
Yes they do, it is called IP.
Ok, maybe I should've been clearer - they don't dictate what application layer protocols I can use.
Yes they do, it is called SMTP
Err, no they don't - the ISP's router doesn't know anything about SMTP. For all the ISP knows I could be running a frickin' web server on port 25.
Who say's that they have to be sniffing for encrypted mail. You have an MX record for your email server don't you? You can sniff for traffic based the IP address that is being sent to or sent from and capture the raw data. After that, you have a copy of the raw data that can be rebuilt and hacked against to break the encryption. Just for fun put a Snort box right outside of your email server and see what you get.
Yes, they could sniff the traffic, but they're not going to be blocking it - if the backbone routers start blocking traffic then the internet is frankly doomed. If the backbone routers start parsing traffic to work out what to filter they would fall over from the load. And if my ISP starts filtering my traffic then I'll damned well find an ISP with a clue.
Your are still looking at it at to high of a level. VoIP is still nothing more than data encapsulated into an IP packet. Once the data is transmitted via IP it can be sniffed and captured.
Yes, and as my original message said - how are they going to stop me encapsulating it in IPsec? I wasn't arguing that you couldn't sniff VoIP traffic (indeed you can and there are utilities that will output a wav file of the conversation if you feed them tcpdump logs), my arguement was that it's completely unenforcable because they can't stop people using whatever the hell protocol they want - encryption or no.
Capturing IP packets is trivial. Sincce VoIP is nothing but IP encapsulated data, sniffing and capturing phone conversations should be just as trivial as long as you have the resources to rebuild the voice and break the encryption.
Ok, I'll hand you an IPSEC encrypted VoIP stream and you tell me what the conversation was about - if they have the technology to break encryption they wouldn't need to have legislation saying that the protocol allows for them to listen in would they?
I don't see the need for "VOIP networks" - please explain the concept?
(see my other post)
Who provides you your DSL connection?
My ISP, but they are not a telephone provider and will not be dictating what protocols I can and can't use, nor will they be charging me on a per-second basis for my phone calls (ok, eventually we might each end up paying for the bandwidth we use, but the bandiwdth used by voice calls is tiny compared to the bandwidth used for surfing the web and downloading pr0n so the bandwidth cost of telephony will be largely irrelevent).
When people send email to your server from somewhere else, there are lots of middleman involved.
Yes, but again, they are not going to be dictating what protocols I can use - some random router on the internet isn't going to sit there sniffing TCP traffic on port 25 and reject it because I'm sending an encrypted email - only the mail relays are in a position to do that.
That is the hole concept behind routing. When I said "provider" I was meaning your data provider or better known as ISP.
By "end-to-end" I meant that the protocols don't rely on there being lots of VoIP relays understanding the protocol and routing it - the source VoIP server connects directly to the destination server, the routers between just do IP routing and don't know/care what protocol I'm using over IP. The backbone routers are not in a position to be stopping me using whatever protocols I want.
If you are using a provider, are you not actually sitting on that providers network?
See my other comment...
I'm not entirely sure who the "providers" are you're talking about - doing VoIP over the internet involves 2 endpoints talking to eachother. I don't see why you need any telephone "providers" involved at all. It's the same as email - I don't pay an "email provider" to route my mail for me (and maybe charge per mail or something), I run a mail server on the end of my DSL line and people wanting to email me send to there, no middlemen involved.
For eaxmeple, lets say that I am using provider A, and make a VoIP call to a subscriber that uses provider B. Don't my packets travel from my phone to provider A's network, bounce around in their until they are routed to provider B's network, bounce around their until they get routed to the other VoIP phone that I am calling.
As far as I'm concerned, you have an IP phone plugged into your internet account and you dial another IP phone either by entering an IP address, DNS name or real phone number (translated by an ENUM DNS lookup). What are these providers doing? Why do you need them? Do you subscribe to an "SSH provider" to route your SSH sessions to the right server?
errm... how?
How exactly do you stop the cpu executing the stack if there is no way to mark it as non-executable?
most of us should run with a no executable stack theses days
Ah, you mean the vast majority of people are now running Athlon64's? (tip: Plain IA32 CPUs don't support the NX bit).
If you do that (which is probably a good idea) you'll need to weight it based on the amount of code written by that author that _could_ contain a security hole. Otherwise the stats will just show that the authors who write 99% of the complex network-facing code are responsible for most security holes.
Another way of killing the problem is using the NX (I hope I got that correct) instruction/bit in newer CPUs and simply separate code and data, and not allow execution in a data segment. Win SP2 does this, I am sure Linux does/will soon
Yep, Fedora Core 2 has done this since one of the early kernel revisions (I think it was when they went from 2.6.5 to 2.6.6)
But if you use an IP Phone, you probably have to have an account with at firm that provides some kind of phone service
:)
See my other comment about this.
You don't want to go around remembering the ip v6 for all your friends
There's a thing called DNS, it lets you use easy to remember names instead of IP addresses... Or do you email people using their IP addresses?
At least that's my unqualified gues since I don't "know" the VoIP systems in the US.
I'm in the UK, but I don't see why this is different anywhere else - I have Asterisk running on my server which handles my IP phones. My server also has an FXO card in it that lets me make and receive calls over my POTS line. The only 3rd-parties involved are:
1. My telco when I make PSTN calls over my POTS line (but that's just like having a plain POTS phone)
2. e164.org - for translating phone numbers into VoIP addresses using DNS (this is _lookups_ only, no actual voice traffic involved here)
3. VoipUser who provide some incoming PSTN DDIs for me over the internet
So the only "tappable" third parties there are only involved when I'm making calls via the PSTN - VoIP calls are always made directly. I honestly can't see a place for any VoIP service providers except VoIP-PSTN gateways and maybe voicemail providers, etc in the event your internet connection breaks or your server goes down.
We are only talking about centralized networks. This is not likely to pertain to or be enforceable regarding decentralized or private networks.
This is going a bit offtopic, but maybe you can explain why anybody even needs centralised VoIP networks? The nature of VoIP is that it is end-to-end - the only time you need middlemen doing any VoIP gatewaying is when you need to gateway VoIP traffic to the PSTN. You don't pay for an "email provider", you run your own server instead - how is VoIP any different?
And if you're saying you need a VoIP provider to connect your phone to on a pay-per-minute basis and then they work out what needs to go over the PSTN and what goes over the internet (in a you-don't-need-to-know kind of way), that isn't at all the case - the ENUM system is designed to map normal phone numbers to VoIP servers using DNS. So your VoIP server can make a DNS lookup for the phone number you're calling - if it resolves then your VoIP server makes a direct connection (costing you only bandwidth) and if it doesn't resolve then you need to call over the PSTN, either by routing VoIP via a PSTN gateway (and paying them accordingly) or by having your VoIP server connected to the PSTN itself and paying your normal telco for placing the call.
In the next few years, I think we can expect to see the PSTN slowly vanish in favor of doing everything over the internet - we probably need a bit more infrastructure such as MX-style DNS records, but in the long run I can't see how we will actually need any "telephone providers" - all calls can be made directly over IP without using any middlemen.
I don't understand how this is enforcable - VoIP is an end-to-end system - no middlemen are needed. How are they going to stop me doing VoIP over an IPSEC connection?
OpenGravity is nolonger available as the courts have ruled it is infringing Microsoft's patent on gravity.
I believe that's technically incorrect. If your speedometer shows 70 and you're going 76, it's still within the tolerance permitted by the MoT test, and I understand that you're not speeding.
AFAIK that's not the case - as I understand it there is a 10% tollerance on the MoT but no such tollerance on the actual law (so technically to be definately within the limit you should be cruising at 63mph, which is downright stupid). However, all the cars I've travelled in always have the speedo read over (according to the GPS) - when I'm doing 70mph my speedo is reading about 74mph, so cruising with the speedo reading 70mph is quite safe.
I do, however, wish that they would raise the speed limit to 80mph on the motorways and then properly inforce it with SPECS cameras.
They also keep putting in GATSO cameras despite plenty of evidence that they actually increase the number of fatalities (people cruise down the road and slam on the brakes when they see the camera... the guy who's tailgating behind them promptly slams into the back of them.) The answer is SPECS cameras, which do a good job (they average your speed over sections of road rather than just looking at your speed at one particular point, so if you accidentally creep over the limit for a second you don't get fined). Of course SPECS cameras actually effectively make people slow down so the police won't put them in since they can't issue as many fines.
The very silly thing is there are a few stretches a road in the UK with so many cameras on them that if you speed down the stretch of road you can lose your licence within a couple of miles - there should be some laws stopping that situation, people with a clean driving licence shouldn't be able to get banned for driving just by going 10mph over the limit for 2 miles.
An excellent example of why GATSOs shouldn't be used is Bournemouth - I go through it fairly frequently, I know exactly where the cameras are. The speed limit is 50mph, the road is reasonably straight, but if I wanted to (I don't) I could do 90mph down that stretch of road, just braking down to 50 for each camera.
EXIF headers (used by practically every digital camera) store time and date information, amoungst other very useful data.
Similarly you could sort by exposure settings, etc. if you really wanted.
Nothing new here, move along.