The biggest problem here isn't the question of software patents. It's patents on things that are obvious, or are an obvious progression from something that's already common (eg. taking the manual process of balancing a checkbook and having a computer perform the exact same steps). It's just that software is the field where it's taken root the most, I think because people treat computers as some sort of magic that transforms the ordinary into something extraordinary.
The most straightforward way to deal with it might be to take computers out of the picture. Start by asking the question "If we replaced the computer with a trained monkey who could slavishly follow instructions, would this be patentable?". If the answer is "Yes.", then the patent's valid. If the answer's "No.", then the burden should be on the patent-holder to explain why the application of a computer to this problem is so non-intuitive, so non-obvious, that someone familiar with the problem and computers would not think of letting a computer handle the chore. And "Because nobody's done it before." is not a valid response. Someone always has to be the first one to try to solve a problem. Counter-intuitively, the patent-holder should have to show that they were not the first, that doing this was so non-obvious that there's a large number of other people who knew what they were doing who tried this and could not figure it out. That the first person to try it immediately found this solution should be considered support for the idea that this was an obvious solution and thus not eligible for patent. That is, after all, almost the dictionary definition of "obvious": the first thing you think to try when faced with a problem?
1. All government services must be accessible at no cost via a method which is guaranteed to be available to any person. IOW if landline phone service isn't required to be universal then all government offices must have in-person hours and be staffed at a level sufficient to get everyone who shows up on any given day served before the office closes, or all services must be available via mail (postage pre-paid). Online-only services are not allowed, since the government isn't guaranteeing that everyone will receive Internet access. Phone-only services are not allowed since the government isn't guaranteeing everyone will receive cel phone service. Online-only or phone-only would only be allowed if the government mandated that everyone would be able to receive either Internet access or cel-phone service regardless of location. Which the service providers won't go for, since their whole goal is to avoid being legally required to provide service in unprofitable areas.
2. Any person must be able to get basic (local calling and 911 service) phone service at any address, regardless of where that address is, upon request at no more than the previous cost of equivalent landline service. Whether it be via cel or VOIP, the service must be available. Note that this doesn't completely get around requirement #1, since the basic service isn't guaranteed to provide access to government numbers. To the extent that it does, it would satisfy #1.
Except that, as these companies make abundantly clear when you're hired, you are not in an employment contract. You are an at-will employee who can leave at any time and who can be terminated at any time for any or no reason. Companies like that because it lets them just fire people whenever they want, and these agreements are simply to let the company have all the advantages of having at-will employees without having to suffer any of the consequences of having at-will employees.
Necessary to keep teams together? I don't think so. How about, maybe, paying well enough that people people aren't tempted to jump ship in the middle of a project? Or putting people under contract instead of having them be at-will employees? Sure you can't just fire them any time you want (unless you've got good cause, like failure to do their jobs), but you don't have to worry about losing them at any time either.
These hiring collusions aren't necessary to keep employees. They're only necessary to keep employees without the company doing anything to actually keep employees.
I do know that even as a non-disabled user, the behavior Peter describes as "per spec" (that is, mouse buttons are not keys for the purposes of releasing the sticky keys) is counter-intuitive since the modifier keys interact with mouse buttons the same way they do with non-modifier keys (ie. Control modifies selection with mouse clicks the same way it modifies selection with the keyboard). Given that normal interaction with both non-modifier keys and mouse buttons, I'd expect instructions about how modifier keys behave to also apply analogously when both non-modifier keys and mouse buttons (but not mouse movements) are involved. Either that or I would expect modifier keys to not interact with mouse clicks the same way they do with regular keys.
If the password was set by the system, either during a password reset or initial account creation, the first thing I do is change the password to a random one my password manager program's generated. Why were these accounts still using the system-created password? Also, the article seems to conflate two uses of the term "salt": the random nonce used to insure the stored hash value isn't the same for two different accounts that picked the same password, and the random string used in the plaintext of the initial password to avoid a trivially-guessable "password same as username"-type case. The two aren't at all the same.
The answer to why Netflix keeps DVDs around should be obvious if you take more than 10 seconds to think: Netflix wants to offer as many movies as they can to be as attractive to customers as possible, and the studios won't license most recent releases for streaming. As a second reason, there's probably customer demand: a significant number of customers may have bandwidth caps low enough, or connections slow/laggy enough, that streaming high-quality video isn't feasible.
Making the IMEI physically unalterable doesn't help. If you can re-flash the baseband and firmware, you can make it ignore the burned-in IMEI in favor of a programmable one stored in the phone's non-volatile memory.
Making a jammer, yes, but buying radio hardware isn't quite that simple. For anything operating in unlicensed or open-access spectrum (eg. CB radio), it's easy to buy hardware that won't exceed the allowable limitations. Buying gear that can transmit on any channel and/or at any power usually requires having your license recorded as part of the sale. No license = no gear.
As for the IMEI, as far as I know it's not used to authenticate to the cel network. That's done via the IMSI which is on the SIM. The IMEI's mostly used for locating hardware (eg. a lost/stolen phone). Authentication is done using a challenge/response system, and the key used to generate the response from the challenge is in secure storage in the SIM (can't be read short of direct physical access to the internals of the SIM). Unlike other systems, GSM treats the phone as just an interchangeable accessory, the subscriber identity and everything critical to network authentication is carried in the SIM. That's why I can pop the SIM out of one phone and pop it in another (or pop another carrier's SIM in my phone, if the phone isn't locked) and things Just Work.
Most of it's probably regulatory issues. Anything that transmits radio has to be set up so it can't go outside the FCC-set limits (eg. stays within maximum allowable power for a given channel, stays only on assigned channels, etc. etc.). That used to be handled in hardware, but these days it's cheaper to use generic hardware that'll transmit at any power on any channel and then impose the limitations within the baseband code. And it's cheaper to allow updating of the baseband than it is to replace phones to fix problems in the baseband code. That combination means that open-source baseband would allow you to re-flash a baseband that'd go outside regulatory limits, which'd be a no-no. Combine with a legal environment where the phone manufacturer, not the consumer, would be the one sued (because they've got deep pockets and the consumers don't) and you can see why we have the situation we have.
For A above, I don't think it's relevant. If AT&T thinks it's a better deal for them to unevenly distribute bandwidth, it's them that's paying for the traffic so I don't see any reason to second-guess them. As for B, if AT&T thinks the imbalance is a problem then AT&T should pay for the changes to their network. If their customers are simply requesting too much data, then AT&T needs to discuss rates with their customers. AT&T doesn't want to do that because they're scared if they raise rates they'll lose customers, but my thought is that if it's really that unprofitable to offer service at those rates then driving those customers to your competition is probably a good thing. Better it be your competitors selling $100 worth of service for $30 than you. That AT&T is afraid of driving customers away should be the big hint that they aren't losing money on the deal.
As an ISP customer I don't take flat rates for the cost savings. At eg. the rates Amazon charges for data transfer (and I'm assuming Amazon isn't losing money at those rates), I'd be getting off cheaper paying per gigabyte for bandwidth. I take flat rates to get a predictable, stable bill every month without having to worry that something weird will throw the bill out of kilter without warning.
CDNs aren't complicated, they're just another Web site. Netflix hosts it's content on a CDN. Users request data from the CDN, the CDN serves it up, just like any other Web site. The CDN pays for it's connection through it's service providers. It's between Netflix and the CDN how Netflix pays the CDN for hosting it's files and the bandwidth the CDN had to pay for for that hosting. And the CDN may offer AT&T a deal: let the CDN install servers at AT&T's interconnect points and the CDN will handle the transit traffic from Netflix so AT&T doesn't have to worry about either building it's own transit network or paying someone else for transit. But that's an offer AT&T has to evaluate, deciding whether the CDN's terms and prices are a better deal than either of the alternatives.
I already do the same for my own personal Web site. I don't host it myself, I host it on Linode. Linode pays it's providers for bandwidth, AT&T customers request data from Linode instead of directly from me just as if it were Linode's web site, and AT&T doesn't know or care how me and Linode handle settling up for the costs Linode incurred. Linode's my CDN, but that makes no difference to AT&T and shouldn't.
This is what peering agreements handle, and they're already in place. Netflix pays it's Internet provider. That provider in turn has an agreement with AT&T wherein they pay each other for handling each other's traffic. The problem is that AT&T's mostly an end-user network, primarily clients who receive data with very few servers who send data. That means that at the peering point it's primarily the providers AT&T peers with who handle traffic for AT&T's network, with very little traffic bound for those providers handled by AT&T's network.
AT&T simply doesn't like the terms. When an AT&T customer requests data from Netflix, providers like Level 3 handles that traffic as it passes from Netflix to AT&T. AT&T has two choices. It can peer with Level 3 at the same exchange where Netflix connects and handle delivering the traffic across the AT&T network to their customers. This is usually relatively cheap, but it means AT&T has to build a larger backbone network. Alternatively, they can peer at points closer to their customers and let Level 3 handle the cross-country transit. This way AT&T avoids having to build a cross-country network to deliver data, but they don't like having to pay Level 3 for handling the transit traffic. They'd rather have Netflix picking up the bill for it. But why should Netflix have to pay to accommodate AT&T's decisions about how to build their network? This rightly ought to be a matter for AT&T to work out, deciding what the trade-off should be between the cost of buying cross-country transit capacity from someone else vs. building their own cross-country network.
Every month, customers get a bill from AT&T for their Internet service. So, what exactly is that bill for, then, if it's not to pay AT&T for providing Internet service? That does, as I understand it, involve transferring data packets in both directions between my computer and Web sites so I can access the Internet. So, Mr. Cicconi, if what customers are paying you isn't in fact for providing that service, which is what you're saying when you say you're not being paid to let customers access Netflix (which is a Web site), then can you please provide a detailed breakdown of exactly what that bill is for and what service you are providing to your customers for each and every item for which you're billing them. Because if it's not for providing Internet service as advertised, I think every single one of your Internet service customers is entitled to a refund of everything they've paid for a service you haven't been providing them and possibly damages for your false advertising (claiming you're providing them with Internet service when you aren't).
And, Mr. Cicconi, if you claim you are providing your customers with Internet service and that's what that bill's for, please stop whining that you aren't being paid to provide Internet service when by your own admission you are being paid.
So if I store my dollar bills in a jar and it gets destroyed in a fire, I can go to the FDIC and get my money restored by them? No, I can't. That's because the FDIC doesn't insure dollars. It insures deposits (in whatever currency, at it's value in dollars when it was deposited) at institutions that're equivalent to a Bitcoin exchange. As far as gaining/losing value, shall we discuss the bank and financial company bailouts? They were all needed precisely because the banks and financial companies did deal heavily in assets that could and did lose value that quickly and got burned by it. As far as backing, riddle me this: what precisely can you trade a dollar bill in to the US government in exchange for? Nothing but another dollar bill, or a note promising to pay you some number of dollar bills at some point in the future. We haven't had a hard currency in ages, it's all fiat money that's worth exactly what someone else will trade you for it. Just like Bitcoins. If someone won't accept Bitcoins then they're worthless, just like a New Zealand dollar would be in a grocery store here. Technically an NZ dollar's worth some number of US dollars, but if the merchant won't accept it as payment it's a piece of scrap paper for all the good it'll do you. And if someone will sell me a $2000 computer for BTC 4, then a Bitcoin's worth about 500 US dollars.
I'd note that the question of the solvency/stability of a Bitcoin exchange has as much bearing on the viability of Bitcoin as a currency as the question of the solvency/stability of say Bank of America has on the viability of the US dollar as a currency. I can keep Bitcoins in my own wallet on my own computer just like I can keep dollars in my own wallet, use both to pay for things, and never be worried about whether any particular exchange or bank will go belly up. And if I choose an unstable institution to store my currency for me, I run the risk of losing my money whether it be Bitcoins or dollars or yen. The only reason banks don't deal with cryptocurrency is that, unlike most currency, cryptocurrency has a mathematical underpinning that makes it difficult for them to loan it out to other people and make money off it while you aren't actively using it.
The problem here is that the permissions system goes beyond just ordinary user permissions. The system itself uses permissions to control which parts of the system can do what, and those permissions are normally only available to system components (trying to install an app that asks for those permissions results in the app being rejected because it doesn't qualify to get those permissions). For instance, the "Across_users" permission was added to Android 4.2, and allows system components to break through the normal restrictions that separate different users in the system. An app with this permission can reach out and directly affect everything on the phone, not just the things that belong to it. It's restricted to Android system components only. But if I install an app that asks for it on an Android 4.0 device, the app will install without any warnings. If the device is then upgraded to 4.2, the app will silently get the "Across_users" permission activated. So now we have a user-installed app which has a permission that it could never legitimately have that lets it bypass security and the sandbox, and the user will be unaware of the problem. It's very definitely NOT just a UI issue.
In the Unix world it'd be equivalent to finding an other-writable directory sitting in the root user's PATH, and in that directory are executables named "ls", "cat" and so on. It's the kind of thing that'd make a security admin excrete cinder blocks at velocities sufficient to have them achieving high orbit, ceilings nonwithstanding.
That's the thing, though: for the most part the basic programming APIs haven't changed much since then. There's some new ones, but mostly code written for RHEL 2.1 will compile and run on Debian 7.4. The kernel will have been upgraded, the libraries and packages will have been upgraded, but the source code and makefiles and scripts will need minimal changes to make the jump. You won't be able to take advantage of the new features, but you won't be looking at nearly the work to migrate. Even widget sets are mostly backwards-compatible, and for an application like an ATM you can omit the desktop environment stuff that's undergone major changes over the years (why would an ATM need a desktop environment anyway, it's not like customers will be interacting with the ATM's desktop). Combine that with the ability to just not run services like Samba (Windows networking) and the like and you make it a lot easier to do support in-house as well, reducing the need to migrate in the first place.
It reads like it wasn't a subsidy to Google, it's that NASA sold fuel to all it's qualified partners at cost rather than at market rates. So the taxpayers didn't pay anything for a subsidy. NASA recouped what it paid for the fuel, it just didn't make a profit on the transaction. I don't see any compelling reason to require a government agency like NASA to turn a profit on it's deals, as long as it doesn't lose money on them either.
You don't have to save passwords. DD-WRT uses HTTP Basic authentication, so once you've logged in once the browser will continue to send the authentication header with every request for a path that the router's said requires authentication. The router doesn't need to remember any sessions for this to work, once you've entered the credentials for a given authentication realm and path the browser will retain them until you completely close and re-open the browser or clear the active logins data or until the router rejects your password and demands reauthentication.
In theory they should. But you have to trust Comcast to properly research the logs and determine that that IP address assigned to your modem (since the WiFi's part of the modem) was assigned to the public WiFi side and not your account. I'm not sure I'd trust Comcast with that when the consequences of them getting it wrong are so serious, I'd prefer to keep control over access. It may not stop all possibility of illicit access, but at least it'll be something I could have done something about.
And what exactly is stopping a bad guy from setting their network's SSID to 'xfinitywifi' and hijacking traffic? That's one reason I don't trust public hotspots in general, it's too easy for someone else to impersonate them and while I can and do protect my computer against attack from malware I can't protect my network traffic from the access point I'm connected to.
As far as "logging in" with their user ID, I doubt Comcast has set up the infrastructure to do 802.1x authentication and most clients aren't configured to handle it. They're using browser-based authentication, which means your computer will connect to any AP using SSID 'xfinitywifi' without prompting you and all your traffic will be accessible by that AP. A simple Web server mimicking the signon page coded to accept any password and you won't notice a thing.
Actually it is because of regulations. If someone hacks the bank's site and steals the money in your account, banking regulations make the bank liable for the loss not you. Banking regulations require the bank to have a minimum level of reserves to pay out withdrawals. Both of those make it less likely you'll have a problem getting your money. A bank can close it's doors and fold without paying depositors, but it can't do so without any legal liability to them for the money and the totals involved are large enough to make it lucrative for law firms to take on large groups of depositors and track the money down. And of course most people wouldn't put their money in a bank that wasn't FDIC-insured, so they'd get their money and the FDIC would handle tracking down the bank's owners.
And no, sadly the bank's web sites aren't any more secure than any others. It's just that laws and regulations make that not a problem for consumers, and the banks have an internal fraud-detection system that watches accounts for unusual activity. I've had more than a few times when something unusual caused a sudden large shift in my spending, and usually shortly after it starts I start getting calls from the bank's fraud department wanting me to verify the transactions. That system protects against any kind of fraud whether it be through the web site, an ATM, written checks or in-person at a branch.
No, as noted in the article they did not need to be logged into the router since the URLs used didn't require credentials. Yes, it's a horribly huge hole in security. Yes, it was left in undoubtably because "the only way to get to those pages is through the login page so it's secure". Yaright.
Some had the management UI accessible from the Internet, letting botnets probe routers and try common passwords directly (consumer routers have poor intrusion-reporting capabilities so the attempts are likely to go unnoticed).The majority, though, had URLs that can be accessed to change settings without requiring authentication. So the bad guys set up a site that exploits cross-site scripting bugs to cause your browser to access those URLs on the router when visiting the web site. That let them change the DNS servers without needing to crack the password, and the technique works no matter how strong a password you've set. The only way to avoid it's to avoid any router whose firmware's vulnerable. If you've got a vulnerable router that's supported by DD-WRT or OpenWRT, flashing the router with them's an option. The worst case is you brick the router and have to buy a new one, which is what you'd have to do if you didn't re-flash it.
Slashdot Mirror
The biggest problem here isn't the question of software patents. It's patents on things that are obvious, or are an obvious progression from something that's already common (eg. taking the manual process of balancing a checkbook and having a computer perform the exact same steps). It's just that software is the field where it's taken root the most, I think because people treat computers as some sort of magic that transforms the ordinary into something extraordinary.
The most straightforward way to deal with it might be to take computers out of the picture. Start by asking the question "If we replaced the computer with a trained monkey who could slavishly follow instructions, would this be patentable?". If the answer is "Yes.", then the patent's valid. If the answer's "No.", then the burden should be on the patent-holder to explain why the application of a computer to this problem is so non-intuitive, so non-obvious, that someone familiar with the problem and computers would not think of letting a computer handle the chore. And "Because nobody's done it before." is not a valid response. Someone always has to be the first one to try to solve a problem. Counter-intuitively, the patent-holder should have to show that they were not the first, that doing this was so non-obvious that there's a large number of other people who knew what they were doing who tried this and could not figure it out. That the first person to try it immediately found this solution should be considered support for the idea that this was an obvious solution and thus not eligible for patent. That is, after all, almost the dictionary definition of "obvious": the first thing you think to try when faced with a problem?
Only a couple of conditions:
1. All government services must be accessible at no cost via a method which is guaranteed to be available to any person. IOW if landline phone service isn't required to be universal then all government offices must have in-person hours and be staffed at a level sufficient to get everyone who shows up on any given day served before the office closes, or all services must be available via mail (postage pre-paid). Online-only services are not allowed, since the government isn't guaranteeing that everyone will receive Internet access. Phone-only services are not allowed since the government isn't guaranteeing everyone will receive cel phone service. Online-only or phone-only would only be allowed if the government mandated that everyone would be able to receive either Internet access or cel-phone service regardless of location. Which the service providers won't go for, since their whole goal is to avoid being legally required to provide service in unprofitable areas.
2. Any person must be able to get basic (local calling and 911 service) phone service at any address, regardless of where that address is, upon request at no more than the previous cost of equivalent landline service. Whether it be via cel or VOIP, the service must be available. Note that this doesn't completely get around requirement #1, since the basic service isn't guaranteed to provide access to government numbers. To the extent that it does, it would satisfy #1.
Except that, as these companies make abundantly clear when you're hired, you are not in an employment contract. You are an at-will employee who can leave at any time and who can be terminated at any time for any or no reason. Companies like that because it lets them just fire people whenever they want, and these agreements are simply to let the company have all the advantages of having at-will employees without having to suffer any of the consequences of having at-will employees.
Necessary to keep teams together? I don't think so. How about, maybe, paying well enough that people people aren't tempted to jump ship in the middle of a project? Or putting people under contract instead of having them be at-will employees? Sure you can't just fire them any time you want (unless you've got good cause, like failure to do their jobs), but you don't have to worry about losing them at any time either.
These hiring collusions aren't necessary to keep employees. They're only necessary to keep employees without the company doing anything to actually keep employees.
I do know that even as a non-disabled user, the behavior Peter describes as "per spec" (that is, mouse buttons are not keys for the purposes of releasing the sticky keys) is counter-intuitive since the modifier keys interact with mouse buttons the same way they do with non-modifier keys (ie. Control modifies selection with mouse clicks the same way it modifies selection with the keyboard). Given that normal interaction with both non-modifier keys and mouse buttons, I'd expect instructions about how modifier keys behave to also apply analogously when both non-modifier keys and mouse buttons (but not mouse movements) are involved. Either that or I would expect modifier keys to not interact with mouse clicks the same way they do with regular keys.
If the password was set by the system, either during a password reset or initial account creation, the first thing I do is change the password to a random one my password manager program's generated. Why were these accounts still using the system-created password? Also, the article seems to conflate two uses of the term "salt": the random nonce used to insure the stored hash value isn't the same for two different accounts that picked the same password, and the random string used in the plaintext of the initial password to avoid a trivially-guessable "password same as username"-type case. The two aren't at all the same.
The answer to why Netflix keeps DVDs around should be obvious if you take more than 10 seconds to think: Netflix wants to offer as many movies as they can to be as attractive to customers as possible, and the studios won't license most recent releases for streaming. As a second reason, there's probably customer demand: a significant number of customers may have bandwidth caps low enough, or connections slow/laggy enough, that streaming high-quality video isn't feasible.
Making the IMEI physically unalterable doesn't help. If you can re-flash the baseband and firmware, you can make it ignore the burned-in IMEI in favor of a programmable one stored in the phone's non-volatile memory.
Making a jammer, yes, but buying radio hardware isn't quite that simple. For anything operating in unlicensed or open-access spectrum (eg. CB radio), it's easy to buy hardware that won't exceed the allowable limitations. Buying gear that can transmit on any channel and/or at any power usually requires having your license recorded as part of the sale. No license = no gear.
As for the IMEI, as far as I know it's not used to authenticate to the cel network. That's done via the IMSI which is on the SIM. The IMEI's mostly used for locating hardware (eg. a lost/stolen phone). Authentication is done using a challenge/response system, and the key used to generate the response from the challenge is in secure storage in the SIM (can't be read short of direct physical access to the internals of the SIM). Unlike other systems, GSM treats the phone as just an interchangeable accessory, the subscriber identity and everything critical to network authentication is carried in the SIM. That's why I can pop the SIM out of one phone and pop it in another (or pop another carrier's SIM in my phone, if the phone isn't locked) and things Just Work.
Most of it's probably regulatory issues. Anything that transmits radio has to be set up so it can't go outside the FCC-set limits (eg. stays within maximum allowable power for a given channel, stays only on assigned channels, etc. etc.). That used to be handled in hardware, but these days it's cheaper to use generic hardware that'll transmit at any power on any channel and then impose the limitations within the baseband code. And it's cheaper to allow updating of the baseband than it is to replace phones to fix problems in the baseband code. That combination means that open-source baseband would allow you to re-flash a baseband that'd go outside regulatory limits, which'd be a no-no. Combine with a legal environment where the phone manufacturer, not the consumer, would be the one sued (because they've got deep pockets and the consumers don't) and you can see why we have the situation we have.
For A above, I don't think it's relevant. If AT&T thinks it's a better deal for them to unevenly distribute bandwidth, it's them that's paying for the traffic so I don't see any reason to second-guess them. As for B, if AT&T thinks the imbalance is a problem then AT&T should pay for the changes to their network. If their customers are simply requesting too much data, then AT&T needs to discuss rates with their customers. AT&T doesn't want to do that because they're scared if they raise rates they'll lose customers, but my thought is that if it's really that unprofitable to offer service at those rates then driving those customers to your competition is probably a good thing. Better it be your competitors selling $100 worth of service for $30 than you. That AT&T is afraid of driving customers away should be the big hint that they aren't losing money on the deal.
As an ISP customer I don't take flat rates for the cost savings. At eg. the rates Amazon charges for data transfer (and I'm assuming Amazon isn't losing money at those rates), I'd be getting off cheaper paying per gigabyte for bandwidth. I take flat rates to get a predictable, stable bill every month without having to worry that something weird will throw the bill out of kilter without warning.
CDNs aren't complicated, they're just another Web site. Netflix hosts it's content on a CDN. Users request data from the CDN, the CDN serves it up, just like any other Web site. The CDN pays for it's connection through it's service providers. It's between Netflix and the CDN how Netflix pays the CDN for hosting it's files and the bandwidth the CDN had to pay for for that hosting. And the CDN may offer AT&T a deal: let the CDN install servers at AT&T's interconnect points and the CDN will handle the transit traffic from Netflix so AT&T doesn't have to worry about either building it's own transit network or paying someone else for transit. But that's an offer AT&T has to evaluate, deciding whether the CDN's terms and prices are a better deal than either of the alternatives.
I already do the same for my own personal Web site. I don't host it myself, I host it on Linode. Linode pays it's providers for bandwidth, AT&T customers request data from Linode instead of directly from me just as if it were Linode's web site, and AT&T doesn't know or care how me and Linode handle settling up for the costs Linode incurred. Linode's my CDN, but that makes no difference to AT&T and shouldn't.
This is what peering agreements handle, and they're already in place. Netflix pays it's Internet provider. That provider in turn has an agreement with AT&T wherein they pay each other for handling each other's traffic. The problem is that AT&T's mostly an end-user network, primarily clients who receive data with very few servers who send data. That means that at the peering point it's primarily the providers AT&T peers with who handle traffic for AT&T's network, with very little traffic bound for those providers handled by AT&T's network.
AT&T simply doesn't like the terms. When an AT&T customer requests data from Netflix, providers like Level 3 handles that traffic as it passes from Netflix to AT&T. AT&T has two choices. It can peer with Level 3 at the same exchange where Netflix connects and handle delivering the traffic across the AT&T network to their customers. This is usually relatively cheap, but it means AT&T has to build a larger backbone network. Alternatively, they can peer at points closer to their customers and let Level 3 handle the cross-country transit. This way AT&T avoids having to build a cross-country network to deliver data, but they don't like having to pay Level 3 for handling the transit traffic. They'd rather have Netflix picking up the bill for it. But why should Netflix have to pay to accommodate AT&T's decisions about how to build their network? This rightly ought to be a matter for AT&T to work out, deciding what the trade-off should be between the cost of buying cross-country transit capacity from someone else vs. building their own cross-country network.
Every month, customers get a bill from AT&T for their Internet service. So, what exactly is that bill for, then, if it's not to pay AT&T for providing Internet service? That does, as I understand it, involve transferring data packets in both directions between my computer and Web sites so I can access the Internet. So, Mr. Cicconi, if what customers are paying you isn't in fact for providing that service, which is what you're saying when you say you're not being paid to let customers access Netflix (which is a Web site), then can you please provide a detailed breakdown of exactly what that bill is for and what service you are providing to your customers for each and every item for which you're billing them. Because if it's not for providing Internet service as advertised, I think every single one of your Internet service customers is entitled to a refund of everything they've paid for a service you haven't been providing them and possibly damages for your false advertising (claiming you're providing them with Internet service when you aren't).
And, Mr. Cicconi, if you claim you are providing your customers with Internet service and that's what that bill's for, please stop whining that you aren't being paid to provide Internet service when by your own admission you are being paid.
So if I store my dollar bills in a jar and it gets destroyed in a fire, I can go to the FDIC and get my money restored by them? No, I can't. That's because the FDIC doesn't insure dollars. It insures deposits (in whatever currency, at it's value in dollars when it was deposited) at institutions that're equivalent to a Bitcoin exchange. As far as gaining/losing value, shall we discuss the bank and financial company bailouts? They were all needed precisely because the banks and financial companies did deal heavily in assets that could and did lose value that quickly and got burned by it. As far as backing, riddle me this: what precisely can you trade a dollar bill in to the US government in exchange for? Nothing but another dollar bill, or a note promising to pay you some number of dollar bills at some point in the future. We haven't had a hard currency in ages, it's all fiat money that's worth exactly what someone else will trade you for it. Just like Bitcoins. If someone won't accept Bitcoins then they're worthless, just like a New Zealand dollar would be in a grocery store here. Technically an NZ dollar's worth some number of US dollars, but if the merchant won't accept it as payment it's a piece of scrap paper for all the good it'll do you. And if someone will sell me a $2000 computer for BTC 4, then a Bitcoin's worth about 500 US dollars.
I'd note that the question of the solvency/stability of a Bitcoin exchange has as much bearing on the viability of Bitcoin as a currency as the question of the solvency/stability of say Bank of America has on the viability of the US dollar as a currency. I can keep Bitcoins in my own wallet on my own computer just like I can keep dollars in my own wallet, use both to pay for things, and never be worried about whether any particular exchange or bank will go belly up. And if I choose an unstable institution to store my currency for me, I run the risk of losing my money whether it be Bitcoins or dollars or yen. The only reason banks don't deal with cryptocurrency is that, unlike most currency, cryptocurrency has a mathematical underpinning that makes it difficult for them to loan it out to other people and make money off it while you aren't actively using it.
The problem here is that the permissions system goes beyond just ordinary user permissions. The system itself uses permissions to control which parts of the system can do what, and those permissions are normally only available to system components (trying to install an app that asks for those permissions results in the app being rejected because it doesn't qualify to get those permissions). For instance, the "Across_users" permission was added to Android 4.2, and allows system components to break through the normal restrictions that separate different users in the system. An app with this permission can reach out and directly affect everything on the phone, not just the things that belong to it. It's restricted to Android system components only. But if I install an app that asks for it on an Android 4.0 device, the app will install without any warnings. If the device is then upgraded to 4.2, the app will silently get the "Across_users" permission activated. So now we have a user-installed app which has a permission that it could never legitimately have that lets it bypass security and the sandbox, and the user will be unaware of the problem. It's very definitely NOT just a UI issue.
In the Unix world it'd be equivalent to finding an other-writable directory sitting in the root user's PATH, and in that directory are executables named "ls", "cat" and so on. It's the kind of thing that'd make a security admin excrete cinder blocks at velocities sufficient to have them achieving high orbit, ceilings nonwithstanding.
That's the thing, though: for the most part the basic programming APIs haven't changed much since then. There's some new ones, but mostly code written for RHEL 2.1 will compile and run on Debian 7.4. The kernel will have been upgraded, the libraries and packages will have been upgraded, but the source code and makefiles and scripts will need minimal changes to make the jump. You won't be able to take advantage of the new features, but you won't be looking at nearly the work to migrate. Even widget sets are mostly backwards-compatible, and for an application like an ATM you can omit the desktop environment stuff that's undergone major changes over the years (why would an ATM need a desktop environment anyway, it's not like customers will be interacting with the ATM's desktop). Combine that with the ability to just not run services like Samba (Windows networking) and the like and you make it a lot easier to do support in-house as well, reducing the need to migrate in the first place.
It reads like it wasn't a subsidy to Google, it's that NASA sold fuel to all it's qualified partners at cost rather than at market rates. So the taxpayers didn't pay anything for a subsidy. NASA recouped what it paid for the fuel, it just didn't make a profit on the transaction. I don't see any compelling reason to require a government agency like NASA to turn a profit on it's deals, as long as it doesn't lose money on them either.
You don't have to save passwords. DD-WRT uses HTTP Basic authentication, so once you've logged in once the browser will continue to send the authentication header with every request for a path that the router's said requires authentication. The router doesn't need to remember any sessions for this to work, once you've entered the credentials for a given authentication realm and path the browser will retain them until you completely close and re-open the browser or clear the active logins data or until the router rejects your password and demands reauthentication.
In theory they should. But you have to trust Comcast to properly research the logs and determine that that IP address assigned to your modem (since the WiFi's part of the modem) was assigned to the public WiFi side and not your account. I'm not sure I'd trust Comcast with that when the consequences of them getting it wrong are so serious, I'd prefer to keep control over access. It may not stop all possibility of illicit access, but at least it'll be something I could have done something about.
And what exactly is stopping a bad guy from setting their network's SSID to 'xfinitywifi' and hijacking traffic? That's one reason I don't trust public hotspots in general, it's too easy for someone else to impersonate them and while I can and do protect my computer against attack from malware I can't protect my network traffic from the access point I'm connected to.
As far as "logging in" with their user ID, I doubt Comcast has set up the infrastructure to do 802.1x authentication and most clients aren't configured to handle it. They're using browser-based authentication, which means your computer will connect to any AP using SSID 'xfinitywifi' without prompting you and all your traffic will be accessible by that AP. A simple Web server mimicking the signon page coded to accept any password and you won't notice a thing.
Actually it is because of regulations. If someone hacks the bank's site and steals the money in your account, banking regulations make the bank liable for the loss not you. Banking regulations require the bank to have a minimum level of reserves to pay out withdrawals. Both of those make it less likely you'll have a problem getting your money. A bank can close it's doors and fold without paying depositors, but it can't do so without any legal liability to them for the money and the totals involved are large enough to make it lucrative for law firms to take on large groups of depositors and track the money down. And of course most people wouldn't put their money in a bank that wasn't FDIC-insured, so they'd get their money and the FDIC would handle tracking down the bank's owners.
And no, sadly the bank's web sites aren't any more secure than any others. It's just that laws and regulations make that not a problem for consumers, and the banks have an internal fraud-detection system that watches accounts for unusual activity. I've had more than a few times when something unusual caused a sudden large shift in my spending, and usually shortly after it starts I start getting calls from the bank's fraud department wanting me to verify the transactions. That system protects against any kind of fraud whether it be through the web site, an ATM, written checks or in-person at a branch.
No, as noted in the article they did not need to be logged into the router since the URLs used didn't require credentials. Yes, it's a horribly huge hole in security. Yes, it was left in undoubtably because "the only way to get to those pages is through the login page so it's secure". Yaright.
Some had the management UI accessible from the Internet, letting botnets probe routers and try common passwords directly (consumer routers have poor intrusion-reporting capabilities so the attempts are likely to go unnoticed).The majority, though, had URLs that can be accessed to change settings without requiring authentication. So the bad guys set up a site that exploits cross-site scripting bugs to cause your browser to access those URLs on the router when visiting the web site. That let them change the DNS servers without needing to crack the password, and the technique works no matter how strong a password you've set. The only way to avoid it's to avoid any router whose firmware's vulnerable. If you've got a vulnerable router that's supported by DD-WRT or OpenWRT, flashing the router with them's an option. The worst case is you brick the router and have to buy a new one, which is what you'd have to do if you didn't re-flash it.