As seems typical with this government they don't think through the consequences of their laws (or proposed laws). A good law should: 1) Feel guilty if I break. (not applicable in this case cause it is a proscriptive law) 2) Solve a problem.. In this case it will just lead to more off shore services, encryption and obfuscation in existing communications. This will just lift the bar so that a warranted tap will no longer be likely to provide anything useful. 3) Hurt the bad guys more than the good guys. This just lifts the cost for everybody and depending on what the ISPs need to do to collect this data then it may effect performance. 4) Be technically possible.
I've got a plan with a static IP so my ISP doesn't do any transparent proxying so they don't automaticaly get my URL history. I'm running my own mail server so they don't get my email information. I trust them becuase I know they couldn't afford to be bothered.
So the ISP is going to have to start doing deep packet inspection on all my traffic to pull out these bits of information to log. That starts to get expensive and intrusive to their operations and my bill.
If we start to use more TLS on our smtp connections then they just won't have the information to log.
If they are logging URLs then I'd be tempted to do my backups with encrypted data in the get request. Can't be compressed and can't be used. This sort of attack with expensive noise could be implemented on a lot of websites... Say google with their stance against the Australian governments stupidity put more hash codes in their URLs. It would make the hard drive manufacturers rich trying to supply the ISPs fast enough.
I'm not sure that I'd want to learn C as my first language. Such a general and powerful language can get in the way of the lesson being taught.
I'm a fan of swapping between whatever language suits the lessons being taught. It helps the lesson by getting rid of the hoops you need to jump through to make it work. As a side effect it removes the fear of using a different language that some people have.
I think pascal is a good general purpose teaching language. Java maybe but I think the OO + structures libraries would hide the lessons that should be taught. Don't know python. VB could be used as an example of what not to do.
In high school we used Pascal as the teaching language. The move to C for a robotics competition we entered was trivial because by that stage we had enough background to cope with the typing and pointers that C doesn't baby you with.
A uni course I did used C++ and java for OO. I struggled a little because the languages weren't pure OO and a lecturer who didn't understand OO lead to the languages being misused. I think it would have been easier to get the point if we had one of the extremely theoretical OO languages.
What? That's what the ISP is payed for. If they don't advertise the routes we give them then they won't receive the traffic we want them to forward to us. If they don't forward their BGP routes from the rest of the Internet how do we know what they can reach (hopefully everything but probably nothing if they don't forward BGP)?
Hopefully they are being reasonably careful with their filtering but there is not an awful lot they can do. Hopefully they make sure that we only advertise our routes against our AS number but they can't even filter out our routes/AS number from other ISPs cause that might be the preferred/available path.
With utilities, you are using consumable resources. Water costs per gallon. Gas costs per cubic foot. Electricity costs per ton of coal. If you don't use these resources in your home, then the utility doesn't burn up these resources at their end.
With the internet, the "utility" uses bits whether customers data are in those packets or not. As a second goes by, X number of Mbits are used and gone forever. You CANNOT save them like the other utilities I mentioned. It doesn't matter if anyone was using the network then or not, the resource is available and then gone forever.
That's why I think you should pay for a data RATE. Not a data QUANTITY.
But there are multiple rates when talking about Internet services. There is the rate that I connect to my ISP. In my case this is pretty high but is a shared MAC layer with a number of other customers so divide by X.
There is also the rate that my ISP connects to their peers/providers. This is divided amongst all the ISPs customers.
Now being a user I want a fast connection to the Internet because that gets my pages/pics/movies/whatever to me quicker but I don't want to be afford the cost of that bandwidth as a CIR all the way through the Internet core. I make this affordable by buying a share of the ISPs aggregate bandwidth. They charge me for this at a RATE of X gigabytes per month. The ISP then manages all the peering arrangements, the upstream bandwidth rates etc and they do it for a more reasonable price than I could myself.
To me the best model for Internet provision are capped plans. My reasons are: 1) I can get a faster pipe to the Internet than I could afford otherwise. 2) I don't get any surprises in my bill that might occur if I had a straight metered plan. 2) My ISP has an incentive to give me more bandwidth upstream. The more I can use the higher priced cap I might go onto. To some degree they are being payed for the bandwidth I waste. 3) The ISP gets a reasonably consistent revenue stream. This makes it easy to plan staff levels and upgrade costs etc.
Peering links are the subject of negotiation and the ISPs don't seem to understand their position.
I pay for my internet link. I'm not providing anything my ISP wants other than cash. I pay a competitive rate cause my ISP has competition that I'd churn to.
The lower link tier ISPs pay for their uplinks because the higher tier ISPs provide a service they want.
Google gets good deals cause they pay heaps for data centers and their own comms links and the ISPs that they peer with save when they connect.
If somebody said they could save me 6-7% of my upstream charges if I gave them a port on my router I'd jump at that deal.
If you don't like the deal that google is offering don't accept it. You just have to pay your upstream peers for the traffic. If you don't like the deal they are offering either churn to somebody else or don't offer access to the complete Internet. I guess that if you didn't offer access to the complete Internet then your subscribers would churn to somebody who did.
One of the advantages of the Internet is the tiered structure. I pay my ISP to negotiate the routing with their peers/providers. They pay for their access and hopefully have agreements for local routes that make that cheaper.
The gerbil or hand crank sound's like a good idea.
I was running with the $1000/kW idea. A 4mW reactor would cost.4c but then I thought the telcos would probably be involved at some point and we would be charged 40c blowing the budget and making it way to hard.
Photons don't have mass but they do have momentum. This leads to a photon or radiation pressure that is part of the idea behind solar sails.
Unfortunately the amount of momentum for the energy is pretty small. E^2 = p^2.c^2 + m^2.c^4 m=0 big factor of divide by c. Most laser propultion strategies use solar panels + ion drives or ablation or something to accelerate a local mass to provide the change in momentum.
Your walking down the street in the business district (it was a com domain). Your wearing your press hat (your coming from a press computer). One of you friends says you should check out the transport planning office. You walk up to the building labeled "transport planning office" and the automatic doors open in a welcoming way. You look around the foyer and there are posters saying all sorts of interesting stuff about plans for buses, trains and cycling etc. There are no posters saying bugger off this is still draft and private.
I wouldn't feel like I'd done anything immoral by reading them. If I was a reporter I'd report on what I'd read as well.
If you put something in a public place and don't provide a mechanism to keep people out like locking the doors or putting a keep out sign up then it is public.
Apple computers had their logo first so I don't think they would be trying to grab marketing value from Woolworths. If you mean woolies was trying to take marketing off Apple then I don't think that would work. Woolworths is much more "famous" than Apple in their marketing area.
Woolies haven't really had a logo previously. They've been trying to consolidate their image over the last while (i.e. I believed they've ditched the safeway branding). Their jingle is "The fresh food people" so a logo that looks like an apple, mellon, pumpkin or something matches there existing marketing. They also have the "Big W" brand so this is probably a move to consolidate them as well.
If apple wanted a strong logo that was defendable outside the area where it was registered (computing) then they should have picked something a but more unique. Apple logos are and have been used as part of fruit, education (give your teacher an apple) and health (an apple a day keeps the doctor away) markets for longer than apple computers have been around. I don't think the Apple logo is distinctive enough to survive registration as a generic logo where as a green stylised W that give the feeling of fruit or vegetables is much friendlier logo for the registration purpose.
On a side note it wouldn't surprise me if Woolworths is the biggest apple computer reseller in Australia through DSE, Tandy and BigW brands. My MBP was brought through one of their stores.
My personal favourite technical solution is to use some sort of IP hash based token bucket filter. Protocol and service agnostic which is good because any weird protocol based definition of fair would be outdated soon in this world. Doesn't rely on the client/server to behave in a fair way.
Basically everybody gets the same share of the available bandwidth. Since it is based on IP rather than tcp backing off it is relatively immune to P2Ps many connections causing it to unfairly back off. Also immune to short lived http connections not having enough time to settle. The heavy down loaders get their fair share of the bandwidth which is not necessarily true at the moment with the way P2P opens many connections and the way Naggle backs off tcp.
Most implementations have a concept of bursting so that if your link is quiet then you can get a burst for a few packets. Good for the interactive feel for normal browsing.
Good for the ISP in that while it consumes router resources they are limited by the number of hash buckets configured. It would be unfortunate if you were in a hash collision with somebody who was a heav user but normaly the hash is rotated every few seconds to limit this damage.
For the use of the real time protocols SIP/RTP etc then ISP could even honour packet tagging within your bucket. i.e. your voip wins over your P2P but somebody elses voip doesn't impact your P2P.. Currently packet tagging on the internet is pretty useless because the packets are competing against somebody elses definition of important.
My little brother's work has a no fly zone over it. Even the birds don't fly over a second time....
He showed me a photo of some wings with some carbon between them.
Not a solution for airports cause apparently they can do that to pilots as well (hence the NOTAM restricted area). >20kW of microwave energy and a very directional antenna could be an amusing toy. I wonder what the bit error rate is from cooking a bird?
If your planning a HA solution my first step is to decide what you are trying to protect against, what the cost/consequence of these events occurring and a method to test failure events.
I've seen projects where the HA configuration has contributed to more downtime than any specific failure. I've seen projects that were too "important" to schedule test failures so when it did fail it didn't fail over.
In a lot of cases if a specialist site is down then people would come back later. If your consequences are not that high for an outage then save your money for good backups and good support contracts and maybe a cold/warm spare. If slashdot crashed now I'd just check again next time I had a chance.
A HA solution has to be designed from end to end. This isn't easy and some of your components may not work in a compatible way(black box software). Static content can be pretty easy to load balance/failover but once you start getting into dynamic content things become more complicated and uncertain.
If you have to worry about session persistence an unexpected event might redistribute connections causing existing connections to break for something that was very transient. i.e. it amplifies a minor fault.
I've seen applications that didn't pass their status through to the web server. There was a significant back end failure and the web server was still returning "200 OK" responses to the requests. The other servers were still working correctly and due to session persistence the people diagnosing the issue initially didn't realise that 25% of sessions were empty pages. The developer should have provided checks in their code, the load balancer could have done a different check, the initial level 1 support didn't really understand the system. All these have costs and consequences. i.e. development time and skills, risk that a content change might cause a service check to fail, training costs.
Exactly. Its not the protocol that's the problem. Its the way that people think that their usage is more important that others and the way that ISPs (or TCP) enforce fairness.
There needs to be a good, neutral, technical definition of fair. Because you can't trust the end points to be fair it needs to be enforceable via the ISP. It would be reasonably easy to hack a tcp stack to not back off. All the well behaved TCP connections from other users would just get out of your way.
My proposal is some sort of hashed token bucket scheme. The hashing should be done on the basis of the local IP addresses. Maybe hash buckets could be different sizes due to different link/plan sizes. Number of buckets could be kept reasonably low to save router resources.
Maybe their could be a borrow feature. i.e. casual browsing gives a burst of performance for better interactive feel.
This way all users get an equal share of the available bandwidth. P2P users get what is available without being squeezed by some unfair throttling policy. HTTP users get the interactive performance they want or their fair share for a single download. Voip/Video users get a minimum bandwidth to keep them happy. Future protocols, hacks and attacks are handled in a fair, robust, limited way before they are invented.
The other problem is that there appears to be an assumption that ISP users are idiots and its too hard to market otherwise. This has lead to the situation where:
1) Links are sold based on the last mile pipe size. Big is better because its faster/less latency. This is often true but isn't the only one factor. 2) All you can eat plans exist because of the assumption that users don't understand concepts like shared back haul and shared upstream. They also tend to have vague acceptable use policies around impact to others etc.
My ISP tends to be pretty good on this. I'm on a wireless capped plan. The ISP is pretty clear that this is a shared medium. They use a technology that divides this fairly.(as much as they can on ISM band equipment)
Because I'm paying for the cap size there is a commercial incentive for the ISP to keep the upstream bandwidth unsaturated. i.e. I'd be paying for a cheaper plan if I couldn't use the bandwidth.
My ISP is also open about their status. Their mailing list tells about outage, capacity problems and planned upgrades. Running towers on tops of hills means that they occasionally loose capacity due to lightning etc. Being told about this makes it easier for me to plan around the issue.
I'd been listening to the HHGTTG on the laptop while cooking dinner and had just sat down to eat. Top article is about HHGTTG and there are (well were) 42 posts...
Probably infinitely improbable! When will normality return? I haven't knocked the flower pot off the bench yet(again).
Not following the RFC fucks more innocent bystanders.
We get lots of help desk calls because some stupid(but innocent) user spells an email address wrong and they don't get a bounce and they blame us for not delivering it.
If somebody has a problem with back scatter then they obviously don't have their SPF records set up correctly. They aren't so innocent. I'm getting spam traffic from their domain.
The problem gets worse when the spam lists blame a properly configured SPF configuration for back scatter. To solve that the bounces all come from a host that is on every black list know which is sort of embarrassing but seems to keep most people happy.
In this case I don't think gmail is breaking the RFC.. The email was deliverable. It was just definitely spam (the owner of the domain said so) because an RFC broken forwarder couldn't rewrite properly.
Version 2. A little more reliable. A virus doesn't want to delete the contacts list before replicating..
This is an open-source virus. Pass me along to 10 friends and then delete some files at random. Please don't break the chain. One sorry person broke the chain and the next day found someone had hacked into their computer and installed Vista.
I can't think of any good reason not to accept the certificate in this case and some good reasons to accept it permanently.
What it provides: 1) A packet dump in the middle won't show what I was doing on the site (but flow statistics might give it away a bit). Any attack has to be active. 2) It lifts the bar on man in the middle attacks.. Somebody has to do some crypto as well as intercept the traffic.. 3) Provides evidence for future connections that there was a man in the middle attack or there is a new man in the middle attack. If the key changes then you know that something is or was wrong.. Start cleaning your hard drive;-)
The alternatives are: 1) Straight http. No advantages over https with self signed certs. Easy to man in the middle and capture traffic. 2) Trusted CA signed cert. The main disadvantage here is that the users probably don't want to tell the CA that they were visiting this particular site. Whenever you connect to a SSL site then your browser SHOULD be doing a OCSP check with the CA to find out about the validity of the certificate. If I was running a dodgy site I wouldn't want my users to be sending this sort of information to Verisign.
I would treat the SSL certificate from my bank differently.
I agree about the problems with normal users ignoring browsers complaining about too many things.
Slashdot Mirror
As seems typical with this government they don't think through the consequences of their laws (or proposed laws). A good law should:
1) Feel guilty if I break. (not applicable in this case cause it is a proscriptive law)
2) Solve a problem.. In this case it will just lead to more off shore services, encryption and obfuscation in existing communications. This will just lift the bar so that a warranted tap will no longer be likely to provide anything useful.
3) Hurt the bad guys more than the good guys. This just lifts the cost for everybody and depending on what the ISPs need to do to collect this data then it may effect performance.
4) Be technically possible.
I've got a plan with a static IP so my ISP doesn't do any transparent proxying so they don't automaticaly get my URL history. I'm running my own mail server so they don't get my email information. I trust them becuase I know they couldn't afford to be bothered.
So the ISP is going to have to start doing deep packet inspection on all my traffic to pull out these bits of information to log. That starts to get expensive and intrusive to their operations and my bill.
If we start to use more TLS on our smtp connections then they just won't have the information to log.
If they are logging URLs then I'd be tempted to do my backups with encrypted data in the get request. Can't be compressed and can't be used. This sort of attack with expensive noise could be implemented on a lot of websites... Say google with their stance against the Australian governments stupidity put more hash codes in their URLs. It would make the hard drive manufacturers rich trying to supply the ISPs fast enough.
I'm not sure that I'd want to learn C as my first language. Such a general and powerful language can get in the way of the lesson being taught.
I'm a fan of swapping between whatever language suits the lessons being taught. It helps the lesson by getting rid of the hoops you need to jump through to make it work. As a side effect it removes the fear of using a different language that some people have.
I think pascal is a good general purpose teaching language. Java maybe but I think the OO + structures libraries would hide the lessons that should be taught. Don't know python. VB could be used as an example of what not to do.
In high school we used Pascal as the teaching language. The move to C for a robotics competition we entered was trivial because by that stage we had enough background to cope with the typing and pointers that C doesn't baby you with.
A uni course I did used C++ and java for OO. I struggled a little because the languages weren't pure OO and a lecturer who didn't understand OO lead to the languages being misused. I think it would have been easier to get the point if we had one of the extremely theoretical OO languages.
Secondly, no sane ISP will forward BGP data.
What? That's what the ISP is payed for. If they don't advertise the routes we give them then they won't receive the traffic we want them to forward to us. If they don't forward their BGP routes from the rest of the Internet how do we know what they can reach (hopefully everything but probably nothing if they don't forward BGP)?
Hopefully they are being reasonably careful with their filtering but there is not an awful lot they can do. Hopefully they make sure that we only advertise our routes against our AS number but they can't even filter out our routes/AS number from other ISPs cause that might be the preferred/available path.
That's a cute idea, but it is wrong.
With utilities, you are using consumable resources. Water costs per gallon. Gas costs per cubic foot. Electricity costs per ton of coal. If you don't use these resources in your home, then the utility doesn't burn up these resources at their end.
With the internet, the "utility" uses bits whether customers data are in those packets or not. As a second goes by, X number of Mbits are used and gone forever. You CANNOT save them like the other utilities I mentioned. It doesn't matter if anyone was using the network then or not, the resource is available and then gone forever.
That's why I think you should pay for a data RATE. Not a data QUANTITY.
But there are multiple rates when talking about Internet services. There is the rate that I connect to my ISP. In my case this is pretty high but is a shared MAC layer with a number of other customers so divide by X.
There is also the rate that my ISP connects to their peers/providers. This is divided amongst all the ISPs customers.
Now being a user I want a fast connection to the Internet because that gets my pages/pics/movies/whatever to me quicker but I don't want to be afford the cost of that bandwidth as a CIR all the way through the Internet core. I make this affordable by buying a share of the ISPs aggregate bandwidth. They charge me for this at a RATE of X gigabytes per month. The ISP then manages all the peering arrangements, the upstream bandwidth rates etc and they do it for a more reasonable price than I could myself.
To me the best model for Internet provision are capped plans. My reasons are:
1) I can get a faster pipe to the Internet than I could afford otherwise.
2) I don't get any surprises in my bill that might occur if I had a straight metered plan.
2) My ISP has an incentive to give me more bandwidth upstream. The more I can use the higher priced cap I might go onto. To some degree they are being payed for the bandwidth I waste.
3) The ISP gets a reasonably consistent revenue stream. This makes it easy to plan staff levels and upgrade costs etc.
Peering links are the subject of negotiation and the ISPs don't seem to understand their position.
I pay for my internet link. I'm not providing anything my ISP wants other than cash. I pay a competitive rate cause my ISP has competition that I'd churn to.
The lower link tier ISPs pay for their uplinks because the higher tier ISPs provide a service they want.
Google gets good deals cause they pay heaps for data centers and their own comms links and the ISPs that they peer with save when they connect.
If somebody said they could save me 6-7% of my upstream charges if I gave them a port on my router I'd jump at that deal.
If you don't like the deal that google is offering don't accept it. You just have to pay your upstream peers for the traffic. If you don't like the deal they are offering either churn to somebody else or don't offer access to the complete Internet. I guess that if you didn't offer access to the complete Internet then your subscribers would churn to somebody who did.
One of the advantages of the Internet is the tiered structure. I pay my ISP to negotiate the routing with their peers/providers. They pay for their access and hopefully have agreements for local routes that make that cheaper.
The gerbil or hand crank sound's like a good idea.
I was running with the $1000/kW idea. A 4mW reactor would cost .4c but then I thought the telcos would probably be involved at some point and we would be charged 40c blowing the budget and making it way to hard.
And this is better than building a cat and stroking his organ?
Building a pussy to stroke his organ?
Photons don't have mass but they do have momentum. This leads to a photon or radiation pressure that is part of the idea behind solar sails.
Unfortunately the amount of momentum for the energy is pretty small. E^2 = p^2.c^2 + m^2.c^4 m=0 big factor of divide by c. Most laser propultion strategies use solar panels + ion drives or ablation or something to accelerate a local mass to provide the change in momentum.
Actually in Australia they work for four letter agencies.
Like DSD and AFP :-)
(OK OK Maybe ASIO)
A better analogy.
Your walking down the street in the business district (it was a com domain). Your wearing your press hat (your coming from a press computer). One of you friends says you should check out the transport planning office. You walk up to the building labeled "transport planning office" and the automatic doors open in a welcoming way. You look around the foyer and there are posters saying all sorts of interesting stuff about plans for buses, trains and cycling etc. There are no posters saying bugger off this is still draft and private.
I wouldn't feel like I'd done anything immoral by reading them. If I was a reporter I'd report on what I'd read as well.
If you put something in a public place and don't provide a mechanism to keep people out like locking the doors or putting a keep out sign up then it is public.
Apple computers had their logo first so I don't think they would be trying to grab marketing value from Woolworths. If you mean woolies was trying to take marketing off Apple then I don't think that would work. Woolworths is much more "famous" than Apple in their marketing area.
Woolies haven't really had a logo previously. They've been trying to consolidate their image over the last while (i.e. I believed they've ditched the safeway branding). Their jingle is "The fresh food people" so a logo that looks like an apple, mellon, pumpkin or something matches there existing marketing. They also have the "Big W" brand so this is probably a move to consolidate them as well.
If apple wanted a strong logo that was defendable outside the area where it was registered (computing) then they should have picked something a but more unique. Apple logos are and have been used as part of fruit, education (give your teacher an apple) and health (an apple a day keeps the doctor away) markets for longer than apple computers have been around. I don't think the Apple logo is distinctive enough to survive registration as a generic logo where as a green stylised W that give the feeling of fruit or vegetables is much friendlier logo for the registration purpose.
On a side note it wouldn't surprise me if Woolworths is the biggest apple computer reseller in Australia through DSE, Tandy and BigW brands. My MBP was brought through one of their stores.
We've always joked that the squeaky pigeons needed their wings oiled.
My personal favourite technical solution is to use some sort of IP hash based token bucket filter. Protocol and service agnostic which is good because any weird protocol based definition of fair would be outdated soon in this world. Doesn't rely on the client/server to behave in a fair way.
Basically everybody gets the same share of the available bandwidth. Since it is based on IP rather than tcp backing off it is relatively immune to P2Ps many connections causing it to unfairly back off. Also immune to short lived http connections not having enough time to settle. The heavy down loaders get their fair share of the bandwidth which is not necessarily true at the moment with the way P2P opens many connections and the way Naggle backs off tcp.
Most implementations have a concept of bursting so that if your link is quiet then you can get a burst for a few packets. Good for the interactive feel for normal browsing.
Good for the ISP in that while it consumes router resources they are limited by the number of hash buckets configured. It would be unfortunate if you were in a hash collision with somebody who was a heav user but normaly the hash is rotated every few seconds to limit this damage.
For the use of the real time protocols SIP/RTP etc then ISP could even honour packet tagging within your bucket. i.e. your voip wins over your P2P but somebody elses voip doesn't impact your P2P.. Currently packet tagging on the internet is pretty useless because the packets are competing against somebody elses definition of important.
My little brother's work has a no fly zone over it. Even the birds don't fly over a second time....
He showed me a photo of some wings with some carbon between them.
Not a solution for airports cause apparently they can do that to pilots as well (hence the NOTAM restricted area). >20kW of microwave energy and a very directional antenna could be an amusing toy. I wonder what the bit error rate is from cooking a bird?
If your planning a HA solution my first step is to decide what you are trying to protect against, what the cost/consequence of these events occurring and a method to test failure events.
I've seen projects where the HA configuration has contributed to more downtime than any specific failure. I've seen projects that were too "important" to schedule test failures so when it did fail it didn't fail over.
In a lot of cases if a specialist site is down then people would come back later. If your consequences are not that high for an outage then save your money for good backups and good support contracts and maybe a cold/warm spare. If slashdot crashed now I'd just check again next time I had a chance.
A HA solution has to be designed from end to end. This isn't easy and some of your components may not work in a compatible way(black box software). Static content can be pretty easy to load balance/failover but once you start getting into dynamic content things become more complicated and uncertain.
If you have to worry about session persistence an unexpected event might redistribute connections causing existing connections to break for something that was very transient. i.e. it amplifies a minor fault.
I've seen applications that didn't pass their status through to the web server. There was a significant back end failure and the web server was still returning "200 OK" responses to the requests. The other servers were still working correctly and due to session persistence the people diagnosing the issue initially didn't realise that 25% of sessions were empty pages. The developer should have provided checks in their code, the load balancer could have done a different check, the initial level 1 support didn't really understand the system. All these have costs and consequences. i.e. development time and skills, risk that a content change might cause a service check to fail, training costs.
Exactly. Its not the protocol that's the problem. Its the way that people think that their usage is more important that others and the way that ISPs (or TCP) enforce fairness.
There needs to be a good, neutral, technical definition of fair. Because you can't trust the end points to be fair it needs to be enforceable via the ISP. It would be reasonably easy to hack a tcp stack to not back off. All the well behaved TCP connections from other users would just get out of your way.
My proposal is some sort of hashed token bucket scheme. The hashing should be done on the basis of the local IP addresses. Maybe hash buckets could be different sizes due to different link/plan sizes. Number of buckets could be kept reasonably low to save router resources.
Maybe their could be a borrow feature. i.e. casual browsing gives a burst of performance for better interactive feel.
This way all users get an equal share of the available bandwidth. P2P users get what is available without being squeezed by some unfair throttling policy. HTTP users get the interactive performance they want or their fair share for a single download. Voip/Video users get a minimum bandwidth to keep them happy. Future protocols, hacks and attacks are handled in a fair, robust, limited way before they are invented.
The other problem is that there appears to be an assumption that ISP users are idiots and its too hard to market otherwise. This has lead to the situation where:
1) Links are sold based on the last mile pipe size. Big is better because its faster/less latency. This is often true but isn't the only one factor.
2) All you can eat plans exist because of the assumption that users don't understand concepts like shared back haul and shared upstream. They also tend to have vague acceptable use policies around impact to others etc.
My ISP tends to be pretty good on this. I'm on a wireless capped plan. The ISP is pretty clear that this is a shared medium. They use a technology that divides this fairly.(as much as they can on ISM band equipment)
Because I'm paying for the cap size there is a commercial incentive for the ISP to keep the upstream bandwidth unsaturated. i.e. I'd be paying for a cheaper plan if I couldn't use the bandwidth.
My ISP is also open about their status. Their mailing list tells about outage, capacity problems and planned upgrades. Running towers on tops of hills means that they occasionally loose capacity due to lightning etc. Being told about this makes it easier for me to plan around the issue.
Don't save the big one for last.
I guess that solves the x-ray problem. Lots of glue for next xmas.
I'd been listening to the HHGTTG on the laptop while cooking dinner and had just sat down to eat. Top article is about HHGTTG and there are (well were) 42 posts...
Probably infinitely improbable! When will normality return? I haven't knocked the flower pot off the bench yet(again).
As someone who watches a lot of movies, I think I can help them find it. I suggest you look for the ominous looking computer with a single red eye.
And I'm sure that the evil red eye has f5 written on it.
Who cheered when they exploded the server room full of bigips in Swordfish?
Can't live without them but I know they watching all my traffic.
Well they don't use powers of 1024 but powers of 2. ;)
Ummm. They do use powers of 1024 because they want to match the SI prefixes reasonably closely.
1024 is used because it is a power of two making the SI approximations powers of two.
1 B = 1024^0
1 KiB = 1024^1
1 MiB = 1024^2
1 GiB = 1024^3 and on.
Not following the RFC fucks more innocent bystanders.
We get lots of help desk calls because some stupid(but innocent) user spells an email address wrong and they don't get a bounce and they blame us for not delivering it.
If somebody has a problem with back scatter then they obviously don't have their SPF records set up correctly. They aren't so innocent. I'm getting spam traffic from their domain.
The problem gets worse when the spam lists blame a properly configured SPF configuration for back scatter. To solve that the bounces all come from a host that is on every black list know which is sort of embarrassing but seems to keep most people happy.
In this case I don't think gmail is breaking the RFC.. The email was deliverable. It was just definitely spam (the owner of the domain said so) because an RFC broken forwarder couldn't rewrite properly.
My wording is
-BSD ensures freedom of the "recipient" of the CODE to do what they want. No promises for the recipient of a BINARY.
-GPL ensures freedom of the "recipient" of the BINARY to do what they want with the CODE(except WRT distribution.)
Version 2. A little more reliable. A virus doesn't want to delete the contacts list before replicating..
This is an open-source virus. Pass me along to 10 friends and then delete some files at random. Please don't break the chain. One sorry person broke the chain and the next day found someone had hacked into their computer and installed Vista.
I can't think of any good reason not to accept the certificate in this case and some good reasons to accept it permanently.
What it provides:
1) A packet dump in the middle won't show what I was doing on the site (but flow statistics might give it away a bit). Any attack has to be active.
2) It lifts the bar on man in the middle attacks.. Somebody has to do some crypto as well as intercept the traffic..
3) Provides evidence for future connections that there was a man in the middle attack or there is a new man in the middle attack. If the key changes then you know that something is or was wrong.. Start cleaning your hard drive;-)
The alternatives are:
1) Straight http. No advantages over https with self signed certs. Easy to man in the middle and capture traffic.
2) Trusted CA signed cert. The main disadvantage here is that the users probably don't want to tell the CA that they were visiting this particular site. Whenever you connect to a SSL site then your browser SHOULD be doing a OCSP check with the CA to find out about the validity of the certificate. If I was running a dodgy site I wouldn't want my users to be sending this sort of information to Verisign.
I would treat the SSL certificate from my bank differently.
I agree about the problems with normal users ignoring browsers complaining about too many things.