IIRC the problem isn't with computers that don't support IPv6. It's with networks where the computers and DNS software does support IPv6 but there's no IPv6 connectivity. In those cases a name query gets back AAAA records, the computer tries to connect via IPv6, and the connection doesn't go through because IPv6 traffic doesn't have a route off the local network. If your computers don't support IPv6 at all, the problem doesn't happen (the AAAA records never get used). If the DNS software (probably in your router) doesn't support IPv6, it won't do queries for AAAA records in the first place. Note also that at the other end (the DNS servers for the web site's domain) there should also be filtering in place: AAAA records shouldn't be being returned in queries that came in via IPv4. But not all sites do that filtering, so clients have to be prepared to get IPv6-only data back in IPv4 responses and filter it out.
Which is odd, because where I work it's my personal computers that have never had a single bit of malware detected on them in 25 years and the company computers (never mine, because I run it like my personal computer as much as possible) which are constantly needing to be scrubbed of malware that got past the corporate security and anti-virus software.
Virtually no human testing? Given the kind of person who gets into the astronaut corps, I seriously doubt that. There's probably been no official investigation into this done, but when you coop seven mixed-gender, highly intelligent, very curious, extremely goal-driven, competitive problem-solvers up in a small ship for the lengths of time a shuttle mission runs, I think we can pretty much guarantee there's been plenty of unofficial investigations conducted. And there's been IIRC several mixed-gender ISS crews, so ditto there.
I also suspect they've found the entire exercise to be awkward, exhausting (and not in the good way), inconvenient to arrange around all the monitoring that's done, difficult to keep private in those cramped quarters, and generally an awful lot of work for a lot less reward than you'd expect. But if anybody wants to go to Mars they're going to have to figure out how to deal with sex and how to make it reasonably convenient, because no crew's going to remain completely celibate that long.
The story mentioned how you never see the VDI guys actually using VDI when they show up at a customer's site, they're always using traditional "fat" laptops. That's because their customer reps and engineers are on the customer's network and have to deal with all of it's firewalls, VPNs, filtering and other controls that aren't set up for VDI. And there's a whole lot of mobile stuff where you have to deal with the reality of living on someone else's network where you can't just change the configuration as needed.
Ordinary users. They don't use computers, they use applications. The computer's just the plumbing needed to make the applications work. They don't know tech, they don't want to know and they really shouldn't need to know. They need their applications, and they should have as little access to and control over the plumbing underneath them as practical. Give them the tools they need to do their job and leave the maintenance of those tools to the guys over in the tech shop.
Specialized users. These are people who have a particular skill or ability, something they were hired specifically because they can do, and they need particular special tools to do it. These people should get the tools they need and the access they need to do the jobs they were hired for. If needed, sandbox them. Don't try to force them into the "ordinary user" mold, they were hired because they aren't ordinary users and the fact they aren't is what makes them valuable to the business.
Developers. These are the people who're going to be writing the software everybody else is going to use. That means a couple of things. First, they're going to need more control over the systems they're using. They're going to have to debug problems and figure out how to configure things to make their software work, and they can't do that without a lot more access than normal. Second, they're by definition going to be working with stuff that isn't part of the normal setup. They're working on the next generation of stuff, obviously that's going to involve using the next generation of tools and supporting software too. And they tend to know more about the internals than even specialized users do. They know version control and all that, and they know all about the amount of work needed to recover from losing data and they want to avoid it if possible. Give them the control, sandbox them into a development network if needed, and trust them to do their jobs.
Systems and network administration and maintenance. These are the techies that make all the IT infrastructure work so #s 1-3 can do their jobs. If you're worrying about controlling their access and environment, you're missing the point: these are the people who've got root, who spend their workday in the internals of the system, they've got total access and control and they can't do their jobs without it. If you're worrying about them damaging things, you've got a more fundamental problem than access control. So stop worrying and again trust them to do their jobs. They don't want to damage the network, remember they're the ones who're going to have to clean up the mess and they don't want to make more work for themselves than they absolutely have to.
The higher the level you're at, the less useful thin clients tend to be. OTOH, at level 1 thin clients can be really useful if you've got control over the networks involved and can configure it so things work smoothly. Just don't try forcing someone at level 3 into an environment intended for level 1 (or vice-versa). It won't work, and you'll spend more time patching things up and finding workarounds for problems than you'll ever see in purported savings.
The problem is that it isn't your deployment where the problems lie. It's in everyone else's networks where they aren't deploying your VDI solution exactly the way you did, and so the networks aren't set up to make it "just work". If it's internal... well, you can manage desktops relatively easily using the same tools you use to manage the servers (or you should be able to at any rate, in the kinds of networks I'm used to the only difference between a desktop and a server is the video card and what software packages are installed). The only advantage VDI gives you is being able to host multiple desktops on a single box, but that becomes rather pointless when you don't need any special support to simply log in to a larger server the same way you'd log in to your desktop (XDMCP, it's not rocket science). And you don't even need to do anything special to keep users from installing or storing stuff locally, just don't give them a local login on the box on their desktop.
Virtualization has a lot of uses, but VDI seems to me to be an attempt to patch over all the problems created trying to graft network transparency onto a GUI/desktop system after having declared that you don't need network transparency in the GUI/desktop system. I look at it and go "But... we were doing this 20 years ago! What's making it so hard to do it today, and why are you tolerating it?".
Then again, I laugh at current Web developers struggling to implement the 3270 workstation (badly) and wonder when they're going to move to the VT100 like their predecessors did and for exactly the same reasons.
It's all a matter of connectivity. If you're using a traditional "fat" desktop (or notebook), you're self-contained. All your software's there, you aren't dependent on any connectivity to the outside world to get your work done. A "thin" virtual desktop client, by comparison, is completely dependent on having a network connection to it's host server to operate. Without that connectivity, it's a doorstop (and a light-weight one at that, so it doesn't even do very good at blocking a door open). And in a world of corporate firewalls and filters there may not be any connectivity that the VDI client can use. Anything other than HTTP/HTTPS may be blocked completely, and HTTP/HTTPS traffic will usually be forced through a proxy server that, even if it allows the kind of streaming connection a VDI client needs, introduces so much delay that the desktop becomes useless. And that's when the network's working correctly. Add in random network outages and traffic congestion at the wrong times and corporate systems that require non-corporate machines to VPN to the corporate network (and to have specific anti-virus and management software installed before the VPN's allowed to connect) and it makes a VDI client distinctly unreliable and hard to deal with. Meanwhile, the guy with the "fat" notebook may have more system management headaches and software synchronization issues than the VDI system, but he's still getting his work done while the VDI guy's sitting twiddling his thumbs while the techs try to sort out all the problems.
Because the higher-level zone reports it as secured. So if I DNSSEC-secure silverglass.org, then when someone goes to look up a host they first go to the.org servers and get the silverglass.org delegation information which includes the public key record used to verify the silverglass.org records. The.org servers in turn have their records secured, and you get the public key for them from the root DNS servers. The root zone in turn is secured, and it's public key is pre-loaded into the DNS server's software. So if someone tried to hijack the silverglass.org domain and return unsigned records, they'd first have to hijack the.org domain so they could remove the public key record from the delegation information there. That in turn would require hijacking the root DNS servers themselves to remove.org's public key information. And that would require breaking into the target DNS servers to remove the root DNSSEC key from their configuration. Of course if you've done that last you could just disable DNSSEC entirely. But now you're talking attacking every single network on the entire Internet, or at least every network whose users you want to target with your DNS hijacking, which is a whole lot of work.
One thing here is that applications, and even end-user computers, don't need to support DNSSEC directly. It's good if they do, and once they do they can do some interesting things with it, but in practice most end-user computers don't do full DNS anyway. They've got a stub resolver that hands the real work off to the DNS servers on the network they're on, and those handle the heavy lifting. If those DNS servers implement DNSSEC and check records properly, all the computers on the network get the basic benefit of non-forgeable DNS records (if the signatures don't verify, the local DNS servers will return an error to the client).
Even getting it into the home isn't too hard. Most ISPs use DHCP to assign addresses to customers and point customers to the ISP's DNS servers in the process, so if the ISP's DNS servers implement DNSSEC the customers get the benefit. And for users with their own router, all it takes is DNSSEC in the router's firmware to move the verification all the way to the edge of the home LAN. That's not hard, my Netgear router uses a custom Linux system in the firmware and it's not too hard to tweak the DNS software on it. If I can do it, the router manufacturer can surely do it too and make the new firmware available just like they do for any firmware upgrade. The only real issue is hardware horsepower to do the calculations to verify the signatures. Some consumer routers don't have enough.
It's not just spammers. A lot of on-line games, for instance, record the IP address used to log in to a game in the account's history. Customer Support then uses that to help determine eg. whether a claim of a hacked account is valid or bogus. Large-scale NAT is going to mess with that by confusing the record: one computer may appear to be using a different IP address for each login, and multiple unrelated computers can appear to have the same IP address. And with a lot of games moving towards RMT, a hacked account can mean the loss of real money for the player. When CS tells that player "Sorry, the login where the items were sold/transferred came from one of the IP addresses you normally log in from, the problem's on your end." and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.
How about we just have an HTTP header that, if present in the request, states exactly which tracking the user consents to? No ambiguity, easy to implement on both the browser and the server side. End of problem. At least for users, and since it's our data I don't see where any other party should be getting a say in how it's used.
That's because PCs last longer than smartphones, tablets and the like, and people own more of those devices than PCs. The people I know keep PCs for 5-6 years, yet they're replacing their smartphone every 18 months when their carrier offers an upgrade and may replace it more often if it gets broken. And if they have a tablet it's in addition to their smartphone, not in place of it. And then there's their company-issued phone, which is usually in addition to their personal one. Work PCs follow a similar 5-year replacement cycle, but company-issued cel phones tend to follow the 18-month replacement cycle of the carrier's upgrade offers (assuming they aren't broken and require replacement sooner). And tablets will undoubtedly be in addition to cel phones, or used on the job by people who wouldn't normally be issued a cel phone or have their own work PC (think inventory clerk or delivery driver, they may get a tablet in place of the dedicated hand-held terminal device they use now).
So yeah, given the above, I can see how one PC can equal 2-4 mobile devices. But no mobile device will be able to replace the always-on tower system with the 125W quad-core CPU, 2-terabyte RAID array, 26" or larger high-definition flat-screen monitor and full-sized ergonomic keyboard and mouse. I'll use the smartphone or tablet in situations I can't or don't want to mess with the desktop, but I can't see them ever making the desktop unnecessary.
When I hear that, I recall a comment about the misconceptions about racing: "Winning the Indianapolis 500 is easy. All you do is stand on the gas and turn left.". 'nuff said.
Except that same Congress included this in USC Title 17 section 1201(c)(1): "Other Rights, Etc., Not Affected. -- (1) Nothing in this section shall affect rights, remedies, limitations, or defenses to copyright infringement, including fair use, under this title.". So if I have a right to do something under copyright law, the copyright holder can't change that merely by applying a restrictive measure and claiming section 1201 means I can't do what I've a right to do.
True, but that's by the seller's choice. And the access isn't needed for operation of the software, it only restricts access to the software I've bought. It's the equivalent of the lock on the shipping crate: unlocking it's not needed to use the goods, it only restricts access to them. Compare this to an on-line game, where access to the servers is required as a normal part of operation (without it the game'd be a standard off-line single-player game).
Pretty much. I liken it to this: I go and buy an air conditioner. The store charges my credit card, the charges are paid, the store delivers the air conditioner to my doorstep. But they deliver it in a locked steel crate, and refuse to give me the key until I pay an access fee and agree that I didn't buy the air conditioner, I'm only leasing it and they can terminate the lease and take back the air conditioner at any time. Oh, and if they take it back they won't refund what I paid for it. Under the law, am I out of luck? Or can I call a locksmith to open the crate, take my air conditioner out and tell the store I'm available whenever they want to arrange for the return of their crate? Every business law class I've taken, and every lawyer I've talked to, all agree it's the second. So why is software, which is governed by the same law, different?
Yep. Typically in that case either the two ISPs would connect to each other at a peering point, each one paying their own freight to join the interconnect, or they'd connect to backbone providers and let the backbone providers carry the transit traffic.
But Comcast doesn't want to do either. With a standard peering point Comcast would be paying for their own connection to the interconnect, although they wouldn't be paying for data exchanged within the interconnect. Connecting to another backbone provider, Comcast would be paying that provider for the large volume of transit traffic across the backbone terminating within Comcast's network. Comcast doesn't like this. But that's just being greedy. If I keep coming to your store every day to buy groceries, what would be your immediate response if I demanded that you pay me for the privilege of having access to my shopping bags? You'd probably laugh in my face and point out that it's me wanting access to your groceries, not the other way around. The same thing here: it's Comcast's customers that're requesting the traffic, let Comcast bill them for the bandwidth they're using. Oh wait, Comcast already is. Comcast just doesn't like how much it's billing, but it doesn't want to increase the bill. Life is tough, Comcast, deal.
Metered billing won't take off because of two things. First, people like security. They like to know the upper limit on their bill, know that it won't go above that (or at least won't without them being told and given a chance to veto whatever would cause it). Second, people know that they aren't in control of how much they download. They know that when they visit a Web page they don't know in advance whether it'll be 10K of text or 50 megabytes of graphics and sounds and advertising and Flash animations. And they're not going to want to pay per byte without having any say in how many bytes it'll be. If ISPs go the pay-per-byte route, expect a consumer backlash of "OK, but we're not paying for all the advertising and other stuff we didn't ask for. If the Web site wants to send it, bill them.".
All in all, I expect that if one major ISP goes to metered billing, they're going to see a mass migration to other ISPs serving the same area and a drastic reduction in usage by the remaining subscribers leading to a massive decrease in revenues and a lot of unhappy shareholders.
What does the UCC say that rules out notices on product packages that include the EULA by reference?
Well, UCC Article 2 section 401 says this: "Unless otherwise explicitly agreed title passes to the buyer at the time and place at which the seller completes his performance with reference to the physical delivery of the goods, despite any reservation of a security interest and even though a document of title is to be delivered at a different time or place". Note the use of the term "explicit" there. According to the lawyers I've spoken to, "explicit" there has a legal meaning that bars assumed or implicit agreement. A notice like you mention would be an implicit agreement, attempting to impose one without explicit acceptance by the buyer. The word "explicit" in section 401 was chosen specifically to prohibit exactly the kind of thing in your example. And that's not even getting to the question of how the seller would prove there was an agreement if the buyer says "No, I rejected that standard form contract.". After all, the buyer's got possession of the product and he's got a receipt showing the seller accepted his payment for it, and if he says the seller completed the sale without the agreement what evidence does the seller have to the contrary?
The bnetd case differs in that acceptance of the terms is explicit and is required not for the purchase of the software but to gain access to Blizzard's servers. The defendant there did in fact access Blizzard's servers, so Blizzard has some legal footing to claim that the terms do apply to him. We're talking here, though, about a situation where I don't need and in fact don't want to access the seller's equipment or services after the sale.
Except you're missing one thing here: the traffic isn't crossing Comcast's network on it's way to some other network, it's on it's way to Comcast subscribers and was requested by those subscribers. Backbone providers carry other people's traffic (eg. carrier X handling traffic originating on network A and destined for network B because A and B both have connections to X but don't have a direct connection with each other). Comcast doesn't connect other networks to the backbone, it only connects it's own subscribers. If those subscribers are incurring bandwidth costs, Comcast ought to be billing them for it. In fact it is, I'm fairly sure Comcast sends every subscriber a bill every month for their connection and turns that connection off if the bill isn't paid. If Comcast wants Level 3 to pay, then what's that bill to the subscribers for?
Yep, but when trying to claim you don't have a right to make the copies of software onto your hard drive and into memory to run, the copyright holders run afoul of USC Title 17 section 117(a) which says that, since those copies are essential steps in the utilization of said program, making them is not an infringement of copyright. And that one's held up in court. You have to actually own the copy, which is why the rightsholders try so hard to claim that you agreed it wasn't a sale, but I've always held that UCC Article 2 says it was a sale if they can't show an explicit agreement otherwise made before payment was accepted and the goods delivered. And that what I bought was not merely the physical media, because every bit of description on the box and every bit of advertising for the goods describes only the software on the disc, not the box or the disc. The seller's selling what the seller claims to be selling, no more and no less, and they can't handwave away all those claims they made before just because they're inconvenient now.
This is why the policy on my network is "No automatic updates.". Software can tell me there's an update available, but all downloading and installation of updates is operator-initiated. That way I can control when updates are installed and can delay installation until I've seen whether they cause problems or not. Any software that can't follow my rule gets uninstalled (forcibly if neccesary).
It annoys the IT guys at my workplace because they want my home machines (that I use to VPN in to work) to take updates from them automatically, but they can't argue too loudly because my policy is virtually word-for-word identical to their policy for company machines. And they really don't like me pointing out that when it comes to virus infections, I've got a better track record on my machines than they do on theirs.
One hopes the guys at Google took into account the business that sets up a fake review site for the purpose of posting negative reviews of competitors to get Google to falsely downgrade them. My bet's on a manual filter to remove such sites, probably based on a discrepancy between those sites and every other review site.
Well, for e-mail almost all ISPs block outbound port 25 except to their mail servers and scan outgoing e-mail for spam the same way they scan incoming, so for e-mail it ought to be fairly trivial to spot the problem. For other stuff, do what my ISP does and routinely scan their network for the open ports and tell-tale traffic signatures of known malware. I've actually gotten calls from the security people at my ISP when they went to scan my IP address and "my router" suddenly stop responding completely (their scan triggered an alert and my firewall started dropping all packets from the IP address they were scanning from). It's not that hard to catch most of the malware through relatively simple methods, without resorting to nastiness like deep packet inspection. It's just that most ISP's don't bother doing even that.
And frankly you don't have a right to have your computer be a platform for attacking mine. If you want to go that route, my response'd probably be to get a court order barring you from ever having Internet connectivity again, same way we revoke the driving privileges of people who keep driving recklessly and injuring other people on the roads, or same way we forcibly commit (either to psychiatric care or to prison) people who can't control themselves and keep physically attacking and injuring/killing other people. To quote, "Your right to swing your fist ends at the tip of my nose.". Similarly your right to unfettered Internet access ends at the WAN port on my router.
That's why the warning first: so the user knows there's a problem and can go download updates, get anti-virus software and generally clean things up before getting disconnected. If they don't react, I say disconnect them completely (their modem goes dark, they get no IP connectivity whatsoever, not even to the ISP's Web servers) until they call customer service. Once they've called, had the situation explained and promised to clean things up, CS can reconnect them so they can clean things up. If the problem still persists after a reasonable interval, they get disconnected again until they call CS. Second time around they have to show evidence they've had a professional clean their computer before they get reconnected (if the professional comes out to the home, they can call CS and get the computer reconnected during the clean-up). Third time, a professional of the ISP's choosing comes out (at the customer's expense) to clean up the mess. If you can stay clean for 1 year, the clock resets and your record's cleared.
Slashdot Mirror
IIRC the problem isn't with computers that don't support IPv6. It's with networks where the computers and DNS software does support IPv6 but there's no IPv6 connectivity. In those cases a name query gets back AAAA records, the computer tries to connect via IPv6, and the connection doesn't go through because IPv6 traffic doesn't have a route off the local network. If your computers don't support IPv6 at all, the problem doesn't happen (the AAAA records never get used). If the DNS software (probably in your router) doesn't support IPv6, it won't do queries for AAAA records in the first place. Note also that at the other end (the DNS servers for the web site's domain) there should also be filtering in place: AAAA records shouldn't be being returned in queries that came in via IPv4. But not all sites do that filtering, so clients have to be prepared to get IPv6-only data back in IPv4 responses and filter it out.
Which is odd, because where I work it's my personal computers that have never had a single bit of malware detected on them in 25 years and the company computers (never mine, because I run it like my personal computer as much as possible) which are constantly needing to be scrubbed of malware that got past the corporate security and anti-virus software.
Virtually no human testing? Given the kind of person who gets into the astronaut corps, I seriously doubt that. There's probably been no official investigation into this done, but when you coop seven mixed-gender, highly intelligent, very curious, extremely goal-driven, competitive problem-solvers up in a small ship for the lengths of time a shuttle mission runs, I think we can pretty much guarantee there's been plenty of unofficial investigations conducted. And there's been IIRC several mixed-gender ISS crews, so ditto there.
I also suspect they've found the entire exercise to be awkward, exhausting (and not in the good way), inconvenient to arrange around all the monitoring that's done, difficult to keep private in those cramped quarters, and generally an awful lot of work for a lot less reward than you'd expect. But if anybody wants to go to Mars they're going to have to figure out how to deal with sex and how to make it reasonably convenient, because no crew's going to remain completely celibate that long.
The story mentioned how you never see the VDI guys actually using VDI when they show up at a customer's site, they're always using traditional "fat" laptops. That's because their customer reps and engineers are on the customer's network and have to deal with all of it's firewalls, VPNs, filtering and other controls that aren't set up for VDI. And there's a whole lot of mobile stuff where you have to deal with the reality of living on someone else's network where you can't just change the configuration as needed.
Pretty much. I divide users into 4 categories:
The higher the level you're at, the less useful thin clients tend to be. OTOH, at level 1 thin clients can be really useful if you've got control over the networks involved and can configure it so things work smoothly. Just don't try forcing someone at level 3 into an environment intended for level 1 (or vice-versa). It won't work, and you'll spend more time patching things up and finding workarounds for problems than you'll ever see in purported savings.
The problem is that it isn't your deployment where the problems lie. It's in everyone else's networks where they aren't deploying your VDI solution exactly the way you did, and so the networks aren't set up to make it "just work". If it's internal... well, you can manage desktops relatively easily using the same tools you use to manage the servers (or you should be able to at any rate, in the kinds of networks I'm used to the only difference between a desktop and a server is the video card and what software packages are installed). The only advantage VDI gives you is being able to host multiple desktops on a single box, but that becomes rather pointless when you don't need any special support to simply log in to a larger server the same way you'd log in to your desktop (XDMCP, it's not rocket science). And you don't even need to do anything special to keep users from installing or storing stuff locally, just don't give them a local login on the box on their desktop.
Virtualization has a lot of uses, but VDI seems to me to be an attempt to patch over all the problems created trying to graft network transparency onto a GUI/desktop system after having declared that you don't need network transparency in the GUI/desktop system. I look at it and go "But... we were doing this 20 years ago! What's making it so hard to do it today, and why are you tolerating it?".
Then again, I laugh at current Web developers struggling to implement the 3270 workstation (badly) and wonder when they're going to move to the VT100 like their predecessors did and for exactly the same reasons.
It's all a matter of connectivity. If you're using a traditional "fat" desktop (or notebook), you're self-contained. All your software's there, you aren't dependent on any connectivity to the outside world to get your work done. A "thin" virtual desktop client, by comparison, is completely dependent on having a network connection to it's host server to operate. Without that connectivity, it's a doorstop (and a light-weight one at that, so it doesn't even do very good at blocking a door open). And in a world of corporate firewalls and filters there may not be any connectivity that the VDI client can use. Anything other than HTTP/HTTPS may be blocked completely, and HTTP/HTTPS traffic will usually be forced through a proxy server that, even if it allows the kind of streaming connection a VDI client needs, introduces so much delay that the desktop becomes useless. And that's when the network's working correctly. Add in random network outages and traffic congestion at the wrong times and corporate systems that require non-corporate machines to VPN to the corporate network (and to have specific anti-virus and management software installed before the VPN's allowed to connect) and it makes a VDI client distinctly unreliable and hard to deal with. Meanwhile, the guy with the "fat" notebook may have more system management headaches and software synchronization issues than the VDI system, but he's still getting his work done while the VDI guy's sitting twiddling his thumbs while the techs try to sort out all the problems.
Because the higher-level zone reports it as secured. So if I DNSSEC-secure silverglass.org, then when someone goes to look up a host they first go to the .org servers and get the silverglass.org delegation information which includes the public key record used to verify the silverglass.org records. The .org servers in turn have their records secured, and you get the public key for them from the root DNS servers. The root zone in turn is secured, and it's public key is pre-loaded into the DNS server's software. So if someone tried to hijack the silverglass.org domain and return unsigned records, they'd first have to hijack the .org domain so they could remove the public key record from the delegation information there. That in turn would require hijacking the root DNS servers themselves to remove .org's public key information. And that would require breaking into the target DNS servers to remove the root DNSSEC key from their configuration. Of course if you've done that last you could just disable DNSSEC entirely. But now you're talking attacking every single network on the entire Internet, or at least every network whose users you want to target with your DNS hijacking, which is a whole lot of work.
One thing here is that applications, and even end-user computers, don't need to support DNSSEC directly. It's good if they do, and once they do they can do some interesting things with it, but in practice most end-user computers don't do full DNS anyway. They've got a stub resolver that hands the real work off to the DNS servers on the network they're on, and those handle the heavy lifting. If those DNS servers implement DNSSEC and check records properly, all the computers on the network get the basic benefit of non-forgeable DNS records (if the signatures don't verify, the local DNS servers will return an error to the client).
Even getting it into the home isn't too hard. Most ISPs use DHCP to assign addresses to customers and point customers to the ISP's DNS servers in the process, so if the ISP's DNS servers implement DNSSEC the customers get the benefit. And for users with their own router, all it takes is DNSSEC in the router's firmware to move the verification all the way to the edge of the home LAN. That's not hard, my Netgear router uses a custom Linux system in the firmware and it's not too hard to tweak the DNS software on it. If I can do it, the router manufacturer can surely do it too and make the new firmware available just like they do for any firmware upgrade. The only real issue is hardware horsepower to do the calculations to verify the signatures. Some consumer routers don't have enough.
It's not just spammers. A lot of on-line games, for instance, record the IP address used to log in to a game in the account's history. Customer Support then uses that to help determine eg. whether a claim of a hacked account is valid or bogus. Large-scale NAT is going to mess with that by confusing the record: one computer may appear to be using a different IP address for each login, and multiple unrelated computers can appear to have the same IP address. And with a lot of games moving towards RMT, a hacked account can mean the loss of real money for the player. When CS tells that player "Sorry, the login where the items were sold/transferred came from one of the IP addresses you normally log in from, the problem's on your end." and the player learns that that's because his ISP is NATing their entire network, he's not going to be happy.
How about we just have an HTTP header that, if present in the request, states exactly which tracking the user consents to? No ambiguity, easy to implement on both the browser and the server side. End of problem. At least for users, and since it's our data I don't see where any other party should be getting a say in how it's used.
That's because PCs last longer than smartphones, tablets and the like, and people own more of those devices than PCs. The people I know keep PCs for 5-6 years, yet they're replacing their smartphone every 18 months when their carrier offers an upgrade and may replace it more often if it gets broken. And if they have a tablet it's in addition to their smartphone, not in place of it. And then there's their company-issued phone, which is usually in addition to their personal one. Work PCs follow a similar 5-year replacement cycle, but company-issued cel phones tend to follow the 18-month replacement cycle of the carrier's upgrade offers (assuming they aren't broken and require replacement sooner). And tablets will undoubtedly be in addition to cel phones, or used on the job by people who wouldn't normally be issued a cel phone or have their own work PC (think inventory clerk or delivery driver, they may get a tablet in place of the dedicated hand-held terminal device they use now).
So yeah, given the above, I can see how one PC can equal 2-4 mobile devices. But no mobile device will be able to replace the always-on tower system with the 125W quad-core CPU, 2-terabyte RAID array, 26" or larger high-definition flat-screen monitor and full-sized ergonomic keyboard and mouse. I'll use the smartphone or tablet in situations I can't or don't want to mess with the desktop, but I can't see them ever making the desktop unnecessary.
When I hear that, I recall a comment about the misconceptions about racing: "Winning the Indianapolis 500 is easy. All you do is stand on the gas and turn left.". 'nuff said.
Except that same Congress included this in USC Title 17 section 1201(c)(1): "Other Rights, Etc., Not Affected. -- (1) Nothing in this section shall affect rights, remedies, limitations, or defenses to copyright infringement, including fair use, under this title.". So if I have a right to do something under copyright law, the copyright holder can't change that merely by applying a restrictive measure and claiming section 1201 means I can't do what I've a right to do.
True, but that's by the seller's choice. And the access isn't needed for operation of the software, it only restricts access to the software I've bought. It's the equivalent of the lock on the shipping crate: unlocking it's not needed to use the goods, it only restricts access to them. Compare this to an on-line game, where access to the servers is required as a normal part of operation (without it the game'd be a standard off-line single-player game).
Pretty much. I liken it to this: I go and buy an air conditioner. The store charges my credit card, the charges are paid, the store delivers the air conditioner to my doorstep. But they deliver it in a locked steel crate, and refuse to give me the key until I pay an access fee and agree that I didn't buy the air conditioner, I'm only leasing it and they can terminate the lease and take back the air conditioner at any time. Oh, and if they take it back they won't refund what I paid for it. Under the law, am I out of luck? Or can I call a locksmith to open the crate, take my air conditioner out and tell the store I'm available whenever they want to arrange for the return of their crate? Every business law class I've taken, and every lawyer I've talked to, all agree it's the second. So why is software, which is governed by the same law, different?
Yep. Typically in that case either the two ISPs would connect to each other at a peering point, each one paying their own freight to join the interconnect, or they'd connect to backbone providers and let the backbone providers carry the transit traffic.
But Comcast doesn't want to do either. With a standard peering point Comcast would be paying for their own connection to the interconnect, although they wouldn't be paying for data exchanged within the interconnect. Connecting to another backbone provider, Comcast would be paying that provider for the large volume of transit traffic across the backbone terminating within Comcast's network. Comcast doesn't like this. But that's just being greedy. If I keep coming to your store every day to buy groceries, what would be your immediate response if I demanded that you pay me for the privilege of having access to my shopping bags? You'd probably laugh in my face and point out that it's me wanting access to your groceries, not the other way around. The same thing here: it's Comcast's customers that're requesting the traffic, let Comcast bill them for the bandwidth they're using. Oh wait, Comcast already is. Comcast just doesn't like how much it's billing, but it doesn't want to increase the bill. Life is tough, Comcast, deal.
Metered billing won't take off because of two things. First, people like security. They like to know the upper limit on their bill, know that it won't go above that (or at least won't without them being told and given a chance to veto whatever would cause it). Second, people know that they aren't in control of how much they download. They know that when they visit a Web page they don't know in advance whether it'll be 10K of text or 50 megabytes of graphics and sounds and advertising and Flash animations. And they're not going to want to pay per byte without having any say in how many bytes it'll be. If ISPs go the pay-per-byte route, expect a consumer backlash of "OK, but we're not paying for all the advertising and other stuff we didn't ask for. If the Web site wants to send it, bill them.".
All in all, I expect that if one major ISP goes to metered billing, they're going to see a mass migration to other ISPs serving the same area and a drastic reduction in usage by the remaining subscribers leading to a massive decrease in revenues and a lot of unhappy shareholders.
What does the UCC say that rules out notices on product packages that include the EULA by reference?
Well, UCC Article 2 section 401 says this: "Unless otherwise explicitly agreed title passes to the buyer at the time and place at which the seller completes his performance with reference to the physical delivery of the goods, despite any reservation of a security interest and even though a document of title is to be delivered at a different time or place". Note the use of the term "explicit" there. According to the lawyers I've spoken to, "explicit" there has a legal meaning that bars assumed or implicit agreement. A notice like you mention would be an implicit agreement, attempting to impose one without explicit acceptance by the buyer. The word "explicit" in section 401 was chosen specifically to prohibit exactly the kind of thing in your example. And that's not even getting to the question of how the seller would prove there was an agreement if the buyer says "No, I rejected that standard form contract.". After all, the buyer's got possession of the product and he's got a receipt showing the seller accepted his payment for it, and if he says the seller completed the sale without the agreement what evidence does the seller have to the contrary?
The bnetd case differs in that acceptance of the terms is explicit and is required not for the purchase of the software but to gain access to Blizzard's servers. The defendant there did in fact access Blizzard's servers, so Blizzard has some legal footing to claim that the terms do apply to him. We're talking here, though, about a situation where I don't need and in fact don't want to access the seller's equipment or services after the sale.
Except you're missing one thing here: the traffic isn't crossing Comcast's network on it's way to some other network, it's on it's way to Comcast subscribers and was requested by those subscribers. Backbone providers carry other people's traffic (eg. carrier X handling traffic originating on network A and destined for network B because A and B both have connections to X but don't have a direct connection with each other). Comcast doesn't connect other networks to the backbone, it only connects it's own subscribers. If those subscribers are incurring bandwidth costs, Comcast ought to be billing them for it. In fact it is, I'm fairly sure Comcast sends every subscriber a bill every month for their connection and turns that connection off if the bill isn't paid. If Comcast wants Level 3 to pay, then what's that bill to the subscribers for?
Yep, but when trying to claim you don't have a right to make the copies of software onto your hard drive and into memory to run, the copyright holders run afoul of USC Title 17 section 117(a) which says that, since those copies are essential steps in the utilization of said program, making them is not an infringement of copyright. And that one's held up in court. You have to actually own the copy, which is why the rightsholders try so hard to claim that you agreed it wasn't a sale, but I've always held that UCC Article 2 says it was a sale if they can't show an explicit agreement otherwise made before payment was accepted and the goods delivered. And that what I bought was not merely the physical media, because every bit of description on the box and every bit of advertising for the goods describes only the software on the disc, not the box or the disc. The seller's selling what the seller claims to be selling, no more and no less, and they can't handwave away all those claims they made before just because they're inconvenient now.
This is why the policy on my network is "No automatic updates.". Software can tell me there's an update available, but all downloading and installation of updates is operator-initiated. That way I can control when updates are installed and can delay installation until I've seen whether they cause problems or not. Any software that can't follow my rule gets uninstalled (forcibly if neccesary).
It annoys the IT guys at my workplace because they want my home machines (that I use to VPN in to work) to take updates from them automatically, but they can't argue too loudly because my policy is virtually word-for-word identical to their policy for company machines. And they really don't like me pointing out that when it comes to virus infections, I've got a better track record on my machines than they do on theirs.
One hopes the guys at Google took into account the business that sets up a fake review site for the purpose of posting negative reviews of competitors to get Google to falsely downgrade them. My bet's on a manual filter to remove such sites, probably based on a discrepancy between those sites and every other review site.
Well, for e-mail almost all ISPs block outbound port 25 except to their mail servers and scan outgoing e-mail for spam the same way they scan incoming, so for e-mail it ought to be fairly trivial to spot the problem. For other stuff, do what my ISP does and routinely scan their network for the open ports and tell-tale traffic signatures of known malware. I've actually gotten calls from the security people at my ISP when they went to scan my IP address and "my router" suddenly stop responding completely (their scan triggered an alert and my firewall started dropping all packets from the IP address they were scanning from). It's not that hard to catch most of the malware through relatively simple methods, without resorting to nastiness like deep packet inspection. It's just that most ISP's don't bother doing even that.
And frankly you don't have a right to have your computer be a platform for attacking mine. If you want to go that route, my response'd probably be to get a court order barring you from ever having Internet connectivity again, same way we revoke the driving privileges of people who keep driving recklessly and injuring other people on the roads, or same way we forcibly commit (either to psychiatric care or to prison) people who can't control themselves and keep physically attacking and injuring/killing other people. To quote, "Your right to swing your fist ends at the tip of my nose.". Similarly your right to unfettered Internet access ends at the WAN port on my router.
That's why the warning first: so the user knows there's a problem and can go download updates, get anti-virus software and generally clean things up before getting disconnected. If they don't react, I say disconnect them completely (their modem goes dark, they get no IP connectivity whatsoever, not even to the ISP's Web servers) until they call customer service. Once they've called, had the situation explained and promised to clean things up, CS can reconnect them so they can clean things up. If the problem still persists after a reasonable interval, they get disconnected again until they call CS. Second time around they have to show evidence they've had a professional clean their computer before they get reconnected (if the professional comes out to the home, they can call CS and get the computer reconnected during the clean-up). Third time, a professional of the ISP's choosing comes out (at the customer's expense) to clean up the mess. If you can stay clean for 1 year, the clock resets and your record's cleared.