Sorry to break it for you but boot time is measured from the push of the power button to a usable desktop. You may enjoy your 26 seconds of pretending that "this is not really happening" - most other people don't.
On what hardware? I have a brand new MacBook sitting next to me that takes pretty exactly 30 seconds from the push of the button to a usable desktop. Is it broken?
It's still more visual noise. Imho the '%' syntax should stay the way it is - it's quick to type and easy to parse for a human. Furthermore it'd be great if they would add perl-style =~ regex-matches.
Other than that they can objectify all they want, as far as I am concerned.
We need a level of response similar to the Y2K audit to cure this, not just another virus in the mix.
Man, how paranoid can you even be. That's FUD and nonsense!
Repeat after me: Any system that could be negatively affected by a counter-worm is already at the mercy of the STORM operators today, right now, in this minute!
If a STORM operator willy-nilly decides to push a broken update to the botnet, or to perform an expensive attack that makes some of the machines break down then your imaginary life-supporting systems will go down right there, today, in 5 minutes, or tomorrow afternoon.
There are plenty of companies including hospitals and power stations running top to bottom Windows solutions
Nonsense. Oh my, do you honestly believe that the heart-lung machine at your hospital is connected to the internet? Or that your nuclear power plant is running on Windows XP? Let me assure you: They are not. And if someone in the world truly misdesigned a critical system in a way that could be affected by a windows worm then we'd better be grateful for the learning expirience that they'll inevitably get (with or without a counter-worm). Or would you really want them to get away with that? Do you really think it'd be good idea to let them get into the habit of building critical stuff upon "cheap" Microsoft infrastructure?
Even if your nonsensical assumptions were correct: I'd still much prefer to have one powerplant melt down today due to a counter-worm than to have hundreds of powerplants running on vulnerable systems in 30 years because hey, "nothing ever happened".
If it screws up uninfected machines and networks, oh well, umm whoops?
Nonsense. If the counter-worm manages to interfere with machines or networks that are not infected by the original worm then these machines and networks were not properly secured and/or isolated in first place. Their admins should be glad that the counter-worm sheds light on the flaws before a malicious operator of the original worm does.
If there are actually critical, life-supporting systems affected, damn, I guess we can't say sorry to the dead, perhaps send a nice e-mail to their grieving families?
Nonsense. The heart-lung machine in your hospital does not run windows. The telco systems that dispatch your emergency calls do not run windows. If there are any truly critical systems out there vulnerable to a worm then we'd better find out about that sooner than later. What's the difference between a counter-worm breaking them today versus a "regular" worm breaking them tomorrow?
Your post is not unlike the difference between, say, a clueless person using inappropiate analogies, and the proof that car analogies hardly ever make any sense.
Seriously, all this crap is blown way out of proportion. Firetrucks. Car-Bombs. My ass...
If they have a tool to eliminate a large botnet then, by all means, do it. Stop crying for attention in the press, just run the damn counter-worm or release the source-code so the scriptkiddies can fragment the worm into insignificance.
If that wipes out the worm: Great! If that bricks all infected machines: Well, still better than what we had before.
There's no need to worry about collateral damage. Critical, life-supporting systems are not participating in storm. The worst that can happen is that a lot of computer illiterate people will have a "broken PC" over night and will have to ask their "PC guy" to fix it. This is a "risk" that we should be willing to take...
Interesting view of the "backbone"-problematic and I can second some of the restructuring problems, as I'm also from germany.:-)
I generally agree with your backbone-view, but as I described in my reply to turbidostato I don't think that this is a sustainable strategy. I have seen the same effects that you describe in many companies but imho those of them that survived only survived because everyone else in their market is *also* working in the same failure-mode. It's nearly impossible to gain or sustain any momententum when you work in this "lazy backbone"-mode.
That is okay as long as nobody else has any momentum either. But "unfortunately", especially in the web-business, we see these young, unconventional startups pop up left and right. I guess quite a few CEOs cry a lot these days because they must watch how their cake is eaten by a bunch of university-dropouts who simply get shit done without wasting so much time on playing "real company".
Remember corporate burocracy is basically the art of dealing with mediocrity.
You say that as if it's a good thing or an unchangeable fact of life. Having worked with my share of mediocre teams I can't disagree more. Mediocrity may work out in other departments and a few subsections of IT as long as there's a strong puppetmaster pulling the strings. But I don't believe in the common "100 codemonkeys will hammer out a shakespare" notion.
A coder who can't properly handle a daily SCM workflow or who even deliberately screws it up to slack off will hurt productivity, no matter how you spin it. Anyone who tolerates such people on their team either has no clue (the common failure-mode in smaller corps) and/or just doesn't care (the common failure-mode in large corps where managers spend most of their time fighting over budgets and bonuses).
It's no secret anymore that the difference in productivity between a great coder and a mediocre coder is measured in orders of magnitude. I have witnessed teams of 3 outpace teams of 30 more than once and you probably have, too.
Moreover, if you look at the hiring strategies of the big guys you'll notice that they tend to agree with me here. Google, Yahoo, Microsoft, Oracle and others are all said to aim for top-notch only. Ofcourse you can seldomly assemble teams of *only* Einsteins, simply because not so many Einsteins are available. But the idea is to have Einsteins in all critical positions, partly because that's also a natural protection against slackers like the one described by grandparent.
Unfortunately in large R&Ds you always have to align on lowest competence level.
If that's your premise then you're dead in the water anyways. I have a better idea: Why don't you just fire the incompetent slacker instead of slowing down the rest of your team?
Sorry to burst your bubble but most software projects do involve artwork and it makes a lot of sense to version that, too - along with the source code. Do you think artists never make mistakes? Do you think nobody ever wants to go back to an older version of a button-image after a while because the new one wasn't received well? Well if so then let me welcome you to the real world.
Well, this FAQ entry was admittedly a bit sloppy and dismissed the issue without really explaining.
To clarify and correct it: Yes, you can change your password. The technical implementation for such a password change would be a bit more involved than it is today but it could definately be wrapped up into a simple "change password" dialog, displayed and executed by the browser.
I initially answered this with a "No" because I don't think your use-cases are truly relevant but after thinking about it more: Yes, users will demand the functionality (if only out of irrational habit) and yes, it can be done.
If you had read my other follow up posts you'd realize that this is not about cookies. Admittedly my usage of the term "session" was misleading, though. I meant to say: At the beginning of the browser-session, i.e. when you start the browser.
Ha! That's interesting, didn't know about it (maybe because I'm never using excel). Makes you wonder how many corporations and individuals have based their decisions on miscalculated data...
Generally no, your browser doesn't need to follow you - all browsers would just need to implement the same HTTP protocol extension and credential hashing.
Furthermore I don't think that any kind of common ID should be used for truly critical sites such as online-banking. I'll be the first to argue that a separate password for your online-banking is mandatory, plus a TAN system (one time passwords) for each transaction.
What we're talking about here is not to combine your current 173 passwords into one. We're talking about combining your current 173 passwords into three or four. One for your "master" identity, one for your "on the road" identity (of which you could have any number, if you feel so inclined) and one each for your online-banking and other truly critical sites.
Well, see my other post for a more detailed description.
Well, imho OpenID is broken by design. I give them credit for "making the best of existing infrastrucutre" but, as the low adoption shows, this is unfortunately not good enough. OpenID is cumbersome, incomplete and just screams "i'm a nasty hack" into everyone's face. The sad truth is that even if it was properly executed (sane APIs etc.) it would still not gain significant traction because the basic premise of exporting your identity to a remote party is flawed.
Anyways, see my other post for more details on the utopy that I have in mind.
Are you talking about client-side certificates? Or are you talking about Kerberos?
Neither. I'm talking about an implementation similar to these two but optimized for the browser use-case.
You are ofcourse right, the technology exists, in theory. But it's nowhere near usable because no one has bothered to put the pieces together. Usable would be:
Open Browser (any browser, on any machine)
Enter Username and Master Password (the combination must be globally unique, so force users to a minimum 20 chars pass-phrase)
Surf around, taking advantage of that "Login" chrome-button as you see fit
The "registration" link on websites merely asks for personal information, no more passwords
This all is technically feasible today. The only hard case in the resulting system would be the "Lost / stolen password" case. Fortunately there is a fairly simple solution to this:
First off, when someone captures your password (e.g. keylogger) then he'll obviously temporarily own your identity. There's no way to avoid that, live with it and just don't enter your master password on public terminals.
We'd need a network of public revokation servers. Authenticate to one of them once and they'll add your current token to a list of "expired" identities. Websites would query this list for each "login" and reject blacklisted identities. This can be fast, similar to the antispam RBLs that we already have. Thus, when your identity is stolen you'd have a simple and fast way to revoke it - and the thief can't do anything about it, the identity is invalidated immediately and forever.
It's trivial to have multiple identities; just enter a different username/password when the browser prompts you. Websites should allow to chain multiple tokens to any one of their accounts (e.g. by requiring the original identity to confirm the addition). Thus you'd commonly have one "master identity" that you only use from the comfort and security of your home and primarily to "register" at the various websites that you care about. To that you'd add any number of "secondary identities" that you can use to login from work or when you're on the road. All those identities can (not must!) chain you to the same account on the websites that you frequent. The idea is to make it less painful to revoke a compromised identity; Your "on-the-road" password was stolen? No problem, revoke it, create a new one and chain it to all the accounts that you care about using the (uncompromised) master-identity - nothing lost and no need to enter your details again on all those websites.
FAQ:
But what about collisions when two people pick the same username/password?
Easy. Force a reasonable minimum length on username and password. I'd suggest 5 chars for the username, 20 for the password.
But idiots will use joe@microsoft.com / aaaaaaaaaaaaaaaaaaa!
Idiots will always be idiots. Choose a half-sane password and your identity will be secure.
Can I change my password?
No. Why would you want to?
But the website-owners can see my token and use it to login to other websites!
No. The browser creates a unique token for each website you visit from your username, password and the websites domain name (e.g. "slashdot.org"). The token generation could be as simple as MD5( username | password | domain ) - in reality we'd probably use HMAC. A website owner can not use your token to authenticate to other websites and it cannot generate tokens for other websites from the token he sees.
Who runs the public revokation servers?
Now this would be an interesting application for P2P technology. We don't want a single entity to control these things, so distribute it. The detailed spec for such a system is too long for a slashdot post - but in the end it's just a matter of actually implementing it, no really hard or "unsolvable" problems involved here.
I considered it, really. But writing Fx addons is painful, to say the least. And even if it magically made it into the public build that would still only cover 30% of all web traffic. Not nearly enough to gain momentum in itself and a pipe dream anyways, as the moz guys would never support a proprietary extension like that.
The only realistic way to establish such a thing in the long-term would be as part of the HTTP standard, when was HTTP/1.2 scheduled again?
If you have a better solution, I'd like to know what it is.
Well, I can offer the obvious solution.
Put authentication in the browser. Oh my god, what a novel idea! Have the user enter his password once, at the beginning of the session, and create a unique token for each site from that. Submit that token along with every request, in a HTTP-header.
No login required ever. Sites can distinguish users by their tokens (even when they're not "logged in") and a registration merely consists of connecting a token to whatever metadata (a username, address, whatever the user wants to give out to a particular site).
Paranoid users could choose to suppress the token by default and only start submitting it when they hit the "Login" button on their browser chrome - without typing in a username or password ever.
Better yet, add a bit of cryptographic trickery and these tokens can easily be revokable, updateable etc. for the cases where a password is stolen or "lost". And ofcourse browsers could easily store multiple "identities" and provide a dropdown to switch between them on the fly.
It's not rocket science, really. The whole system could be designed and spec'ed out over a weekend and would work better than anything that we had before. No third parties involved and everybody (even the data collectors) happy.
Problem? Oh, right. Getting it into the mainstream browsers... Well, give it another 20 years.
* Ten good reasons to pull down your pants before taking a dump * Ask Slashdot: I keep forgetting things, anyone know a good way to not forget things? * How to manage your data, ten good recommendations for folder names * Ask Slashdot: What size harddrive should I buy?
Seriously, what reason is there to 'limit liability' for the owners if not to do things they wouldn't do personally?
The reason is that otherwise hardly anyone would ever start a company - other than people who already own truckloads of money.
Let's say you have this really great idea for a word processor software. You can build it and bring it to market, no problem. But you know that MS will probably sue you and you can't be sure about the outcome of that. With limited liability you at least know that the worst that can happen is that your company goes out of business and you wasted a few years of your life. Without limited liability on the other hand... Well, good luck paying off those seven digit "virtual damages" that some court may bill you for.
Slashdot Mirror
Sorry to break it for you but boot time is measured from the push of the power button to a usable desktop.
You may enjoy your 26 seconds of pretending that "this is not really happening" - most other people don't.
On what hardware?
I have a brand new MacBook sitting next to me that takes pretty exactly 30 seconds from the push of the button to a usable desktop. Is it broken?
Asiatronouts.
It's still more visual noise. Imho the '%' syntax should stay the way it is - it's quick to type and easy to parse for a human.
Furthermore it'd be great if they would add perl-style =~ regex-matches.
Other than that they can objectify all they want, as far as I am concerned.
Maybe light rests only when nobody's looking?
Just like we browse slashdot at work only when nobody's looking?
Man, how paranoid can you even be. That's FUD and nonsense!
Repeat after me: Any system that could be negatively affected by a counter-worm is already at the mercy of the STORM operators today, right now, in this minute!
If a STORM operator willy-nilly decides to push a broken update to the botnet, or to perform an expensive attack that makes some of the machines break down then your imaginary life-supporting systems will go down right there, today, in 5 minutes, or tomorrow afternoon.
Nonsense.
Oh my, do you honestly believe that the heart-lung machine at your hospital is connected to the internet? Or that your nuclear power plant is running on Windows XP? Let me assure you: They are not. And if someone in the world truly misdesigned a critical system in a way that could be affected by a windows worm then we'd better be grateful for the learning expirience that they'll inevitably get (with or without a counter-worm). Or would you really want them to get away with that? Do you really think it'd be good idea to let them get into the habit of building critical stuff upon "cheap" Microsoft infrastructure?
Even if your nonsensical assumptions were correct: I'd still much prefer to have one powerplant melt down today due to a counter-worm than to have hundreds of powerplants running on vulnerable systems in 30 years because hey, "nothing ever happened".
Fake. Google never looked like that.
Well, at a market cap of 100 billions I think this should rather read: Google doesn't want to help you with that. :P
Nonsense. If the counter-worm manages to interfere with machines or networks that are not infected by the original worm then these machines and networks were not properly secured and/or isolated in first place. Their admins should be glad that the counter-worm sheds light on the flaws before a malicious operator of the original worm does.
Nonsense. The heart-lung machine in your hospital does not run windows. The telco systems that dispatch your emergency calls do not run windows. If there are any truly critical systems out there vulnerable to a worm then we'd better find out about that sooner than later. What's the difference between a counter-worm breaking them today versus a "regular" worm breaking them tomorrow?
Your post is not unlike the difference between, say, a clueless person using inappropiate analogies, and the proof that car analogies hardly ever make any sense.
Seriously, all this crap is blown way out of proportion. Firetrucks. Car-Bombs. My ass...
If they have a tool to eliminate a large botnet then, by all means, do it. Stop crying for attention in the press, just run the damn counter-worm or release the source-code so the scriptkiddies can fragment the worm into insignificance.
If that wipes out the worm: Great!
If that bricks all infected machines: Well, still better than what we had before.
There's no need to worry about collateral damage. Critical, life-supporting systems are not participating in storm. The worst that can happen is that a lot of computer illiterate people will have a "broken PC" over night and will have to ask their "PC guy" to fix it. This is a "risk" that we should be willing to take...
Interesting view of the "backbone"-problematic and I can second some of the restructuring problems, as I'm also from germany. :-)
I generally agree with your backbone-view, but as I described in my reply to turbidostato I don't think that this is a sustainable strategy.
I have seen the same effects that you describe in many companies but imho those of them that survived only survived because everyone else in their market is *also* working in the same failure-mode. It's nearly impossible to gain or sustain any momententum when you work in this "lazy backbone"-mode.
That is okay as long as nobody else has any momentum either. But "unfortunately", especially in the web-business, we see these young, unconventional startups pop up left and right. I guess quite a few CEOs cry a lot these days because they must watch how their cake is eaten by a bunch of university-dropouts who simply get shit done without wasting so much time on playing "real company".
You say that as if it's a good thing or an unchangeable fact of life. Having worked with my share of mediocre teams I can't disagree more. Mediocrity may work out in other departments and a few subsections of IT as long as there's a strong puppetmaster pulling the strings. But I don't believe in the common "100 codemonkeys will hammer out a shakespare" notion.
A coder who can't properly handle a daily SCM workflow or who even deliberately screws it up to slack off will hurt productivity, no matter how you spin it. Anyone who tolerates such people on their team either has no clue (the common failure-mode in smaller corps) and/or just doesn't care (the common failure-mode in large corps where managers spend most of their time fighting over budgets and bonuses).
It's no secret anymore that the difference in productivity between a great coder and a mediocre coder is measured in orders of magnitude. I have witnessed teams of 3 outpace teams of 30 more than once and you probably have, too.
Moreover, if you look at the hiring strategies of the big guys you'll notice that they tend to agree with me here.
Google, Yahoo, Microsoft, Oracle and others are all said to aim for top-notch only. Ofcourse you can seldomly assemble teams of *only* Einsteins, simply because not so many Einsteins are available. But the idea is to have Einsteins in all critical positions, partly because that's also a natural protection against slackers like the one described by grandparent.
If that's your premise then you're dead in the water anyways. I have a better idea: Why don't you just fire the incompetent slacker instead of slowing down the rest of your team?
Sorry to burst your bubble but most software projects do involve artwork and it makes a lot of sense to version that, too - along with the source code.
Do you think artists never make mistakes? Do you think nobody ever wants to go back to an older version of a button-image after a while because the new one wasn't received well?
Well if so then let me welcome you to the real world.
Whippersnappers indeed.
You're thinking of the Amiga. A1000, A2000/A500, A3000, A500+/A600, A1200/A4000.
Well, this FAQ entry was admittedly a bit sloppy and dismissed the issue without really explaining.
To clarify and correct it:
Yes, you can change your password. The technical implementation for such a password change would be a bit more involved than it is today but it could definately be wrapped up into a simple "change password" dialog, displayed and executed by the browser.
I initially answered this with a "No" because I don't think your use-cases are truly relevant but after thinking about it more: Yes, users will demand the functionality (if only out of irrational habit) and yes, it can be done.
If you had read my other follow up posts you'd realize that this is not about cookies.
Admittedly my usage of the term "session" was misleading, though. I meant to say: At the beginning of the browser-session, i.e. when you start the browser.
Ha! That's interesting, didn't know about it (maybe because I'm never using excel).
Makes you wonder how many corporations and individuals have based their decisions on miscalculated data...
Generally no, your browser doesn't need to follow you - all browsers would just need to implement the same HTTP protocol extension and credential hashing.
Furthermore I don't think that any kind of common ID should be used for truly critical sites such as online-banking.
I'll be the first to argue that a separate password for your online-banking is mandatory, plus a TAN system (one time passwords) for each transaction.
What we're talking about here is not to combine your current 173 passwords into one.
We're talking about combining your current 173 passwords into three or four. One for your "master" identity, one for your "on the road" identity (of which you could have any number, if you feel so inclined) and one each for your online-banking and other truly critical sites.
Well, see my other post for a more detailed description.
Well, imho OpenID is broken by design. I give them credit for "making the best of existing infrastrucutre" but, as the low adoption shows, this is unfortunately not good enough. OpenID is cumbersome, incomplete and just screams "i'm a nasty hack" into everyone's face. The sad truth is that even if it was properly executed (sane APIs etc.) it would still not gain significant traction because the basic premise of exporting your identity to a remote party is flawed.
Anyways, see my other post for more details on the utopy that I have in mind.
Neither. I'm talking about an implementation similar to these two but optimized for the browser use-case.
You are ofcourse right, the technology exists, in theory. But it's nowhere near usable because no one has bothered to put the pieces together.
Usable would be:
This all is technically feasible today. The only hard case in the resulting system would be the "Lost / stolen password" case.
Fortunately there is a fairly simple solution to this:
FAQ:
Easy. Force a reasonable minimum length on username and password. I'd suggest 5 chars for the username, 20 for the password.
Idiots will always be idiots. Choose a half-sane password and your identity will be secure.
No. Why would you want to?
No. The browser creates a unique token for each website you visit from your username, password and the websites domain name (e.g. "slashdot.org").
The token generation could be as simple as MD5( username | password | domain ) - in reality we'd probably use HMAC.
A website owner can not use your token to authenticate to other websites and it cannot generate tokens for other websites from the token he sees.
Now this would be an interesting application for P2P technology. We don't want a single entity to control these things, so distribute it. The detailed spec for such a system is too long for a slashdot post - but in the end it's just a matter of actually implementing it, no really hard or "unsolvable" problems involved here.
I considered it, really. But writing Fx addons is painful, to say the least. And even if it magically made it into the public build that would still only cover 30% of all web traffic. Not nearly enough to gain momentum in itself and a pipe dream anyways, as the moz guys would never support a proprietary extension like that.
The only realistic way to establish such a thing in the long-term would be as part of the HTTP standard, when was HTTP/1.2 scheduled again?
Well, I can offer the obvious solution.
Put authentication in the browser. Oh my god, what a novel idea!
Have the user enter his password once, at the beginning of the session, and create a unique token for each site from that.
Submit that token along with every request, in a HTTP-header.
No login required ever. Sites can distinguish users by their tokens (even when they're not "logged in") and a registration merely consists of connecting a token to whatever metadata (a username, address, whatever the user wants to give out to a particular site).
Paranoid users could choose to suppress the token by default and only start submitting it when they hit the "Login" button on their browser chrome - without typing in a username or password ever.
Better yet, add a bit of cryptographic trickery and these tokens can easily be revokable, updateable etc. for the cases where a password is stolen or "lost". And ofcourse browsers could easily store multiple "identities" and provide a dropdown to switch between them on the fly.
It's not rocket science, really. The whole system could be designed and spec'ed out over a weekend and would work better than anything that we had before. No third parties involved and everybody (even the data collectors) happy.
Problem? Oh, right. Getting it into the mainstream browsers... Well, give it another 20 years.
Sneak preview, Tomorrow's headlines on slashdot:
* Ten good reasons to pull down your pants before taking a dump
* Ask Slashdot: I keep forgetting things, anyone know a good way to not forget things?
* How to manage your data, ten good recommendations for folder names
* Ask Slashdot: What size harddrive should I buy?
zzZz
The reason is that otherwise hardly anyone would ever start a company - other than people who already own truckloads of money.
Let's say you have this really great idea for a word processor software. You can build it and bring it to market, no problem. But you know that MS will probably sue you and you can't be sure about the outcome of that. With limited liability you at least know that the worst that can happen is that your company goes out of business and you wasted a few years of your life.
Without limited liability on the other hand... Well, good luck paying off those seven digit "virtual damages" that some court may bill you for.