I'm not claiming to be an economist, but I'd imagine there are some big problems with taxing consumption as well. As people will point out, taxing something often has the effect of discouraging it. Depending on how you structure the tax, it could encourage a pack-rat mentality, where people just stuff their money away. That's not all bad, since it serves a purpose of encouraging savings, but when you cut consumption, you have the potential of also cutting economic growth. In addition, a tax on consumption might hit poorer people, since everyone has a minimum amount that they must consume. For example, poor people and rich people both need to spend a minimum of $[X]/year on food just to survive. As the amount of income increases, that $[X] becomes a vanishingly small percentage of income for rich people, while it remains a substantial amount of money for the very poor.
Taxing consumption could also (again, depending on how it's structured) simply drive money out of the US. In its simplest form, it would become much cheaper to make money in the US (since income and capital gains wouldn't be taxed) while making it much more expensive to spend money here. The "smart thing to do" would be to make your fortune here and spend it elsewhere, where the tax is not on consumption.
And that also doesn't begin to confront the source of a lot of the problem: wealth and power represent a self-reinforcing cycle. To oversimplify a bit: Poor people have no power to promote their own interests, while rich people can use their economic power to develop other forms of power, which they can, in turn, use to reinforce their economic power. The obvious example of this is that they can contribute money to politicians, supporting politicians who will support their economic interests. Those politicians can change trade policy to benefit the wealthy person's business, or rewrite the tax code to allow the wealthy person to avoid paying taxes.
If we started taxing based on consumption, how long do you think it would take for an exception to be written into the tax code for private yachts?
And this immediately raises the question in my mind, how to we anticipate tracking "consumption" and deciding what should and should not be counted as "consumption"?
Now, I'm not ruling out the possibility of someone developing a plan that deals with these issues appropriately. But I've heard the suggestion of taxing consumption before, and I've never heard an adequate explanation of how all of these things would be addressed. It seems a bit... I don't know the right word-- silly? creepy? Well, it seems noteworthy to me that Bill Gates starts and finishes his argument by talking about how rich people should be treated differently based on how charitable they are. It suggests that his main motivation is to argue, "I'm one of the good ones. You should leave me alone and let me keep more of my money. Yes, yes, by all means, tax rich people more to deal with this income inequality issue, just so long as you don't tax me."
But in those cases the strength of the password doesn't matter...
Correct.
...and periodic rotation might not be enough to prevent damage.
Also correct. It might not be enough to completely prevent any damage, or it might. If it doesn't completely prevent any damage, it might limit the amount of damage that's done. Often, security is not about the removal of risk, but about the mitigation of risk.
OpenID is more complicated for the end user to manage, AND it puts additional technical burden on them to understand.
This is a dramatic shift in your argument. I don't want to start a whole new argument at this point, but in short, I would admit that OpenID as it stands is not a good/complete solution. I would only argue that the industry should be working together to develop a better solution, either by improving OpenID dramatically or developing a replacement that works better. I've argued in the past that such a solution should not merely provide SSO, but also include a more complete form of "identity management".
But now I've sacrificed my control over my users.
So again, you want a walled garden. Walled gardens are all well and good until you want to do something that falls outside the wall, or if you disagree with the gardener.
You say the failure of OpenID is malicious intent on the part of the big corporate players to create locked-in ecosystems.
Not malicious. More like "not benevolent". They aren't working toward a better solution that would be beneficial to us all, improving the way the Internet works. They aren't working on a superior technical solution that can work as a model for the future. They're working toward their own business interests, which includes corralling people into their walled gardens and locking them in. The shepherd isn't malicious towards the health of his sheep, but his intention is to slaughter them for meat.
A password's crackability is not measured in time units, but in number of failed attempts. So it would be useful to collect them.
A big part of what I was saying is, a password may become cracked with 0 failed attempts. There are other ways that an attacker can acquire a password.
No, you misunderstand. Authentication and authorization are fundamentally two different steps.
* First step, authentication: Some guy is claiming to be "Dynedain". I've checked the [certificate or password or whatever] against the [certificate authority or password has or whatever] and it checks out. Therefore, yes, I believe that this is "Dynedain".
* Second step, authorization: Now, let me look at my records to see what "Dynedain" is supposed to have access to. Is he allowed to have an account yet? Nope. He hasn't been authorized. Close the connection.
So in this case, you were authenticated, but not authorized. So Google could "trust" other servers in terms of authentication (This guy says he's "Dynedain@Slashdot.org" and "Slashdot.org" says that's true, so I'm going to believe that he is "Dynedain@Slashdot.org") without automatically trusting the user to the point of authorizing them to do anything.
If I trust Google IDs, and allow people to signup to my site with Google IDs, that is a fairly good way of limiting malicious bots from signing up on my site. But I've now accepted Google's signup policies as my own.
Yeah, see, right here, you're looking to Google to create a walled garden. You're saying, "I don't just want to trust Google's authentication, but I also want to trust that anyone who is using Google's authentication is *also* automatically authorized to have full access to my services." That's pretty much exactly what it means to have a walled garden-- creating a closed ecosystem with defined limits and restricted access to the outside world, in the hopes of creating a "safe area".
You're saying that you don't want Google to trust authentication from anywhere else because you want to trust that any authentication coming from Google is equivalent to valid authorization, which helps you prevent spambots from signing up for your service. It's not fundamentally different from saying that Google should only allow Gmail users to receive email from other Gmail users, which would prevent spam from reaching your inbox. You're not entirely wrong, but the reason it helps crack down on misuse is that walled gardens are easier to control. The higher level of control is both a good thing and a bad thing.
In the case of email and in the case of authorization, the negatives of walled gardens far outweigh the benefits. And Google knows this. They have smart people working for them. But then, they also want to push people toward using Gmail and Google+, and having a walled garden helps them accomplish that.
Now, if only I could believe it. Printer drivers have been going away fro decades now, and yet every year, I feel like the printer drivers become harder to install, less reliable, and more likely to bundle in some crapware to advertise that you can buy more printer ink. But maybe that's just because I'm using Windows...?
If tomorrow Google suddenly opened the floodgates and said spambots could create all the Google IDs they wanted
Already you completely misunderstand. Other companies wouldn't create GoogleIDs, they'd create other IDs. All Google would have to do is say, "I trust Facebook to be in charge of Facebook IDs. This user is claiming to be nine-times@facebook.com, and Facebook says that's true. Therefore, I'll trust that the user is nine-times@facebook.com, and they should have access to anything that nine-times@facebook.com is supposed to have access to."
What "nine-times@facebook.com" is supposed to have access to in Google's services is a whole other issue that Google can work out how to decide. This setup doesn't solve all problems, but it would solve a bunch of them.
The problem isn't trust. The problem is that these companies want walled gardens that they control.
I was talking as a customer, and not as a developer. And keep in mind, I'm not saying, "The app store sucks!" I'm just pointing out that there is room for improvement in app discovery and app browsing.
They've already improved it a lot by providing a large selection of editor recommendations. They'll have different promotional groups for apps (right now, I'm seeing one for "Get Stuff Done" and "Quick-Fix Games" for example). Not too long ago, they made it so you get recommendations and charts for each category, which they didn't used to do. These are all good choices, but I think they could do more. I'm just not entirely sure the best way to improve things.
But to give an example, it would be nice if, when you're looking at an application, there was a list of "the competition", i.e. similar apps on the App Store. If I'm looking for a todo list manager, let me easily see a list of some of my different options. It'd be even better if they could provide a method of comparison, such as "editor notes" describing the strengths/weaknesses of each, or a feature comparison matrix. I think this is a pretty good idea, but an idea with obvious problems. Most obviously, it sets Apple up to pick favorites (which they already do, to some extent), and pointing out problems with applications, which runs the risk of alienating developers.
Some other ideas: Allow developers to provide movies/tutorials rather than just screenshots. Improve searching to allow provide more control than just a keyword search. Put a button on each app's page for "more like this", showing a list of applications that have similar designs, are made by the same developer, or can be used for accomplishing certain goals. Refine the categorization of apps, so that I don't have games in the same category as media players, and I don't have business-targeted CRMs in the same category as Quicken and Mint.
Now you might not like my ideas. That's fine, they're just off the top of my head. Still, I think I'm right in that the store could be improved.
I took your example, and followed your instructions (to replace letters with numbers/symbols to make it more secure). That's all I did. Even going back to
'Tabrt"CHBS"', it seems much harder to remember that than "correct horse battery staple". I think a fundamental issue that you may be missing is, it does not make the password more secure or more memorable to take the first letters of each word. You still have to remember all of the words, so it's no more memorable, and spelling out the words to have a complete sentence is actually far more secure. The fact that you use whole words instead of letters does not make it more vulnerable to a dictionary attack.
I wouldn't necessarily go that far. I support both professionally, and there are certainly things about Windows that are easier. For example, Windows domains provide a lot of great tools. Microsoft Office is much better on Windows than on Macs.
But then there are some ways in which I've generally found easier on Macs than on PCs. They're all unixy, really. They come from the factory supporting php, perl, ruby, and bash. Imaging Macs isn't much harder than copying the contents of a bootable disk, and then running a command to make the disk bootable. There's no activation to for Apple's OS or apps. Many of the application install/uninstall consists of drag-and-drop (or just using a script to copy a directory in place). A lot of the configuration is stored in text files. The support is generally pretty damned good. And there *are* actually administrative tools that work pretty well, once you dig into it.
The biggest reason I don't do iOS development anymore (other than here and there) is because it's too damn crowded.
This brings up an issue that I have with the App Store from a customer/user perspective: it's not easy to find quality apps. Unless your application hits the front page by being on charted as one of their top apps, or by hitting one of their "editor's choice" lists, I'm probably not going to see it. Every once in a while, I actually go browsing through the different categories to see if there are any other nice apps out there, and even then I feel like there must be some hidden gems out there that I'm just not seeing.
I don't know how to fix that, but I think it is a problem. It's hard to browse/discover apps unless you already know which app you're looking for, or if it's one of the small number that Apple chooses to highlight.
I think he has some good points here, but as an IT (support) guy, I see other problems with the App Store that are completely unrelated. One of the biggest is the issue of "volume licensing". I don't know if Apple has sorted it all out recently, but last I looked into it, it was a confusing mess of a program with little administrative control. IIRC, at one point Apple was advising businesses to gift employees with applications that would then be bound to the employee AppleID, which is completely stupid, without the ability to withdraw the license and reuse it.
It's also pretty frustrating that you need to put in an Apple ID to install or update any application, even if it's free. For example, if the iWork/iLife apps are pre-installed on the system and there's a new update available, even though Apple detects that the apps are already installed, and Apple knows that the upgrades are free, it still won't install the updates until you sign in with an Apple ID. That might not seem like such a big deal, but when you're administering a few hundred Macs, it means that you either need to make every user create their own AppleID, or you need to provide them access to a company Apple ID which you then lose control over. Failing to come up with a solution means that your users are going to be bugged to update applications that they can't update.
And speaking of updates, AFAIK there's no command-line utility for the App Store application. This means that I can't control the thing with a script at all. Making it more confusing, there *is* a command-line utility to download and install system updates, which are normally installed through the App Store GUI. This means that if you look at a list of updates available for your system presented in the App Store application, you can write a script to install some of them automatically, but other updates need to be updated through the GUI. What I wouldn't give to be able to update everything with apt-get.
Getting back to the article, I'm not sure I completely agree with him. I understand his frustration with sandboxing, but on the other hand, left to their own devices, developers seem to do some really dumb and annoying things. For example, instead of using an installer or developing their app to be drag-and-drop, they develop a custom application that installs their software, making it difficult and frustrating to push out in an automated fashion. Or they code their application to require an installer, dumping their files all over the system, when it really shouldn't be necessary. I wouldn't be opposed to Apple supporting applications that require installers, so long as they (a) allowed customers to get access to the unaltered installer; and (b) kept tabs on what the installer did and rejected developers who used them unnecessarily. Otherwise, I think you'd see too much dumb crap on the App Store.
Again, like I said, "It's a hack to get around with the fact that things are built in a stupid way. If you came up with a real solution, a password manager would probably be useless, or at least redundant." It's not the internal combustion engine. Is ASCII art while we wait for someone to develop a real image format. It's not useless, and it's even a bit clever, but it is at least a little silly and stupid. Even if you took the concept of a password manager, it should instead be a certificate manager, and we should be using PKE for authentication rather than passwords. That would only raise the question, "Do I really need a separate cert for every site?" and the answer would of course be "no".
The problem exactly is trusting 3rd party services.
My point was, it's an issue of "trust" in the technical sense of authentication, but not trust in the sense of whether something is trustworthy. Google, Microsoft, and Facebook refuse to "trust" 3rd party authentication providers, but it's not because they can't trust them. It's because they want control and leverage over their own userbase, as well as having access/control/information about other developers who might be willing to use their authentication services.
As a user, I hate it when a security rule requires to change password. Why?
From your post, I think you're assuming that password rotation is meant to prevent against brute-force attacks. As in, "My password would take 20 years to crack via a simple brute-force, so I should rotate it every 20 years," or something like that. Though that makes sense, but there's a little more to it.
Essentially, most forms of attack that would compromise your password take some amount of time. Whether it's brute force, a dictionary attack, a hash-lookup, social engineering, or anything else, it takes some amount of time to execute the attack, get access to the password, and then make use of that information. Plus, most attacks are not targeted, but instead carried out in bulk. The attacker might try a dictionary attack on a large number of known email addresses, or the attacker gets their hands on a password table of a website, and they try looking up the password hashes for all the users of that website. By executing an attack on thousands of users at the same time, they can scoop up some low-hanging fruit, but that means that it will take a bit of time before they make use of that for any particular user.
So what rotating your password does is to shrink that window of time. If you rotate your password every two months, then an attacker has at most two months to compromise your account and then use the fact that your account compromised before they have to start over. If, on the other hand, you haven't changed your password in 10 years, then they may have compromised your account at any time over the past 10 years, and if they have, they can continue to access your account for whatever purpose they like. Yes, someone may have started a brute force attack 10 years ago, and they might have just cracked it today. Or, your ex-girlfriend might have seen your password 7 years ago, and he might have been reading your email for the past 7 years. Or a hacker might have gotten access to the website's hashed password list 3 years ago, taken 10 months to confirm all the passwords worked, sold your password 2 years ago, used access to your email account to watch for emails from your bank with important banking information over those 2 years, and just gotten access to your bank account yesterday.
The point is, you don't know how your account could be compromised, and does get compromised, you won't necessarily notice. If, however, your rotate your passwords on a regular basis, you're mitigating your risks.
It's a hack to get around with the fact that things are built in a stupid way. If you came up with a real solution, a password manager would probably be useless, or at least redundant.
I don't have the memory bandwidth to memorize a hundred unique passwords. I memorize four or five passwords (my email, my bank, my work, my home and my password manager). For everything else (my Slashdot, my wifi, etc) I use a password manager.
Great. As I said, "There are plenty of scenarios for which a password manager is helpful." Good for you for finding some. It's still not a real solution to the problem.
There are plenty of scenarios for which a password manager is helpful. However, as long as there are also a lot of scenarios for which password managers are inconvenient, password managers cannot replace memorable passwords.
As a Netflix subscriber whose ISP does not charge them for peered access, it is simply Wrong that part of my subscription fee is being used to pay Comcast, Verizon, etc. when I have no business relationship with them.
Any business you patronize is going to use some of your money for purposes that don't directly benefit you. Microsoft used some of the money I paid for Windows/Office to fund the development of the XBox, and I don't own an XBox. Boo hoo.
When 60% of peak traffic over the edge is from Netflix, pulling all that onto a dedicated peering link in many cases means there's no longer a congestion problem. Direct Peering IS a mechanism for fixing edge congestion.
Well we'll see. I think part of the concern is that Verizon can now start using this as leverage against anyone and everyone. They can basically make sure their peering connections are generally congested for anyone moving a significant amount of data, and then say, "If you want things to improve, pay us a bunch of money to become a Premium peering partner!" Taken to the extreme, the Internet could cease to become an open network, and instead become a AOL-styled walled garden.
The concept of the "correct horse battery staple" was that they were randomly chosen words. As I admitted in my post, the idea of using a line from a poem kind of falls apart insofar as it's possible to have that poem in the dictionary used in a dictionary attack.
The "correct horse battery staple" idea is sound, and isn't particularly vulnerable to a dictionary attack since a dictionary attack consists of checking likely combinations. If the words were chosen randomly, then there aren't "likely combinations", and you're back to talking about a brute force attack. Therefore, as you point out, you're going to be trying 235886^4 combinations to brute-force it, and that's assuming that all four words are in that dictionary.
Yes, I'm aware of OpenID. Even if Google technically uses it, effectively they don't, because it's not treated as an open/standard protocol, but as a proprietary authentication system that is offered by Google. As you said, "no one was willing to trust a 3rd party's servers". And I don't think it's really an issue of trust. Google, Facebook, and Microsoft have all offered a form of this service, and it's always really just a ploy to wrangle you into using their services.
You raise good points, but I think we need to take a step back from this question and ask, "What are we trusting them with?"
For example, I've long been a proponent of the idea of putting SSL certificates into signed DNS records so that we don't need to go through a certificate authority in order to use SSL on our web page. I've had people challenge me and say, "But that doesn't seem helpful. It's just a self-signed certificate!" To which, I point out that I've stuck it in my domain records, and it's verifiable from there, so it's less vulnerable to man-in-the-middle attacks. To that, I've gotten the response, "But that doesn't prove anything! If you want to prove you're really who you say you are, you need extended validation with identify verification. Otherwise your website could be fake, which means it's not absolutely secure." Again, true, but kind of missing the point.
Security is not about absolutes, but about understanding the likely attackers, the likely form of the attack, and establishing what trust to extend under what circumstances to guard against those attacks. In the case of trust, trust doesn't need to be absolute in order to accomplish the goals of security.
So going back to my example, if I create a website called "nine-times.org", create a self-signed SSL certificate and assign it to my site, then I can encrypt my traffic, preventing various kinds of easy attacks on my site and on the visitors to my site. That's a big security win, but since it's just a self-signed cert, I leave myself open to a MITM (man-in-the-middle) attack.
If, however, I put the self-signed certificate into a signed DNS record, then visitors could potentially verify my browser, preventing MITM attacks by verifying that the certificate that they've been provided is the correct certificate for the "nine-times.org" website. Now, this doesn't prove that the "nine-times.org" website is run by me. It doesn't prevent you from setting up a fake-but-similar website on "nine-times.com" and stealing my traffic. But that doesn't mean that my certificate validation isn't helpful or meaningful.
What it would mean is, when you connect to "nine-times.org" you can trust that you're actually talking to "nine-times.org", which has been verified by the person who owns that domain. That's all you're trusting that certificate validation to prove-- and that's a lot! Now, whether the "nine-times.org" website is a trustworthy site, or whether it's the site you intended to visit... that's a different issue. Sorry, I don't have as easy a method for verifying that. However, if we can establish that the site is trustworthy, as least the DNS-verified certificate would let you know that you're communicating with who you intended to communicate.
So I see this concept of identity management in a similar way. We don't actually need much trust to make it work, to prove that the identities are reputable people or even real people. We just need a method to verify that the digital identity you're dealing with is the same as the digital identity that it purports to be.
In fact, even if you wanted to use these identities for payment, you could greatly increase the security of transactions without necessarily linking the identity to a real person. You could have a method of payment where you could verify through a third-party trusted institution that "nine-times" in fact does have $[x] in an account without that institution knowing who "nine-times" is. The account could be with any kind of institution or currency, but as long as you trust that institution, you could know with cryptographic certainty that the "nine-times" you're talking to is the same "nine-times" that has possession of those funds.
Now, if you wanted to enable those digital identities to be used for legal purposes, tax purposes, passports, or something along those lines, *then* you'd need to get the Federal government involved. They would need to decide what level of authentication is required to verify that the digital identity is linked to a legal entity, but that doesn't mean that they'd necessarily have to do the identity management themselves.
Slashdot Mirror
I'm not claiming to be an economist, but I'd imagine there are some big problems with taxing consumption as well. As people will point out, taxing something often has the effect of discouraging it. Depending on how you structure the tax, it could encourage a pack-rat mentality, where people just stuff their money away. That's not all bad, since it serves a purpose of encouraging savings, but when you cut consumption, you have the potential of also cutting economic growth. In addition, a tax on consumption might hit poorer people, since everyone has a minimum amount that they must consume. For example, poor people and rich people both need to spend a minimum of $[X]/year on food just to survive. As the amount of income increases, that $[X] becomes a vanishingly small percentage of income for rich people, while it remains a substantial amount of money for the very poor.
Taxing consumption could also (again, depending on how it's structured) simply drive money out of the US. In its simplest form, it would become much cheaper to make money in the US (since income and capital gains wouldn't be taxed) while making it much more expensive to spend money here. The "smart thing to do" would be to make your fortune here and spend it elsewhere, where the tax is not on consumption.
And that also doesn't begin to confront the source of a lot of the problem: wealth and power represent a self-reinforcing cycle. To oversimplify a bit: Poor people have no power to promote their own interests, while rich people can use their economic power to develop other forms of power, which they can, in turn, use to reinforce their economic power. The obvious example of this is that they can contribute money to politicians, supporting politicians who will support their economic interests. Those politicians can change trade policy to benefit the wealthy person's business, or rewrite the tax code to allow the wealthy person to avoid paying taxes.
If we started taxing based on consumption, how long do you think it would take for an exception to be written into the tax code for private yachts?
And this immediately raises the question in my mind, how to we anticipate tracking "consumption" and deciding what should and should not be counted as "consumption"?
Now, I'm not ruling out the possibility of someone developing a plan that deals with these issues appropriately. But I've heard the suggestion of taxing consumption before, and I've never heard an adequate explanation of how all of these things would be addressed. It seems a bit... I don't know the right word-- silly? creepy? Well, it seems noteworthy to me that Bill Gates starts and finishes his argument by talking about how rich people should be treated differently based on how charitable they are. It suggests that his main motivation is to argue, "I'm one of the good ones. You should leave me alone and let me keep more of my money. Yes, yes, by all means, tax rich people more to deal with this income inequality issue, just so long as you don't tax me."
But in those cases the strength of the password doesn't matter...
Correct.
...and periodic rotation might not be enough to prevent damage.
Also correct. It might not be enough to completely prevent any damage, or it might. If it doesn't completely prevent any damage, it might limit the amount of damage that's done. Often, security is not about the removal of risk, but about the mitigation of risk.
OpenID is more complicated for the end user to manage, AND it puts additional technical burden on them to understand.
This is a dramatic shift in your argument. I don't want to start a whole new argument at this point, but in short, I would admit that OpenID as it stands is not a good/complete solution. I would only argue that the industry should be working together to develop a better solution, either by improving OpenID dramatically or developing a replacement that works better. I've argued in the past that such a solution should not merely provide SSO, but also include a more complete form of "identity management".
But now I've sacrificed my control over my users.
So again, you want a walled garden. Walled gardens are all well and good until you want to do something that falls outside the wall, or if you disagree with the gardener.
You say the failure of OpenID is malicious intent on the part of the big corporate players to create locked-in ecosystems.
Not malicious. More like "not benevolent". They aren't working toward a better solution that would be beneficial to us all, improving the way the Internet works. They aren't working on a superior technical solution that can work as a model for the future. They're working toward their own business interests, which includes corralling people into their walled gardens and locking them in. The shepherd isn't malicious towards the health of his sheep, but his intention is to slaughter them for meat.
A password's crackability is not measured in time units, but in number of failed attempts. So it would be useful to collect them.
A big part of what I was saying is, a password may become cracked with 0 failed attempts. There are other ways that an attacker can acquire a password.
No, you misunderstand me.
No, you misunderstand. Authentication and authorization are fundamentally two different steps.
* First step, authentication: Some guy is claiming to be "Dynedain". I've checked the [certificate or password or whatever] against the [certificate authority or password has or whatever] and it checks out. Therefore, yes, I believe that this is "Dynedain".
* Second step, authorization: Now, let me look at my records to see what "Dynedain" is supposed to have access to. Is he allowed to have an account yet? Nope. He hasn't been authorized. Close the connection.
So in this case, you were authenticated, but not authorized. So Google could "trust" other servers in terms of authentication (This guy says he's "Dynedain@Slashdot.org" and "Slashdot.org" says that's true, so I'm going to believe that he is "Dynedain@Slashdot.org") without automatically trusting the user to the point of authorizing them to do anything.
If I trust Google IDs, and allow people to signup to my site with Google IDs, that is a fairly good way of limiting malicious bots from signing up on my site. But I've now accepted Google's signup policies as my own.
Yeah, see, right here, you're looking to Google to create a walled garden. You're saying, "I don't just want to trust Google's authentication, but I also want to trust that anyone who is using Google's authentication is *also* automatically authorized to have full access to my services." That's pretty much exactly what it means to have a walled garden-- creating a closed ecosystem with defined limits and restricted access to the outside world, in the hopes of creating a "safe area".
You're saying that you don't want Google to trust authentication from anywhere else because you want to trust that any authentication coming from Google is equivalent to valid authorization, which helps you prevent spambots from signing up for your service. It's not fundamentally different from saying that Google should only allow Gmail users to receive email from other Gmail users, which would prevent spam from reaching your inbox. You're not entirely wrong, but the reason it helps crack down on misuse is that walled gardens are easier to control. The higher level of control is both a good thing and a bad thing.
In the case of email and in the case of authorization, the negatives of walled gardens far outweigh the benefits. And Google knows this. They have smart people working for them. But then, they also want to push people toward using Gmail and Google+, and having a walled garden helps them accomplish that.
Seriously.
Now, if only I could believe it. Printer drivers have been going away fro decades now, and yet every year, I feel like the printer drivers become harder to install, less reliable, and more likely to bundle in some crapware to advertise that you can buy more printer ink. But maybe that's just because I'm using Windows...?
If tomorrow Google suddenly opened the floodgates and said spambots could create all the Google IDs they wanted
Already you completely misunderstand. Other companies wouldn't create GoogleIDs, they'd create other IDs. All Google would have to do is say, "I trust Facebook to be in charge of Facebook IDs. This user is claiming to be nine-times@facebook.com, and Facebook says that's true. Therefore, I'll trust that the user is nine-times@facebook.com, and they should have access to anything that nine-times@facebook.com is supposed to have access to."
What "nine-times@facebook.com" is supposed to have access to in Google's services is a whole other issue that Google can work out how to decide. This setup doesn't solve all problems, but it would solve a bunch of them.
The problem isn't trust. The problem is that these companies want walled gardens that they control.
I was talking as a customer, and not as a developer. And keep in mind, I'm not saying, "The app store sucks!" I'm just pointing out that there is room for improvement in app discovery and app browsing.
They've already improved it a lot by providing a large selection of editor recommendations. They'll have different promotional groups for apps (right now, I'm seeing one for "Get Stuff Done" and "Quick-Fix Games" for example). Not too long ago, they made it so you get recommendations and charts for each category, which they didn't used to do. These are all good choices, but I think they could do more. I'm just not entirely sure the best way to improve things.
But to give an example, it would be nice if, when you're looking at an application, there was a list of "the competition", i.e. similar apps on the App Store. If I'm looking for a todo list manager, let me easily see a list of some of my different options. It'd be even better if they could provide a method of comparison, such as "editor notes" describing the strengths/weaknesses of each, or a feature comparison matrix. I think this is a pretty good idea, but an idea with obvious problems. Most obviously, it sets Apple up to pick favorites (which they already do, to some extent), and pointing out problems with applications, which runs the risk of alienating developers.
Some other ideas: Allow developers to provide movies/tutorials rather than just screenshots. Improve searching to allow provide more control than just a keyword search. Put a button on each app's page for "more like this", showing a list of applications that have similar designs, are made by the same developer, or can be used for accomplishing certain goals. Refine the categorization of apps, so that I don't have games in the same category as media players, and I don't have business-targeted CRMs in the same category as Quicken and Mint.
Now you might not like my ideas. That's fine, they're just off the top of my head. Still, I think I'm right in that the store could be improved.
I took your example, and followed your instructions (to replace letters with numbers/symbols to make it more secure). That's all I did. Even going back to 'Tabrt"CHBS"', it seems much harder to remember that than "correct horse battery staple". I think a fundamental issue that you may be missing is, it does not make the password more secure or more memorable to take the first letters of each word. You still have to remember all of the words, so it's no more memorable, and spelling out the words to have a complete sentence is actually far more secure. The fact that you use whole words instead of letters does not make it more vulnerable to a dictionary attack.
they are manifestly unsuited to it.
I wouldn't necessarily go that far. I support both professionally, and there are certainly things about Windows that are easier. For example, Windows domains provide a lot of great tools. Microsoft Office is much better on Windows than on Macs.
But then there are some ways in which I've generally found easier on Macs than on PCs. They're all unixy, really. They come from the factory supporting php, perl, ruby, and bash. Imaging Macs isn't much harder than copying the contents of a bootable disk, and then running a command to make the disk bootable. There's no activation to for Apple's OS or apps. Many of the application install/uninstall consists of drag-and-drop (or just using a script to copy a directory in place). A lot of the configuration is stored in text files. The support is generally pretty damned good. And there *are* actually administrative tools that work pretty well, once you dig into it.
The biggest reason I don't do iOS development anymore (other than here and there) is because it's too damn crowded.
This brings up an issue that I have with the App Store from a customer/user perspective: it's not easy to find quality apps. Unless your application hits the front page by being on charted as one of their top apps, or by hitting one of their "editor's choice" lists, I'm probably not going to see it. Every once in a while, I actually go browsing through the different categories to see if there are any other nice apps out there, and even then I feel like there must be some hidden gems out there that I'm just not seeing.
I don't know how to fix that, but I think it is a problem. It's hard to browse/discover apps unless you already know which app you're looking for, or if it's one of the small number that Apple chooses to highlight.
I think he has some good points here, but as an IT (support) guy, I see other problems with the App Store that are completely unrelated. One of the biggest is the issue of "volume licensing". I don't know if Apple has sorted it all out recently, but last I looked into it, it was a confusing mess of a program with little administrative control. IIRC, at one point Apple was advising businesses to gift employees with applications that would then be bound to the employee AppleID, which is completely stupid, without the ability to withdraw the license and reuse it.
It's also pretty frustrating that you need to put in an Apple ID to install or update any application, even if it's free. For example, if the iWork/iLife apps are pre-installed on the system and there's a new update available, even though Apple detects that the apps are already installed, and Apple knows that the upgrades are free, it still won't install the updates until you sign in with an Apple ID. That might not seem like such a big deal, but when you're administering a few hundred Macs, it means that you either need to make every user create their own AppleID, or you need to provide them access to a company Apple ID which you then lose control over. Failing to come up with a solution means that your users are going to be bugged to update applications that they can't update.
And speaking of updates, AFAIK there's no command-line utility for the App Store application. This means that I can't control the thing with a script at all. Making it more confusing, there *is* a command-line utility to download and install system updates, which are normally installed through the App Store GUI. This means that if you look at a list of updates available for your system presented in the App Store application, you can write a script to install some of them automatically, but other updates need to be updated through the GUI. What I wouldn't give to be able to update everything with apt-get.
Getting back to the article, I'm not sure I completely agree with him. I understand his frustration with sandboxing, but on the other hand, left to their own devices, developers seem to do some really dumb and annoying things. For example, instead of using an installer or developing their app to be drag-and-drop, they develop a custom application that installs their software, making it difficult and frustrating to push out in an automated fashion. Or they code their application to require an installer, dumping their files all over the system, when it really shouldn't be necessary. I wouldn't be opposed to Apple supporting applications that require installers, so long as they (a) allowed customers to get access to the unaltered installer; and (b) kept tabs on what the installer did and rejected developers who used them unnecessarily. Otherwise, I think you'd see too much dumb crap on the App Store.
Again, like I said, "It's a hack to get around with the fact that things are built in a stupid way. If you came up with a real solution, a password manager would probably be useless, or at least redundant." It's not the internal combustion engine. Is ASCII art while we wait for someone to develop a real image format. It's not useless, and it's even a bit clever, but it is at least a little silly and stupid. Even if you took the concept of a password manager, it should instead be a certificate manager, and we should be using PKE for authentication rather than passwords. That would only raise the question, "Do I really need a separate cert for every site?" and the answer would of course be "no".
The problem exactly is trusting 3rd party services.
My point was, it's an issue of "trust" in the technical sense of authentication, but not trust in the sense of whether something is trustworthy. Google, Microsoft, and Facebook refuse to "trust" 3rd party authentication providers, but it's not because they can't trust them. It's because they want control and leverage over their own userbase, as well as having access/control/information about other developers who might be willing to use their authentication services.
As a user, I hate it when a security rule requires to change password. Why?
From your post, I think you're assuming that password rotation is meant to prevent against brute-force attacks. As in, "My password would take 20 years to crack via a simple brute-force, so I should rotate it every 20 years," or something like that. Though that makes sense, but there's a little more to it.
Essentially, most forms of attack that would compromise your password take some amount of time. Whether it's brute force, a dictionary attack, a hash-lookup, social engineering, or anything else, it takes some amount of time to execute the attack, get access to the password, and then make use of that information. Plus, most attacks are not targeted, but instead carried out in bulk. The attacker might try a dictionary attack on a large number of known email addresses, or the attacker gets their hands on a password table of a website, and they try looking up the password hashes for all the users of that website. By executing an attack on thousands of users at the same time, they can scoop up some low-hanging fruit, but that means that it will take a bit of time before they make use of that for any particular user.
So what rotating your password does is to shrink that window of time. If you rotate your password every two months, then an attacker has at most two months to compromise your account and then use the fact that your account compromised before they have to start over. If, on the other hand, you haven't changed your password in 10 years, then they may have compromised your account at any time over the past 10 years, and if they have, they can continue to access your account for whatever purpose they like. Yes, someone may have started a brute force attack 10 years ago, and they might have just cracked it today. Or, your ex-girlfriend might have seen your password 7 years ago, and he might have been reading your email for the past 7 years. Or a hacker might have gotten access to the website's hashed password list 3 years ago, taken 10 months to confirm all the passwords worked, sold your password 2 years ago, used access to your email account to watch for emails from your bank with important banking information over those 2 years, and just gotten access to your bank account yesterday.
The point is, you don't know how your account could be compromised, and does get compromised, you won't necessarily notice. If, however, your rotate your passwords on a regular basis, you're mitigating your risks.
It's a hack to get around with the fact that things are built in a stupid way. If you came up with a real solution, a password manager would probably be useless, or at least redundant.
I don't have the memory bandwidth to memorize a hundred unique passwords. I memorize four or five passwords (my email, my bank, my work, my home and my password manager). For everything else (my Slashdot, my wifi, etc) I use a password manager.
Great. As I said, "There are plenty of scenarios for which a password manager is helpful." Good for you for finding some. It's still not a real solution to the problem.
There are plenty of scenarios for which a password manager is helpful. However, as long as there are also a lot of scenarios for which password managers are inconvenient, password managers cannot replace memorable passwords.
That's not secure! You should use "p@ssw0rd-dr0pb0x".
As a Netflix subscriber whose ISP does not charge them for peered access, it is simply Wrong that part of my subscription fee is being used to pay Comcast, Verizon, etc. when I have no business relationship with them.
Any business you patronize is going to use some of your money for purposes that don't directly benefit you. Microsoft used some of the money I paid for Windows/Office to fund the development of the XBox, and I don't own an XBox. Boo hoo.
When 60% of peak traffic over the edge is from Netflix, pulling all that onto a dedicated peering link in many cases means there's no longer a congestion problem. Direct Peering IS a mechanism for fixing edge congestion.
Well we'll see. I think part of the concern is that Verizon can now start using this as leverage against anyone and everyone. They can basically make sure their peering connections are generally congested for anyone moving a significant amount of data, and then say, "If you want things to improve, pay us a bunch of money to become a Premium peering partner!" Taken to the extreme, the Internet could cease to become an open network, and instead become a AOL-styled walled garden.
The concept of the "correct horse battery staple" was that they were randomly chosen words. As I admitted in my post, the idea of using a line from a poem kind of falls apart insofar as it's possible to have that poem in the dictionary used in a dictionary attack.
The "correct horse battery staple" idea is sound, and isn't particularly vulnerable to a dictionary attack since a dictionary attack consists of checking likely combinations. If the words were chosen randomly, then there aren't "likely combinations", and you're back to talking about a brute force attack. Therefore, as you point out, you're going to be trying 235886^4 combinations to brute-force it, and that's assuming that all four words are in that dictionary.
Yes, I'm aware of OpenID. Even if Google technically uses it, effectively they don't, because it's not treated as an open/standard protocol, but as a proprietary authentication system that is offered by Google. As you said, "no one was willing to trust a 3rd party's servers". And I don't think it's really an issue of trust. Google, Facebook, and Microsoft have all offered a form of this service, and it's always really just a ploy to wrangle you into using their services.
Now on the greater internet, who do we trust?
You raise good points, but I think we need to take a step back from this question and ask, "What are we trusting them with?"
For example, I've long been a proponent of the idea of putting SSL certificates into signed DNS records so that we don't need to go through a certificate authority in order to use SSL on our web page. I've had people challenge me and say, "But that doesn't seem helpful. It's just a self-signed certificate!" To which, I point out that I've stuck it in my domain records, and it's verifiable from there, so it's less vulnerable to man-in-the-middle attacks. To that, I've gotten the response, "But that doesn't prove anything! If you want to prove you're really who you say you are, you need extended validation with identify verification. Otherwise your website could be fake, which means it's not absolutely secure." Again, true, but kind of missing the point.
Security is not about absolutes, but about understanding the likely attackers, the likely form of the attack, and establishing what trust to extend under what circumstances to guard against those attacks. In the case of trust, trust doesn't need to be absolute in order to accomplish the goals of security.
So going back to my example, if I create a website called "nine-times.org", create a self-signed SSL certificate and assign it to my site, then I can encrypt my traffic, preventing various kinds of easy attacks on my site and on the visitors to my site. That's a big security win, but since it's just a self-signed cert, I leave myself open to a MITM (man-in-the-middle) attack.
If, however, I put the self-signed certificate into a signed DNS record, then visitors could potentially verify my browser, preventing MITM attacks by verifying that the certificate that they've been provided is the correct certificate for the "nine-times.org" website. Now, this doesn't prove that the "nine-times.org" website is run by me. It doesn't prevent you from setting up a fake-but-similar website on "nine-times.com" and stealing my traffic. But that doesn't mean that my certificate validation isn't helpful or meaningful.
What it would mean is, when you connect to "nine-times.org" you can trust that you're actually talking to "nine-times.org", which has been verified by the person who owns that domain. That's all you're trusting that certificate validation to prove-- and that's a lot! Now, whether the "nine-times.org" website is a trustworthy site, or whether it's the site you intended to visit... that's a different issue. Sorry, I don't have as easy a method for verifying that. However, if we can establish that the site is trustworthy, as least the DNS-verified certificate would let you know that you're communicating with who you intended to communicate.
So I see this concept of identity management in a similar way. We don't actually need much trust to make it work, to prove that the identities are reputable people or even real people. We just need a method to verify that the digital identity you're dealing with is the same as the digital identity that it purports to be.
In fact, even if you wanted to use these identities for payment, you could greatly increase the security of transactions without necessarily linking the identity to a real person. You could have a method of payment where you could verify through a third-party trusted institution that "nine-times" in fact does have $[x] in an account without that institution knowing who "nine-times" is. The account could be with any kind of institution or currency, but as long as you trust that institution, you could know with cryptographic certainty that the "nine-times" you're talking to is the same "nine-times" that has possession of those funds.
Now, if you wanted to enable those digital identities to be used for legal purposes, tax purposes, passports, or something along those lines, *then* you'd need to get the Federal government involved. They would need to decide what level of authentication is required to verify that the digital identity is linked to a legal entity, but that doesn't mean that they'd necessarily have to do the identity management themselves.
there are no good password managers.
Yes, that was what I was pointing out.