I've used these for a long time. It's almost natural to use the neutral plural as a neutral singular: when you say "he or she", you're implicitly referring to two possible states of gender, so using "they" to stand for the superposition of the two makes sense.
Hmm. If I recall correctly, flooding a country with counterfeit currency to destabilize its financial system has actually been done (or at least proposed) before.
What's interesting about this DOS attack is it doesn't matter if every single counterfeit transaction is discovered as such and rejected... what's being attacked is the efficiency of the system itself. If transactions get inefficient enough, the currency becomes burdensome to use, so people forgo it and turn to other mediums of exchange.
(Whether you're a BTC fan or not, it's fascinating to watch Bitcoin's pristine mathematical world rocked by thousands of years of lessons-learned in real world financial competition. Vires in Numeris indeed.)
Many people who believe in the flat Earth theory turn to the Bible in order to back up their theory. They quote various passages in order to back up their theories and interpret certain passages literally. Not all of them rely on the Bible though or simply on the Bible. Samuel Shenton who formed the Flat Earth Society, one of the most modern flat earth groups, believed that his beliefs could be proven using common sense and science.
(Quoting from Ask.com) The term 'parabellum' refers to a type of semiautomatic pistol or machine-gun which is also known as Luger. The name was derived from a Latin saying which means ''if you wish for peace, prepare for war''.
So: we've got the threat of war, the name of a gun, and the fact that "antebellum" -- a term which is basically synonymous with the pre-Civil-War South -- might be appealing for exactly the reason you give. Sounds like a pretty good name choice for an RNC project.
It was an internal email, intended to calm the waters in a time of change... I don't think he would have come out and said, "Well, we've got stiff competition in both the mobile and server markets, and we've really fumbled the ball in the past with things like Microsoft Bob, the Zune, Windows ME, Vista, and the Windows 8 UI, but please don't send your resume to Google just yet..."
...as lobbyists in the UK, where they will dine frequently and lavishly with their old friends still in Parliament, to ensure that such a close call never occurs again.
Well, that's sort of like saying, "I developed lupus* at age 40, so in this particular case it would have been better if I didn't have an immune system at all." I'm not sure a doctor would agree.
* Lupus is an auto-immune disease, where your immune system gets confused and attacks your body**. ** "It's never lupus."
No. Those automated systems enable a small number of human beings to administer a large number of servers in a consistent, sanity-checked, and monitored manner. If Google didn't have those automated systems, every configuration change would probably involve a minor army of technicians performing manual processes: slowly, independently, inconsistently and frequently incorrectly.
I work on a large, partially public-facing enterprise system. Automated deployment, fault detection, and rollback/recovery make it possible for us to have extremely good uptime stats. The benefits far outweigh the costs of the occasional screwup.
Well, it depends on what "create your own money" means. Certainly we have department stores issuing their own credit cards and gift certificates right now, and airlines allowing you to earn "points" when you fly. In all cases, your balance -- positive or negative -- is just a number in a register somewhere. If you allow people to transfer a portion of that number between themselves via gift certificates, or exchange a portion for goods or services, then it seems to me that you have the beginnings of a currency.
As long as Amazon pays the necessary taxes, fees, bri--, er, "campaign contributions", etc. to keep the Feds off their back, and more dollars are flowing into the US than out of it, I'm not seeing a great incentive to shut the operation down.
As for not being unable to shut down Bitcoin because of its distributed nature -- I'm sorry, I just don't buy that in the long term. Do you really believe that it will never be within the power of governments to monitor the Internet traffic of its citizens and sniff out BTC-related packets or access to BTC-related websites?
For non-banking corporations like say Google and MSN, there is the options of adding banking features to their repertoire and credit say something like MSN credits in lieu of interest or other earned income and provide a whole range of services in exchange or even cashing out your earned credits (not the original capital which remains regular local currency and can be withdrawn at any time).
That's exactly what I'm talking about... something like "Amazon Gift Cards", but with an extended range of services so that you can use them for buying Amazon products (perhaps initially at a discount), pool or transfer portions of them electronically through Amazon's website, etc. Earn credits (i.e., interest) towards other Amazon purchases, etc. Perhaps even connect buyers and sellers as per EBay.
All with Amazon certifying the lion's share of the transactions, and hosting the biggest exchange, the wallet software, and backing everything with insurance such that transactions are reversed if goods are not delivered.
People always talk about one of the benefits of Bitcoin being the lack of the usual 2-3% transaction fees associated with credit cards. Marketplaces like Amazon have had to build those fees into their pricing structure. But if there were a way for them to securely transfer funds without such fees, they could keep their prices the same and keep the additional profits (less the costs of running the cryptocoin/wallet/etc. infrastructure).
In short: Amazon now has their own in-store "credit card", like many major department stores -- except it's a cryptocurrency, backing one of the largest department stores on the planet.
Because the current users of Bitcoin are generally computer-savvy and security-minded -- except for the ones who insist on using wallets hosted in the cloud, but we can assume that they're a minority.
As for the Great Unwashed, though, they're still using passwords like "123456" and shrugging their shoulders at Snapchat's gaping security holes while they sext with friends. Because convenience.
I can't speak for Google -- its business model is a little different -- but Amazon has the customer base, market penetration, and mindshare to prop up a currency. Imagine if they just started by basing Amazon Gift Certificates off the technology. Suddenly next Christmas, several hundred million teens and twenty-somethings would have wallets and be spending Amazoncoins. Amazon trumpets the numbers, using them as proof that Amazoncoins are popular, thus setting the stage for further acceptance by people who know nothing about Bitcoin but sure as hell know Amazon.
You know, if a company like Amazon or Google -- with their immense server farms for mining -- did come up with its own cryptocoin, it could tilt the masses towards accepting the idea of cryptocurrencies, while simultaneously taking a huge bite out of Bitcoin's future potential.
Imagine an Amazoncoin, AZC, providing everything that BTC provides plus... - convenient support for payment to Amazon.com or transactions throughout the web - theft-insurance-backed online wallets for people who are unwilling to manage wallets on their own - nice incentives for mining companies willing to partner with them to support AZC transactions in the early days.
I totally believe it... I can imagine a bunch of causes for this, too, like catching and ignoring an exception from the authentication layer. Because some very junior developers assume that exceptions are always bad, especially in the case of an "impossible" situation (as in, the user could NEVER make it to this page without having logged in and then clicked on a bunch of things, and I don't want to have to deal with this checked exception, so I'll just catch it, print an error message, and continue...).
See the reply by "cbhacking" above. It might not be as obvious as a parameter in a URL, but it might be in a cookie or a POST'ed parameter.
A lot of big systems are built by a mix of senior and junior developers, because government contracts are won partly on price. So you invariably get a few people who only have a few years of experience and may not have thought about these issues. And since the senior people are worrying about the difficult stuff like the database schema and the business logic, that leaves the junior folks building a lot of the rest of the code, including the webtier layer.
Now, certainly the senior folks are going to make sure that the web framework is configured so that sessions are managed properly and no one gets in without authenticating, but once they're in, it's up to each individual request handler (meaning, something like a Struts Action) to ensure that it only serves resources that this particular user is allowed to see.
Terminology-wise, "authentication" says who you are, and "authorization" says what you can do after you've been authenticated as user X. Authentication is usually straightforward to configure for a given web framework, but authorization is fine-grained and strongly tied to business logic and even the peculiarities of individual user/database records. Hence authorization logic gets sprinkled around the UI layer where your more-junior people may be doing the implementation. And if the application is complex enough to have a hundred separate actions, dumb security holes can get buried.
Code reviews and security audits can catch some of the more obvious abuses, but for a system that had a massive scope creep like HealthCare.gov, the senior developers were probably too frantic to do due diligence.
They have my sympathies -- the problem here was most likely management at all levels agreeing to an unrealistic schedule with last-minute requirements changes, and also not letting bad news flow up the chain to the people that could have put a halt to disaster. But they still need to bring the white hat hackers in-house to tell them where the vulnerabilities are, and then they need to fix them. They can't just shrug their shoulders and say, "what are the odds that someone will bother to look at the site cookies and reverse-engineer a way of grabbing other people's data". Because, thanks to this article at least, odds are officially 1 in 1.
Good point. I've always been impressed by how hackers can exploit the information gleaned from a very sample interactions with a system to discern the underlying algorithm behind token choice, etc. I saw a step-by-step presentation recently from DEFCON on how the presenter was able to break into someone's social media account, IIRC by whittling down millions or billions of possible authentication tokens to a very small number by a combination of social engineering and sleuthing using the clock time, host IP, etc. I wish I could find it again and post it here; it was dizzying.
Disclaimer: I've never been to the site, but I can almost imagine how such a hack might be done, because it's so easy to code a bad webapp:
1. Create an account on the site. 2. Log in. 3. Notice that your URL ends in something like/showUserProfile?userID=70001 4. While still in your session, tweak the URL's userID to some other numbers to see if you can bring another user's profile up. If you can, then: 5. Automate the grabbing of userIDs 1 through 70000 via a Perl/Python/whatever script.
A properly-designed app would validate the authenticated session against any data it was trying to access. A poorly-designed one would not, and so be vulnerable to this sort of attack.
Slashdot Mirror
I've used these for a long time. It's almost natural to use the neutral plural as a neutral singular: when you say "he or she", you're implicitly referring to two possible states of gender, so using "they" to stand for the superposition of the two makes sense.
Yup, that must be what I'm thinking of: Operation Bernhard. More info here: http://en.wikipedia.org/wiki/O...
Hmm. If I recall correctly, flooding a country with counterfeit currency to destabilize its financial system has actually been done (or at least proposed) before.
What's interesting about this DOS attack is it doesn't matter if every single counterfeit transaction is discovered as such and rejected... what's being attacked is the efficiency of the system itself. If transactions get inefficient enough, the currency becomes burdensome to use, so people forgo it and turn to other mediums of exchange.
(Whether you're a BTC fan or not, it's fascinating to watch Bitcoin's pristine mathematical world rocked by thousands of years of lessons-learned in real world financial competition. Vires in Numeris indeed.)
Ok, found it. 52nd.
It looks like google.com is 4th, and bing.com is...
um...
...ok, does anybody know where bing.com is?
http://www.universetoday.com/4...
Sounds legit. Teach the Controversy!
(Quoting from Ask.com) The term 'parabellum' refers to a type of semiautomatic pistol or machine-gun which is also known as Luger. The name was derived from a Latin saying which means ''if you wish for peace, prepare for war''.
So: we've got the threat of war, the name of a gun, and the fact that "antebellum" -- a term which is basically synonymous with the pre-Civil-War South -- might be appealing for exactly the reason you give. Sounds like a pretty good name choice for an RNC project.
It was an internal email, intended to calm the waters in a time of change... I don't think he would have come out and said, "Well, we've got stiff competition in both the mobile and server markets, and we've really fumbled the ball in the past with things like Microsoft Bob, the Zune, Windows ME, Vista, and the Windows 8 UI, but please don't send your resume to Google just yet..."
...as lobbyists in the UK, where they will dine frequently and lavishly with their old friends still in Parliament, to ensure that such a close call never occurs again.
Yep. I think you nailed it. :-)
Microsoft to strike deal with UK government offering them thousands of free copies of MS Office in 3...2...1...
Also the sentence. :-)
So... not unlike Rule 34, then...
Well, that's sort of like saying, "I developed lupus* at age 40, so in this particular case it would have been better if I didn't have an immune system at all." I'm not sure a doctor would agree.
* Lupus is an auto-immune disease, where your immune system gets confused and attacks your body**.
** "It's never lupus."
No. Those automated systems enable a small number of human beings to administer a large number of servers in a consistent, sanity-checked, and monitored manner. If Google didn't have those automated systems, every configuration change would probably involve a minor army of technicians performing manual processes: slowly, independently, inconsistently and frequently incorrectly.
I work on a large, partially public-facing enterprise system. Automated deployment, fault detection, and rollback/recovery make it possible for us to have extremely good uptime stats. The benefits far outweigh the costs of the occasional screwup.
Well, it depends on what "create your own money" means. Certainly we have department stores issuing their own credit cards and gift certificates right now, and airlines allowing you to earn "points" when you fly. In all cases, your balance -- positive or negative -- is just a number in a register somewhere. If you allow people to transfer a portion of that number between themselves via gift certificates, or exchange a portion for goods or services, then it seems to me that you have the beginnings of a currency.
As long as Amazon pays the necessary taxes, fees, bri--, er, "campaign contributions", etc. to keep the Feds off their back, and more dollars are flowing into the US than out of it, I'm not seeing a great incentive to shut the operation down.
As for not being unable to shut down Bitcoin because of its distributed nature -- I'm sorry, I just don't buy that in the long term. Do you really believe that it will never be within the power of governments to monitor the Internet traffic of its citizens and sniff out BTC-related packets or access to BTC-related websites?
For non-banking corporations like say Google and MSN, there is the options of adding banking features to their repertoire and credit say something like MSN credits in lieu of interest or other earned income and provide a whole range of services in exchange or even cashing out your earned credits (not the original capital which remains regular local currency and can be withdrawn at any time).
That's exactly what I'm talking about... something like "Amazon Gift Cards", but with an extended range of services so that you can use them for buying Amazon products (perhaps initially at a discount), pool or transfer portions of them electronically through Amazon's website, etc. Earn credits (i.e., interest) towards other Amazon purchases, etc. Perhaps even connect buyers and sellers as per EBay.
All with Amazon certifying the lion's share of the transactions, and hosting the biggest exchange, the wallet software, and backing everything with insurance such that transactions are reversed if goods are not delivered.
People always talk about one of the benefits of Bitcoin being the lack of the usual 2-3% transaction fees associated with credit cards. Marketplaces like Amazon have had to build those fees into their pricing structure. But if there were a way for them to securely transfer funds without such fees, they could keep their prices the same and keep the additional profits (less the costs of running the cryptocoin/wallet/etc. infrastructure).
In short: Amazon now has their own in-store "credit card", like many major department stores -- except it's a cryptocurrency, backing one of the largest department stores on the planet.
Eh... just a fun thought experiment. :-)
Because the current users of Bitcoin are generally computer-savvy and security-minded -- except for the ones who insist on using wallets hosted in the cloud, but we can assume that they're a minority.
As for the Great Unwashed, though, they're still using passwords like "123456" and shrugging their shoulders at Snapchat's gaping security holes while they sext with friends. Because convenience.
I can't speak for Google -- its business model is a little different -- but Amazon has the customer base, market penetration, and mindshare to prop up a currency. Imagine if they just started by basing Amazon Gift Certificates off the technology. Suddenly next Christmas, several hundred million teens and twenty-somethings would have wallets and be spending Amazoncoins. Amazon trumpets the numbers, using them as proof that Amazoncoins are popular, thus setting the stage for further acceptance by people who know nothing about Bitcoin but sure as hell know Amazon.
You know, if a company like Amazon or Google -- with their immense server farms for mining -- did come up with its own cryptocoin, it could tilt the masses towards accepting the idea of cryptocurrencies, while simultaneously taking a huge bite out of Bitcoin's future potential.
Imagine an Amazoncoin, AZC, providing everything that BTC provides plus...
- convenient support for payment to Amazon.com or transactions throughout the web
- theft-insurance-backed online wallets for people who are unwilling to manage wallets on their own
- nice incentives for mining companies willing to partner with them to support AZC transactions in the early days.
I totally believe it... I can imagine a bunch of causes for this, too, like catching and ignoring an exception from the authentication layer. Because some very junior developers assume that exceptions are always bad, especially in the case of an "impossible" situation (as in, the user could NEVER make it to this page without having logged in and then clicked on a bunch of things, and I don't want to have to deal with this checked exception, so I'll just catch it, print an error message, and continue...).
Second image down:
http://www.midorisnyder.com/th...
Man, but medieval porn was tame.... :-)
See the reply by "cbhacking" above. It might not be as obvious as a parameter in a URL, but it might be in a cookie or a POST'ed parameter.
A lot of big systems are built by a mix of senior and junior developers, because government contracts are won partly on price. So you invariably get a few people who only have a few years of experience and may not have thought about these issues. And since the senior people are worrying about the difficult stuff like the database schema and the business logic, that leaves the junior folks building a lot of the rest of the code, including the webtier layer.
Now, certainly the senior folks are going to make sure that the web framework is configured so that sessions are managed properly and no one gets in without authenticating, but once they're in, it's up to each individual request handler (meaning, something like a Struts Action) to ensure that it only serves resources that this particular user is allowed to see.
Terminology-wise, "authentication" says who you are, and "authorization" says what you can do after you've been authenticated as user X. Authentication is usually straightforward to configure for a given web framework, but authorization is fine-grained and strongly tied to business logic and even the peculiarities of individual user/database records. Hence authorization logic gets sprinkled around the UI layer where your more-junior people may be doing the implementation. And if the application is complex enough to have a hundred separate actions, dumb security holes can get buried.
Code reviews and security audits can catch some of the more obvious abuses, but for a system that had a massive scope creep like HealthCare.gov, the senior developers were probably too frantic to do due diligence.
They have my sympathies -- the problem here was most likely management at all levels agreeing to an unrealistic schedule with last-minute requirements changes, and also not letting bad news flow up the chain to the people that could have put a halt to disaster. But they still need to bring the white hat hackers in-house to tell them where the vulnerabilities are, and then they need to fix them. They can't just shrug their shoulders and say, "what are the odds that someone will bother to look at the site cookies and reverse-engineer a way of grabbing other people's data". Because, thanks to this article at least, odds are officially 1 in 1.
I found the DEFCON video that shows the really creative ways that webapps can be attacked, along the lines of what you're talking about:
https://www.youtube.com/watch?...
It's by Samy Kamkar. I strongly recommend it for any developer of public-facing webapps.
Good point. I've always been impressed by how hackers can exploit the information gleaned from a very sample interactions with a system to discern the underlying algorithm behind token choice, etc. I saw a step-by-step presentation recently from DEFCON on how the presenter was able to break into someone's social media account, IIRC by whittling down millions or billions of possible authentication tokens to a very small number by a combination of social engineering and sleuthing using the clock time, host IP, etc. I wish I could find it again and post it here; it was dizzying.
Disclaimer: I've never been to the site, but I can almost imagine how such a hack might be done, because it's so easy to code a bad webapp:
1. Create an account on the site. /showUserProfile?userID=70001
2. Log in.
3. Notice that your URL ends in something like
4. While still in your session, tweak the URL's userID to some other numbers to see if you can bring another user's profile up. If you can, then:
5. Automate the grabbing of userIDs 1 through 70000 via a Perl/Python/whatever script.
A properly-designed app would validate the authenticated session against any data it was trying to access. A poorly-designed one would not, and so be vulnerable to this sort of attack.
+1 Insightful. Especially for the "shower" example.