Why would they pay Foursquare? There's the local newspaper and several local tabloids, they can put coupons in them cheaper than Foursquare and almost everyone local who's looking for coupons is already reading one or more of those. Better local coverage, lower cost, again we're back to what exactly is Foursquare giving a local business that doesn't need to reach the entire world?
The Internet's good for global reach. But someplace like Rudford's? If you don't live in the area, you probably aren't going to make a trip to San Diego just to eat there and they aren't really interested in paying to make you aware they exist. And the whole checkin thing fails when it trips over the simple fact that it mainly tells me where my friends are at and if they're at Rudford's I probably already know because they pinged me asking if I was interested in dinner.
So what exactly does Foursquare bring to me? Not much. And since I'm the product it's selling to advertisers, if it's not bringing anything to me then why would I be showing up there to be sold?
For driving, it's the ultimate heads-up display: anything that can be displayed on a screen can be displayed overlaid on your actual field of view without you having to take your eyes off the road. Vehicle speed, a compass, GPS navigation indications. Even an actual map so you can see a bird's-eye view of the next few blocks worth of street. One thing I can see is integrating a couple of cameras into the system to give real-time speed or closure-rate readouts on surrounding cars or warnings of cars coming up behind or beside you.
I can also see it as a replacement for more mundane things. At a meeting it's helpful to have information about the other parties on tap, but it's rude to keep checking your laptop or tablet. So feed the data directly into your eyeball where it's just as available but not nearly as obvious. I'd love to see the first negotiation where one side has a team listening (and maybe watching), pulling up needed information and feeding it directly to their representative without any obvious hints that it's happening. It'd be unnerving when the rep knows your name, your wife's name and your kids' names before you're introduced, and even more so when he seems to have detailed financial reports on your company at his fingertips but he's got no tablet or smartphone, no notes, no obvious source.
The only downside is that currently it's very one-way: you can receive a lot of data, but it's inconvenient to enter text to send. You're limited to basically a single-button mouse.
I can't see how Motorola's using the lawsuit as a business strategy. They didn't file it, they don't want to be in court, and they have no choice about showing up or about what claims they have to defend against. I'm getting more and more annoyed at judges who get mad at defendants for having the temerity to stand up and defend themselves against the claims the plaintiff has made. If their defenses are meritless, then just rule so and be done with it. If they aren't meritless, then the blame for any complexity lies with the party making the claims, not the defense.
The solution's the standard one: take the long-term view. If you think Bitcoins are actually going to be worth that much long-term, don't sell. Hold onto them, and buy during the drops. If you think Bitcoins aren't worth their current value long-term, sell before another drop happens and don't buy back in. The speculators (because that's what's driving any manipulation) depend on people dumb enough to do short-term trading while lagging behind the curve. They're professionals with all the tools, so as a non-professional the only way you can win is to not play their game.
Rule of poker: there's always a sucker at the table. If you look around and don't see one, it's you.
The problem I see is that for software to process and work with the encrypted data it must be decrypted without human intervention. That means that either the software itself has to know the decryption key, the software has to know the authentication key used to get the decryption key from the crypto infrastructure, or the decryption key has to be available from the infrastructure without authentication. So while the encryption can protect against an intruder who's gained access to the network from the inside (without accessing the externally-visible side of the applications), it can't protect against an intruder who's gained access to the applications. And it seems like the most common exploits use vulnerabilities in the applications to gain access through the applications. So once the application is compromised, how does the encryption prevent the application from getting the decrypted data when the one unchangeable requirement is that the application can get the decrypted data to work on?
It's the same dilemma as with full-drive encryption. Sure, it'll protect your drive against someone who physicall steals your laptop. How much good will it do you against the malware slipped into your machine that accesses data while you're using your machine?
It's a fuzzy line. The question is whether the meals are non-cash compensation (thus taxable), an incidental in the workplace (not taxable) or just an ordinary expense to the employee. If you're running the business, you need to consult a tax accountant or tax attorney to get a definitive answer (or as definitive as it gets, the IRS are the ones with the last word on the matter).
From the employee side, usually if the meals are just discounted there's no tax issues. The only time it gets dicey is when the discounts are so high that it brings the price of the meals below cost. That's when the IRS might say the difference between the discounted price and cost is taxable non-cash compensation. That's where Google and others run into the problem: those meals cost something and they're giving them away free, and that difference is what the IRS wants reported as compensation the employee's receiving in a non-cash form. Drinks and such would normally be an incidental and not counted as compensation, unless the value is exceptionally high.
As for the company car, uniform, mobile phone and the like, yes they can be considered non-cash compensation with tax due on their value. Again it depends heavily on how they're handled. If the company's giving you the car, you owe taxes on the value. Normally though the company owns the car and just lets you use it while you're employed, when you leave the car stays with the company, so it may not be taxable compensation for you. Uniforms, if they're required and supplied by the company they're normally not compensation. OTOH if they're regular clothes that're usable outside work and you keep them when you leave, their value may be considered taxable compensation. If the phone's required as part of your job and the company "owns" it and just lets you use it for work purposes and will take it back when you leave, it probably won't be counted as compensation. If they're merely paying for your personal phone plan (or a part of it) or if you keep the phone and plan after you leave, the IRS may want what the employer's paying to be considered non-cash compensation.
That all this non-cash value given to the employee's at least potentially considered taxable compensation is long settled in favor of "Yes, it is.". The exact rules on whether a particular item is or isn't, well, that's what keeps tax accountants and attorneys gainfully employed.:)
It won't work mainly because the people they're asking to review the software are in positions where good relations with the vendor are important. Their employer won't allow them to bad-mouth their vendors because that can impact contract terms the next time the employer has to negotiate licenses. And the requirement for a LinkedIn profile means there's no way to post a review without the vendor knowing exactly which customer has admins who think their offering is crud.
Remember, when customers are saying that there's major problems with a product, to the vendor the problem isn't that there's major problems with the product, it's that customers are saying their are. So the vendor will proceed to fix the problem: they'll go after the customers who're saying bad things to make them shut up.
My rule's simple: if you can't do it without taking your attention off the road for longer than the time it takes to check your rear-view mirror, you shouldn't be doing it while driving. To me, electronic maps are the same as physical maps: they take too much of your attention off the road for too long to use safely when you're the driver. There's a few things they can safely be used for, but if you need them for navigation then you usually have to concentrate on them at the expense of the road for too long.
Because despite all that you still see Microsoft and Apple and other large companies trying to dismiss Linux as irrelevant or "too complicated". The point is to point out the need to counter that, to go "If it's so complicated and so hard to use and so irrelevant, why are we using it every day in simple, easy-to-understand things, without even thinking about it?".
Well, technically I don't have the right to say no, I have the contractual obligation to say no. I'm subject to LinkedIn's and Facebook's terms of service which specifically forbid me from allowing anyone else to access my account that way. If I said yes, I'd be in violation of those terms of service. And since my employer would have to agree to those terms of service as a condition of their accessing my account, then they'll have violated those terms of service and their access is unauthorized. If they don't accept the terms of service, their access is likewise unauthorized. And it's the position of the US Federal government that unauthorized access in violation of the terms of service is a felony violation of the Computer Fraud and Abuse Act. Plus, if the employer has a presence on those networks, they could find themselves in trouble for a separate violation of the terms of service for their own presence.
Thing is, increasingly the government outsources it's spying to... those same corporations. Why do it in-house where you have to comply (or at least appear to comply) with a bunch of regulations when you can farm it out to a private company (who's dropping some nice campaign donations on you) that, not being a government agency, doesn't have to comply with any of those regulations?
Simple: Spamhaus blocks not a single thing. Anywhere. Ever.
I block things by configuring my servers to check Spamhaus' list and use it to control what I accept and what I reject. If I choose not to use Spamhaus' list, Spamhaus can't and doesn't do a single blessed thing to prevent e-mail from a domain they list from being accepted by my server.
By saying you don't want Spamhaus to be able to work, you're saying you want to deny me any right to control my own servers.
And yes, Spamhaus does expand it's blocking beyond just the source of the e-mails. That's why they're effective. They only expand blocking when the service provider for the source of the spam declines to take any action. That's because service providers of that sort generally only react when their customers complain, and the recipients of spam aren't their customers. So if they won't act, Spamhaus makes the problem the provider's customer's problem. Now the provider has to decide whether the spammer's worth more than the rest of their customers. Call it the free market in action. And as for signing up for a mailing list and then reporting it as spam, it generally won't work. The most popular block list Spamhaus runs detects spam via the use of spamtrap addresses, not random user submissions. If your ISP is trusted by Spamhaus, it's unlikely they'll report a source of spam just on the say-so of one or two random users without doing any investigation. Over the years I've found that Spamhaus is at least 99.9% reliable, and the handful of "false" positives have been otherwise-legitimate e-mail sourced through a third-party service known to also serve spammers. And my comments to the senders tend to run along the lines of "If you don't understand why using a service that caters to spammers is your problem, it's not worth my time to educate you. And if that means I won't be able to do business with you, then I guess it's your competitor's lucky day, isn't it?".
Better idea: take the top generals in the hard-line faction, and identify which of them have a bunch of young grandchildren. On a day those grandchildren are at the general's house, drop a dud bomb loaded with 100lbs of Pop Rocks dead-center of the courtyard. A nice dual message: "Yes, we know who's really behind this and are perfectly willing and able to put an end to you." and "Yes, we're perfectly willing and able to make you suffer before we put an end to you.".
Are you positive that all the application servers you permit through the firewall are uncompromised? And that they'll remain uncompromised? Are there errors in the firewall that are allowing traffic through you don't expect? Are your servers in a data center where a mistake in the internal network could allow traffic to get to your machine from other (compromised) customers bypassing the firewall?
And does this vulnerability even require direct access to the database server, or is it one that can be triggered by data? If so, what do I need to filter in my applications to remove the kinds of bad data that could trigger the vulnerability? If normal firewalls and SQL-injection filtering would blunt the attack, I'd expect the PgSQL team to be less worried about revealing the problem because it wouldn't be very exploitable. So given their panic I have to assume that a normal installation with access to the database strictly limited by firewalls is still highly vulnerable to attacks against this bug. I'm remembering exotic bugs like ones involving non-standard UTF-8 sequences that could completely bypass SQL-injection filtering or trigger bugs in low-level libraries via ordinary data, vulnerabilities that required no special access to exploit and would work straight through the tightest of firewalls, but could be stopped dead by appropriate filtering if you knew what the problem was that you had to check against (eg. UTF-8 sequences that weren't the shortest valid sequence for that character).
A lot of the time the web servers need access to the database because the code on the web server will be doing database access. If the web servers are compromised, the firewalls will permit attacks from them against the database servers. And the same chain applies when there's application servers in the way, it just takes one more step. With automated toolkits that one more step will be taken by automated exploit software, so the attackers probably won't even notice the delay. There also, as you noted, the problem of internal attacks from compromised desktops and other machines with access to the database servers.
Security depends on securing all layers of the system, so that when (not if, when) any layer fails it doesn't compromise the entire system. If you design your security on the assumption that all other layers of security are intact and working, you just guarantee your security will fail.
The sysadmin's motto: "It's not whether you're paranoid, it's whether you're paranoid enough.".
My thought is that their reaction is exactly the wrong move. All it does is announce to the bad guys that there's a vulnerability they can exploit (which they probably know about already) and that none of their targets will know what it is or how to spot an attempt to exploit it, while at the same time insuring that the admins responsible for PgSQL servers can't find out what they need to protect against. If the vulnerability is that critical and severe that it can't be discussed, then as an admin it's critical and severe enough that I need to do something to mitigate it RIGHT FRAKKIN' NOW! I can't wait until Monday, I need to do something today to keep my PgSQL servers from being exploited. But as it stands the only thing I can do is shut them down completely and migrate fast to some other database. I can't wait, if I could the PgSQL team wouldn't be this panicked about the problem.
I think the main mistake he made is in thinking his mirrors were backups. He wasn't doing a live mirror, but what he was doing had one thing in common with mirrors: that the operation modifies the target. A proper backup would not have modified the target, it would've created a new target. That way if your source gets corrupted, doing the backup doesn't corrupt the target and you can recover from older versions of the backup.
Yes. Think about this: how do you recover the repository when the historical commit data is what's been damaged? Note that it doesn't have to be data corruption, although that's fairly common. One of the worst problems to recover from is human error, eg. an administrator makes a mistake cleaning up obsolete projects and permanently deletes more projects than intended, or makes a mistake on the filesystem itself and deletes the files associated with part of the repository. And yes you need more than a month's worth of backups to recover from that because sometimes the damage may not be apparent for months. I've got a project at work in version control that's incredibly critical, without it several major customers are totally off-line. Changes to it are very rare, measured in years per change, but when we do need changes to it they're high-priority (again the customer is totally off-line until the change goes in). If someone makes a mistake and wipes out that project it might literally be years before someone has a reason to look for the project and notice it's gone missing. If we only have a couple months worth of backups, what are we going to do?
IMO that'd be another thing I'd push: if on-line merchants are expected to collect taxes based on the buyer's place of residence, then brick-and-mortar stores should also have to collect it that way. So if I walk into a store in Nevada, they have to look up the sale tax due in San Diego, CA and collect that and remit it to California.
Brick-and-mortar retailers, I'd like to introduce you to this guy named Procrustes.
I'd say that's not the merchant's problem. If the state wants to have out-of-state merchants collect sales tax for it, then the merchants just remit to the state according to the rate the state sets. It's up to the state to distribute anything due to entities under it's jurisdiction like counties and cities. Or if the state doesn't want to collect taxes at that level, it can fight it out with the cities and counties. If it turns out the state wants merchants to collect city and county tax and remit it separately, then the state has to provide information in it's service about where to contact those cities and counties and they have the responsibility to provide the same standardized tax-rate service the merchant can query. Fair's fair, any entity that wants merchants to collect tax for it has to take responsibility for telling merchants how much tax to collect for each transaction. They don't want the responsibility, it's not the merchant's job to pick it up.
Won't work. Here in San Diego we have several ZIP codes where there are 2 sales tax rates within the ZIP code depending on the exact address. Parts of the ZIP code are within a city, subject to city sales tax, and parts are outside the city and city sales tax isn't due. To get the rate right you need to know not just the ZIP code but whether that particular address is inside or outside the city limits. And the state of California can't tell you which it is, the state doesn't know the exact city boundary. I doubt even the city could tell you without finding the address on a map.
I'd be OK with sales tax on on-line sales, on one condition: states be required to provide a standard way for merchants, at no cost to the merchant, to ask what the sales tax rate for a given address should be, with the answer being the legally binding rate (if the merchant charges the rate given in that answer then the merchant cannot be held liable if that rate turns out to be wrong, and if the service failed to answer for any reason then the merchant can't be held liable for failing to charge sales tax).
That's probably the easiest way to deter piracy: price it reasonably for it's job. Most people would rather get it legitimately than pirate it. Make it easy to download without going to shady download sites like CNet (I say shady because there's no way of telling where what they're hosting came from or who put it there, and I do not trust software where I can't trace it's provenance). Hosting downloads from your own domain will help, and leads into the next item: mark each copy you sell. Encode a serial number and buyer identity into each copy, making each one unique to the buyer. Make it clear when they buy that the copy's been stamped with their identity, and do the same on the initial splash screen if any and in the About dialog. This won't be seen by most people as anything particularly objectionable in itself, at the same time it'll make them skittish about just handing it out willy-nilly knowing that if someone they give it to uploads it to a torrent site or something it'll be them clearly identified as the source. It won't stop the hard-code pirates, but then very little will. It won't stop people from installing an extra copy for family. But it should be enough to convince the majority of people to tell their friends to just shell out the $15 for their own copy.
What'd've been useful: details of how/what to check to determine if your phone uses the vulnerable software, and what would indicate you've received an update. I tend not to use the WiFi calling anyway, but it'd be nice to be able to confirm the update. Looking at it my phone's still using the original release of the WiFi Calling app and hasn't had it's firmware updated since May 2012.
Slashdot Mirror
Why would they pay Foursquare? There's the local newspaper and several local tabloids, they can put coupons in them cheaper than Foursquare and almost everyone local who's looking for coupons is already reading one or more of those. Better local coverage, lower cost, again we're back to what exactly is Foursquare giving a local business that doesn't need to reach the entire world?
The Internet's good for global reach. But someplace like Rudford's? If you don't live in the area, you probably aren't going to make a trip to San Diego just to eat there and they aren't really interested in paying to make you aware they exist. And the whole checkin thing fails when it trips over the simple fact that it mainly tells me where my friends are at and if they're at Rudford's I probably already know because they pinged me asking if I was interested in dinner.
So what exactly does Foursquare bring to me? Not much. And since I'm the product it's selling to advertisers, if it's not bringing anything to me then why would I be showing up there to be sold?
For driving, it's the ultimate heads-up display: anything that can be displayed on a screen can be displayed overlaid on your actual field of view without you having to take your eyes off the road. Vehicle speed, a compass, GPS navigation indications. Even an actual map so you can see a bird's-eye view of the next few blocks worth of street. One thing I can see is integrating a couple of cameras into the system to give real-time speed or closure-rate readouts on surrounding cars or warnings of cars coming up behind or beside you.
I can also see it as a replacement for more mundane things. At a meeting it's helpful to have information about the other parties on tap, but it's rude to keep checking your laptop or tablet. So feed the data directly into your eyeball where it's just as available but not nearly as obvious. I'd love to see the first negotiation where one side has a team listening (and maybe watching), pulling up needed information and feeding it directly to their representative without any obvious hints that it's happening. It'd be unnerving when the rep knows your name, your wife's name and your kids' names before you're introduced, and even more so when he seems to have detailed financial reports on your company at his fingertips but he's got no tablet or smartphone, no notes, no obvious source.
The only downside is that currently it's very one-way: you can receive a lot of data, but it's inconvenient to enter text to send. You're limited to basically a single-button mouse.
I can't see how Motorola's using the lawsuit as a business strategy. They didn't file it, they don't want to be in court, and they have no choice about showing up or about what claims they have to defend against. I'm getting more and more annoyed at judges who get mad at defendants for having the temerity to stand up and defend themselves against the claims the plaintiff has made. If their defenses are meritless, then just rule so and be done with it. If they aren't meritless, then the blame for any complexity lies with the party making the claims, not the defense.
The solution's the standard one: take the long-term view. If you think Bitcoins are actually going to be worth that much long-term, don't sell. Hold onto them, and buy during the drops. If you think Bitcoins aren't worth their current value long-term, sell before another drop happens and don't buy back in. The speculators (because that's what's driving any manipulation) depend on people dumb enough to do short-term trading while lagging behind the curve. They're professionals with all the tools, so as a non-professional the only way you can win is to not play their game.
Rule of poker: there's always a sucker at the table. If you look around and don't see one, it's you.
The problem I see is that for software to process and work with the encrypted data it must be decrypted without human intervention. That means that either the software itself has to know the decryption key, the software has to know the authentication key used to get the decryption key from the crypto infrastructure, or the decryption key has to be available from the infrastructure without authentication. So while the encryption can protect against an intruder who's gained access to the network from the inside (without accessing the externally-visible side of the applications), it can't protect against an intruder who's gained access to the applications. And it seems like the most common exploits use vulnerabilities in the applications to gain access through the applications. So once the application is compromised, how does the encryption prevent the application from getting the decrypted data when the one unchangeable requirement is that the application can get the decrypted data to work on?
It's the same dilemma as with full-drive encryption. Sure, it'll protect your drive against someone who physicall steals your laptop. How much good will it do you against the malware slipped into your machine that accesses data while you're using your machine?
It's a fuzzy line. The question is whether the meals are non-cash compensation (thus taxable), an incidental in the workplace (not taxable) or just an ordinary expense to the employee. If you're running the business, you need to consult a tax accountant or tax attorney to get a definitive answer (or as definitive as it gets, the IRS are the ones with the last word on the matter).
From the employee side, usually if the meals are just discounted there's no tax issues. The only time it gets dicey is when the discounts are so high that it brings the price of the meals below cost. That's when the IRS might say the difference between the discounted price and cost is taxable non-cash compensation. That's where Google and others run into the problem: those meals cost something and they're giving them away free, and that difference is what the IRS wants reported as compensation the employee's receiving in a non-cash form. Drinks and such would normally be an incidental and not counted as compensation, unless the value is exceptionally high.
As for the company car, uniform, mobile phone and the like, yes they can be considered non-cash compensation with tax due on their value. Again it depends heavily on how they're handled. If the company's giving you the car, you owe taxes on the value. Normally though the company owns the car and just lets you use it while you're employed, when you leave the car stays with the company, so it may not be taxable compensation for you. Uniforms, if they're required and supplied by the company they're normally not compensation. OTOH if they're regular clothes that're usable outside work and you keep them when you leave, their value may be considered taxable compensation. If the phone's required as part of your job and the company "owns" it and just lets you use it for work purposes and will take it back when you leave, it probably won't be counted as compensation. If they're merely paying for your personal phone plan (or a part of it) or if you keep the phone and plan after you leave, the IRS may want what the employer's paying to be considered non-cash compensation.
That all this non-cash value given to the employee's at least potentially considered taxable compensation is long settled in favor of "Yes, it is.". The exact rules on whether a particular item is or isn't, well, that's what keeps tax accountants and attorneys gainfully employed. :)
It won't work mainly because the people they're asking to review the software are in positions where good relations with the vendor are important. Their employer won't allow them to bad-mouth their vendors because that can impact contract terms the next time the employer has to negotiate licenses. And the requirement for a LinkedIn profile means there's no way to post a review without the vendor knowing exactly which customer has admins who think their offering is crud.
Remember, when customers are saying that there's major problems with a product, to the vendor the problem isn't that there's major problems with the product, it's that customers are saying their are. So the vendor will proceed to fix the problem: they'll go after the customers who're saying bad things to make them shut up.
My rule's simple: if you can't do it without taking your attention off the road for longer than the time it takes to check your rear-view mirror, you shouldn't be doing it while driving. To me, electronic maps are the same as physical maps: they take too much of your attention off the road for too long to use safely when you're the driver. There's a few things they can safely be used for, but if you need them for navigation then you usually have to concentrate on them at the expense of the road for too long.
Because despite all that you still see Microsoft and Apple and other large companies trying to dismiss Linux as irrelevant or "too complicated". The point is to point out the need to counter that, to go "If it's so complicated and so hard to use and so irrelevant, why are we using it every day in simple, easy-to-understand things, without even thinking about it?".
Well, technically I don't have the right to say no, I have the contractual obligation to say no. I'm subject to LinkedIn's and Facebook's terms of service which specifically forbid me from allowing anyone else to access my account that way. If I said yes, I'd be in violation of those terms of service. And since my employer would have to agree to those terms of service as a condition of their accessing my account, then they'll have violated those terms of service and their access is unauthorized. If they don't accept the terms of service, their access is likewise unauthorized. And it's the position of the US Federal government that unauthorized access in violation of the terms of service is a felony violation of the Computer Fraud and Abuse Act. Plus, if the employer has a presence on those networks, they could find themselves in trouble for a separate violation of the terms of service for their own presence.
Thing is, increasingly the government outsources it's spying to... those same corporations. Why do it in-house where you have to comply (or at least appear to comply) with a bunch of regulations when you can farm it out to a private company (who's dropping some nice campaign donations on you) that, not being a government agency, doesn't have to comply with any of those regulations?
Simple: Spamhaus blocks not a single thing. Anywhere. Ever.
I block things by configuring my servers to check Spamhaus' list and use it to control what I accept and what I reject. If I choose not to use Spamhaus' list, Spamhaus can't and doesn't do a single blessed thing to prevent e-mail from a domain they list from being accepted by my server.
By saying you don't want Spamhaus to be able to work, you're saying you want to deny me any right to control my own servers.
And yes, Spamhaus does expand it's blocking beyond just the source of the e-mails. That's why they're effective. They only expand blocking when the service provider for the source of the spam declines to take any action. That's because service providers of that sort generally only react when their customers complain, and the recipients of spam aren't their customers. So if they won't act, Spamhaus makes the problem the provider's customer's problem. Now the provider has to decide whether the spammer's worth more than the rest of their customers. Call it the free market in action. And as for signing up for a mailing list and then reporting it as spam, it generally won't work. The most popular block list Spamhaus runs detects spam via the use of spamtrap addresses, not random user submissions. If your ISP is trusted by Spamhaus, it's unlikely they'll report a source of spam just on the say-so of one or two random users without doing any investigation. Over the years I've found that Spamhaus is at least 99.9% reliable, and the handful of "false" positives have been otherwise-legitimate e-mail sourced through a third-party service known to also serve spammers. And my comments to the senders tend to run along the lines of "If you don't understand why using a service that caters to spammers is your problem, it's not worth my time to educate you. And if that means I won't be able to do business with you, then I guess it's your competitor's lucky day, isn't it?".
Better idea: take the top generals in the hard-line faction, and identify which of them have a bunch of young grandchildren. On a day those grandchildren are at the general's house, drop a dud bomb loaded with 100lbs of Pop Rocks dead-center of the courtyard. A nice dual message: "Yes, we know who's really behind this and are perfectly willing and able to put an end to you." and "Yes, we're perfectly willing and able to make you suffer before we put an end to you.".
Are you positive that all the application servers you permit through the firewall are uncompromised? And that they'll remain uncompromised? Are there errors in the firewall that are allowing traffic through you don't expect? Are your servers in a data center where a mistake in the internal network could allow traffic to get to your machine from other (compromised) customers bypassing the firewall?
And does this vulnerability even require direct access to the database server, or is it one that can be triggered by data? If so, what do I need to filter in my applications to remove the kinds of bad data that could trigger the vulnerability? If normal firewalls and SQL-injection filtering would blunt the attack, I'd expect the PgSQL team to be less worried about revealing the problem because it wouldn't be very exploitable. So given their panic I have to assume that a normal installation with access to the database strictly limited by firewalls is still highly vulnerable to attacks against this bug. I'm remembering exotic bugs like ones involving non-standard UTF-8 sequences that could completely bypass SQL-injection filtering or trigger bugs in low-level libraries via ordinary data, vulnerabilities that required no special access to exploit and would work straight through the tightest of firewalls, but could be stopped dead by appropriate filtering if you knew what the problem was that you had to check against (eg. UTF-8 sequences that weren't the shortest valid sequence for that character).
A lot of the time the web servers need access to the database because the code on the web server will be doing database access. If the web servers are compromised, the firewalls will permit attacks from them against the database servers. And the same chain applies when there's application servers in the way, it just takes one more step. With automated toolkits that one more step will be taken by automated exploit software, so the attackers probably won't even notice the delay. There also, as you noted, the problem of internal attacks from compromised desktops and other machines with access to the database servers.
Security depends on securing all layers of the system, so that when (not if, when) any layer fails it doesn't compromise the entire system. If you design your security on the assumption that all other layers of security are intact and working, you just guarantee your security will fail.
The sysadmin's motto: "It's not whether you're paranoid, it's whether you're paranoid enough.".
My thought is that their reaction is exactly the wrong move. All it does is announce to the bad guys that there's a vulnerability they can exploit (which they probably know about already) and that none of their targets will know what it is or how to spot an attempt to exploit it, while at the same time insuring that the admins responsible for PgSQL servers can't find out what they need to protect against. If the vulnerability is that critical and severe that it can't be discussed, then as an admin it's critical and severe enough that I need to do something to mitigate it RIGHT FRAKKIN' NOW! I can't wait until Monday, I need to do something today to keep my PgSQL servers from being exploited. But as it stands the only thing I can do is shut them down completely and migrate fast to some other database. I can't wait, if I could the PgSQL team wouldn't be this panicked about the problem.
I think the main mistake he made is in thinking his mirrors were backups. He wasn't doing a live mirror, but what he was doing had one thing in common with mirrors: that the operation modifies the target. A proper backup would not have modified the target, it would've created a new target. That way if your source gets corrupted, doing the backup doesn't corrupt the target and you can recover from older versions of the backup.
Yes. Think about this: how do you recover the repository when the historical commit data is what's been damaged? Note that it doesn't have to be data corruption, although that's fairly common. One of the worst problems to recover from is human error, eg. an administrator makes a mistake cleaning up obsolete projects and permanently deletes more projects than intended, or makes a mistake on the filesystem itself and deletes the files associated with part of the repository. And yes you need more than a month's worth of backups to recover from that because sometimes the damage may not be apparent for months. I've got a project at work in version control that's incredibly critical, without it several major customers are totally off-line. Changes to it are very rare, measured in years per change, but when we do need changes to it they're high-priority (again the customer is totally off-line until the change goes in). If someone makes a mistake and wipes out that project it might literally be years before someone has a reason to look for the project and notice it's gone missing. If we only have a couple months worth of backups, what are we going to do?
IMO that'd be another thing I'd push: if on-line merchants are expected to collect taxes based on the buyer's place of residence, then brick-and-mortar stores should also have to collect it that way. So if I walk into a store in Nevada, they have to look up the sale tax due in San Diego, CA and collect that and remit it to California.
Brick-and-mortar retailers, I'd like to introduce you to this guy named Procrustes.
I'd say that's not the merchant's problem. If the state wants to have out-of-state merchants collect sales tax for it, then the merchants just remit to the state according to the rate the state sets. It's up to the state to distribute anything due to entities under it's jurisdiction like counties and cities. Or if the state doesn't want to collect taxes at that level, it can fight it out with the cities and counties. If it turns out the state wants merchants to collect city and county tax and remit it separately, then the state has to provide information in it's service about where to contact those cities and counties and they have the responsibility to provide the same standardized tax-rate service the merchant can query. Fair's fair, any entity that wants merchants to collect tax for it has to take responsibility for telling merchants how much tax to collect for each transaction. They don't want the responsibility, it's not the merchant's job to pick it up.
Won't work. Here in San Diego we have several ZIP codes where there are 2 sales tax rates within the ZIP code depending on the exact address. Parts of the ZIP code are within a city, subject to city sales tax, and parts are outside the city and city sales tax isn't due. To get the rate right you need to know not just the ZIP code but whether that particular address is inside or outside the city limits. And the state of California can't tell you which it is, the state doesn't know the exact city boundary. I doubt even the city could tell you without finding the address on a map.
I'd be OK with sales tax on on-line sales, on one condition: states be required to provide a standard way for merchants, at no cost to the merchant, to ask what the sales tax rate for a given address should be, with the answer being the legally binding rate (if the merchant charges the rate given in that answer then the merchant cannot be held liable if that rate turns out to be wrong, and if the service failed to answer for any reason then the merchant can't be held liable for failing to charge sales tax).
That's probably the easiest way to deter piracy: price it reasonably for it's job. Most people would rather get it legitimately than pirate it. Make it easy to download without going to shady download sites like CNet (I say shady because there's no way of telling where what they're hosting came from or who put it there, and I do not trust software where I can't trace it's provenance). Hosting downloads from your own domain will help, and leads into the next item: mark each copy you sell. Encode a serial number and buyer identity into each copy, making each one unique to the buyer. Make it clear when they buy that the copy's been stamped with their identity, and do the same on the initial splash screen if any and in the About dialog. This won't be seen by most people as anything particularly objectionable in itself, at the same time it'll make them skittish about just handing it out willy-nilly knowing that if someone they give it to uploads it to a torrent site or something it'll be them clearly identified as the source. It won't stop the hard-code pirates, but then very little will. It won't stop people from installing an extra copy for family. But it should be enough to convince the majority of people to tell their friends to just shell out the $15 for their own copy.
What'd've been useful: details of how/what to check to determine if your phone uses the vulnerable software, and what would indicate you've received an update. I tend not to use the WiFi calling anyway, but it'd be nice to be able to confirm the update. Looking at it my phone's still using the original release of the WiFi Calling app and hasn't had it's firmware updated since May 2012.