You missed the origanizational resiliency piece (which I probably wasn't clear on). Smaller companies tend to be more influenced by individuals (talents, changes, problems) and don't have the depth to be able to handle major changes in staff. Lose 20 people in a 5000 person company, and your product will probably look exactly the same. Lose 20 people in a 100 person company, and there's a much higher likelyhood that things will change. You also run into lack of backup support, ability to handle geographically disperse customers as well, etc.
It's not that there aren't many exceptions, just that mass goes a long way in mitigating those issues.
That doesn't work for most machines you'll find on the internet. Network data simply doesn't contain enough information to concistently build a flexible, accurate profile of normal usage. You're either going to miss a significant amount of stuff youd like to catch, or catch so much legit traffic that it's unusable. You might find the right middle ground between them, but it'll be infrequent and coincidental.
The ability to block things by numer/frequency/type/foo of connection attempts is pretty old...it's just not particularly useful in cases as open-ended as this (trying to block worm activity based on no other information than connection behavior). It seems someone here is, as usual, reporting on the rediscovery of the wheel.
(Not to mention the fact that the fast moving DoS worm is out of fashion right now. The heat is too much for people looking for kicks and people looking to make money from it have better tools.)
Because what happens over there affects you, me, and the future of our respective countries. A government's mandate is to protect the interests of its people. Therefore, the US is over there doing what the present incarnation of its government believes is protecting its interests. Whether or not you agree the US is doing a good job of protecting its interests, whether it caused the problem in the first place, should legally be allowed to be there, whatever...it's hard to argue that the futures of the US and most of the rest of the world (from economic and military perspectives) are not completely intertwined with what happens there.
Whether it's a good idea for the US to be there is arguable. Their reasons for being there, though, are crystal clear.
Yeah, smaller companies distribute and process information more effectively, so they are almost always better suited to developing new things than the government or the large contractors. However, producing old things repeatably to the same spec and with organizational resiliancy is something smaller companies have a harder time doing, so from a long term perspective it's not a clear win for smaller companies.
The only time the government really beats out private industry (and to a greater extent, larger orgs beat out smaller ones) on new technology innovation is when it's a money issue (the materials really do cost billions of dollars). As technology has gotten cheaper and become more accessible, that advantage has slowly disappeared.
A larger issue than size, though, is that governments (most of them, this one in particular) tend to recruit homogenous workforces and encourage groupthink. Workers are encouraged (directly or through lack of promotions, harassment, etc.) to "fit in" at an institutional level. So, it's not surprising that the government is not as innovative as other places.
People lately are often heard saying that the US government doesn't "pay enough" to get good people. I dont know about you all, but I'd give up a little pay to work on interesting projects and with good people. The government's problem is that it doesn't -like- people who are creative, innovative, and different and actively selects them out - not the pay.
...but...if Apple's remotely like most other big companies...that means they also than need a few weeks or months to assure (with See Jane Run style powerpoints) the middle management that they're not losing any of their rice bowls, whiffle ball bat the DRM-opt-out concept into the heads of the sales and marketing teams, and then crowbar the code into the release cycle thats already been planned out months ahead.
In a country like the US, if you feel like you're losing a freedom or choice, it's not the product. It's not the company. It's not your legislator. It's not the president. It's citizen/user apathy. We get what we ask for. Unfortunately, most people don't ask for much...
Total Cost of Intrusion: Some monetary value, largely intangible
Chance of Intrusion: Impossible to model realistically
Cost of Security Measures: Ok, yeah, you can figure this one out in numbers.
If someone wants a formal real ROI on security, they won't get one. It doesn't work unless you make up numbers that you absolutely cannot know. This equation should only be used for marketing and illustration purposes. It's not useful for real ROI purposes.
You can't measure the probability of something getting broken into. There are a million ways to calculate it and all of them come down to making up a number in your head. Realistically, "vulnerability" (ie, probability of getting hacked) is a null value. Ignore it. Weight your data, whether it can be replaced, the cost to the business if it's compromised (unauth disclosure, corruption of the data, or denial of access). Then threat model how you could do any of those things to your most valuable data and where, your next most valuable data class, etc....mitigate from there.
Also calculate reputation value. A really outstanding good ROI for security has nothing to do with numbers: It's called "I didnt end up on CNN or Slashdot today".
If you don't like what you're charged from an ISP or a content provider, don't pay it and go somehere else.
The problem is that you're in one location and, even if you have isp choices, you certainly dont have many. That's why market forces are of questionable importance here. The ISP's, in theory, will use the fact that you -can't- switch (or will only have one or two other options) to wedge themselves into the equation. If you could just drive down to another ISP, it would be different - they'd have to compete. Instead, since they can by and large dictate what is allowed to go over their lines on a content basis in order to make money, why wouldn't they? That location lock-in is why net neutrality is needed.
Re:The right to privacy is underrated
on
The Privacy Candidate
·
· Score: 5, Insightful
The right to privacy goes hand in hand with the right to free speech and, as such, is one of the rights that must absolutely be kept healthy to sustain our country. Without it, the rest falls apart. So yes, the right to privacy is one of thekey issues for me when considering candidates.
Ah. That's cool. I just went with an LG CU500...it's the first Cingular phone in the US to be able to get on Cingular's HSDPA network. It takes a lot of its design cues from the RAZR..
I've never purchased any Apple equipment (although Ive been given an ipod), I tend to prefer non-Apple computers for various reasons, so it's certainly not fanboyism. Secondly, if it works half as well as demo'd, it's a vast improvement over current cell phones from an interface perspective. Thirdly, if it uses OSX I have no reason to doubt the features have been integrated well due to the fact that I have a reasonable (as does everyone else) understanding of how that OS tends to deal with integration of applications. Fourth, it doesn't take someone shoving something in my hand to recognize a good idea. Fifth, if we really DO have to have it in our hands to intelligently discuss it, this whole thread is BS as well. Sixth, I pointed out RAZR as an example of other, non-feature-related properties having an affect on how well a device does in the market despite other shortcomings (see title of original post: iPhone Faces Uncertain Market). Seventh, tactile feedback is not needed if the interface is reasonably accurate, responsive, and predictable and the market has shown it's really not a big issue anyway. Eighth, the interface integration through the touchscreen doesnt help texting itself, it helps the specificity of the controls on screen at any given time so you dont rely on one key doing 4 different things in different contexts which, from a useability standpoint, tends to be the better option. Ninth, why are you limiting the context to texting so much - have you considered that maybe people rely on texting so much because doing more than that on existing devices is a pain in the ass?
I could go on...it either way...good product or not...you seem to have a pretty emotional response to it, so it must be doing something right. That kind of emotional kick is what'll make it succeed in the market if nothing else;)
The whole QWERTY argument is bunk. RAZR's have a very very similar problem (very little touch-sense of what key youre pressing) and still are exceedingly popular. The crappy keys there didn't limit them at all.
The rest your post misses the point. Every single one of your complaints is just technical evolution. They'll happen - for the iphone and every other device. The new new in the iphone is HOW it does the integration and it's approach to the interfact useability, not that nothing else does this feature or that or that they dont do specific aspects better. The fact is, there is no single device out there (except this) that has integrated the features (all of them) together in any remotely useable/intelligent way.The rest is just product roadmap crap that'll happen.
A resilient system in this context just means it can deliver more spam. The issue isn't that spam is causing mail systems to collapse, it's that people are collapsing - and they're generally collapsing before the IT systems do. Resilient systems don't help with that.
Go back before Ipods. Go back to the mid 90's or earlier. This is the same conversation as "Why do I need a GUI? It just makes things slow and expensive. I can do everything by commandline and do it faster! Geeze. Whoever would get a GUI based OS? morons."
Why use a Wordprocessor instead of a pen and paper? The pen and paper have much better resolution. Really, I just want something to put my thoughts down with.
"It's the interface, stupid" not the features.
And you can never trust security attributes coming from the client.
Yeah, hence the RFID/external verification comments. Any conversation that has the word "trust" and "network" in it will ultimately get down to that. Anything self-contained can be subverted. The two (external identify key and semantic policy descriptions inherent to data objects) go hand in hand.
What we need is resilient systems, which can be attacked, but not collapse under load.
I don't know. I'd rather have my data fail closed than be stolen or otherwise abused. A resilient mail system (to bring it back to SPAM) would just be able to send/receive that much more spam.
Actually, we're almost completely in agreement. Even if you rebaseline your understanding of the project (and what's important to build first) weekly (Ive done it daily for some things), you're still planning before you code and making sure you completely understand your requirements before you code. The two go (as you rightly point out) hand in hand.
The only thing that I think really needs to be done up front that is much much harder to change in the middle of the project is the basic operating architecture of your project. In many cases, that's going to be the messaging bus and other similar components. Hell, most (??? my experience, don't know if that's fact) complex projects don't even have a robust messaging/services layer architected in at all. If you do that right up front, it makes making changes, adding new features, and scaling the project much easier down the road.
If you don't have that at all, your project will be much more painful.
I see more projects go bad because of poor communication and lack of architectural efforts than anything else.
A sufficiently detailed question needs no answer. Likewise, with software development (and really most computer systems development), everyone wants to rush out and start coding as fast as possible...but if they'd made sure there were no assumptions, defined their problem specifically, and spent way more time than they wanted to developing an architecture, the coding afterwards would just be data entry for the most part.
But...people tend to be averse to taking the up-front costs of not only gathering their requirements, but also -understanding them- and making them -fit together-. Frameworks and Architectures tend to be poorly developed and understood ahead of time. Features are developed in isolation from each other. Test cases need to be developed at every step to keep people in agreement and to make find issues early. If your project isn't working in a manner where every new addition to it can't be tested as it's written, you're doing something wrong.
Requirements need to be reviewed and revised and reviewed and revised constantly with all staekholders against those test cases.
But...maybe I'm off base.
Good question. If we don't limit ourselves to money and the poorest 90% of the world (said in jest, but in reality I'm guessing those 90% dont have access or machines...) then I'd honestly say RFID (or equiv). Not something that contains your identity per se, but at least a remote "key" to your online identity tokens. If you're not close by, things aren't done in your name (unless theyve previously been signed by the same means and are scheduled). Biometrics would work as well, but I like the data of authorization not being stored on the machine...prefer the constant reverification with RFID.
I can't (and not sure anyone can) get away from the reality that if it's a system self-contained within the computer/network, someone can shove something between you and the auth mech.
Even so, then we get into broader computer security issues that will really take a complete reworking of how computers are internetworked to solve. Namely the fact that we can't semantically descibe our intent in security policy...so any walls/mitigations we put up tend to be static. Without all data objects having self-contained security attributes which require legitimate participating systems for access and a real semantic security policy taking advantage of those attributes, pretty much any data on the network can be intercepted, altered, or denied somehow.
No one issues them. Everyone issues them. It doesn't matter at this point because we don't even have a universally recognized container/object for them. If we did, it still wouldn't (hypothetically) matter in some potential scenarios. For example, you could allow end-user and ISP and ____ level tagging of the credentialing source in addition to the crdentials themselves. If you consistently allow spammers to be authenticated, you'll end up with a low trust level and people will be less likely to trust your users. (Obviously, this would probably also be done at a user level as well, but I'm not sure that piece would be as valuable.) Different credentialing services could figure out their own methods for authentication.
This sounds a lot like IP lists, except it splits the trust away from an object tied to location and machine it ties it more closely with who is sending. And it takes it out of the -transport- protocols altogether.
And this conversation, with all of the problems with the scenario I've just described, is still (to me) far more productive than one focusing on "should we use THIS service that won't ever fix the problem or THAT service that won't ever fix the problem".
Slashdot Mirror
You missed the origanizational resiliency piece (which I probably wasn't clear on). Smaller companies tend to be more influenced by individuals (talents, changes, problems) and don't have the depth to be able to handle major changes in staff. Lose 20 people in a 5000 person company, and your product will probably look exactly the same. Lose 20 people in a 100 person company, and there's a much higher likelyhood that things will change. You also run into lack of backup support, ability to handle geographically disperse customers as well, etc. It's not that there aren't many exceptions, just that mass goes a long way in mitigating those issues.
That doesn't work for most machines you'll find on the internet. Network data simply doesn't contain enough information to concistently build a flexible, accurate profile of normal usage. You're either going to miss a significant amount of stuff youd like to catch, or catch so much legit traffic that it's unusable. You might find the right middle ground between them, but it'll be infrequent and coincidental.
The ability to block things by numer/frequency/type/foo of connection attempts is pretty old...it's just not particularly useful in cases as open-ended as this (trying to block worm activity based on no other information than connection behavior). It seems someone here is, as usual, reporting on the rediscovery of the wheel. (Not to mention the fact that the fast moving DoS worm is out of fashion right now. The heat is too much for people looking for kicks and people looking to make money from it have better tools.)
What a well thought out, intelligent response. You've convinced me!!
Because what happens over there affects you, me, and the future of our respective countries. A government's mandate is to protect the interests of its people. Therefore, the US is over there doing what the present incarnation of its government believes is protecting its interests. Whether or not you agree the US is doing a good job of protecting its interests, whether it caused the problem in the first place, should legally be allowed to be there, whatever...it's hard to argue that the futures of the US and most of the rest of the world (from economic and military perspectives) are not completely intertwined with what happens there.
Whether it's a good idea for the US to be there is arguable. Their reasons for being there, though, are crystal clear.
Yeah, smaller companies distribute and process information more effectively, so they are almost always better suited to developing new things than the government or the large contractors. However, producing old things repeatably to the same spec and with organizational resiliancy is something smaller companies have a harder time doing, so from a long term perspective it's not a clear win for smaller companies.
The only time the government really beats out private industry (and to a greater extent, larger orgs beat out smaller ones) on new technology innovation is when it's a money issue (the materials really do cost billions of dollars). As technology has gotten cheaper and become more accessible, that advantage has slowly disappeared.
A larger issue than size, though, is that governments (most of them, this one in particular) tend to recruit homogenous workforces and encourage groupthink. Workers are encouraged (directly or through lack of promotions, harassment, etc.) to "fit in" at an institutional level. So, it's not surprising that the government is not as innovative as other places.
People lately are often heard saying that the US government doesn't "pay enough" to get good people. I dont know about you all, but I'd give up a little pay to work on interesting projects and with good people. The government's problem is that it doesn't -like- people who are creative, innovative, and different and actively selects them out - not the pay.
...but...if Apple's remotely like most other big companies...that means they also than need a few weeks or months to assure (with See Jane Run style powerpoints) the middle management that they're not losing any of their rice bowls, whiffle ball bat the DRM-opt-out concept into the heads of the sales and marketing teams, and then crowbar the code into the release cycle thats already been planned out months ahead.
In a country like the US, if you feel like you're losing a freedom or choice, it's not the product. It's not the company. It's not your legislator. It's not the president. It's citizen/user apathy. We get what we ask for. Unfortunately, most people don't ask for much...
Total Cost of Intrusion: Some monetary value, largely intangible Chance of Intrusion: Impossible to model realistically Cost of Security Measures: Ok, yeah, you can figure this one out in numbers. If someone wants a formal real ROI on security, they won't get one. It doesn't work unless you make up numbers that you absolutely cannot know. This equation should only be used for marketing and illustration purposes. It's not useful for real ROI purposes.
You can't measure the probability of something getting broken into. There are a million ways to calculate it and all of them come down to making up a number in your head. Realistically, "vulnerability" (ie, probability of getting hacked) is a null value. Ignore it. Weight your data, whether it can be replaced, the cost to the business if it's compromised (unauth disclosure, corruption of the data, or denial of access). Then threat model how you could do any of those things to your most valuable data and where, your next most valuable data class, etc....mitigate from there. Also calculate reputation value. A really outstanding good ROI for security has nothing to do with numbers: It's called "I didnt end up on CNN or Slashdot today".
If you don't like what you're charged from an ISP or a content provider, don't pay it and go somehere else. The problem is that you're in one location and, even if you have isp choices, you certainly dont have many. That's why market forces are of questionable importance here. The ISP's, in theory, will use the fact that you -can't- switch (or will only have one or two other options) to wedge themselves into the equation. If you could just drive down to another ISP, it would be different - they'd have to compete. Instead, since they can by and large dictate what is allowed to go over their lines on a content basis in order to make money, why wouldn't they? That location lock-in is why net neutrality is needed.
The right to privacy goes hand in hand with the right to free speech and, as such, is one of the rights that must absolutely be kept healthy to sustain our country. Without it, the rest falls apart. So yes, the right to privacy is one of thekey issues for me when considering candidates.
Ah. That's cool. I just went with an LG CU500...it's the first Cingular phone in the US to be able to get on Cingular's HSDPA network. It takes a lot of its design cues from the RAZR..
Of? Simply commenting from the perspective of someone who's had to do a boatload of useability and data representation work, shrug.
I've never purchased any Apple equipment (although Ive been given an ipod), I tend to prefer non-Apple computers for various reasons, so it's certainly not fanboyism. Secondly, if it works half as well as demo'd, it's a vast improvement over current cell phones from an interface perspective. Thirdly, if it uses OSX I have no reason to doubt the features have been integrated well due to the fact that I have a reasonable (as does everyone else) understanding of how that OS tends to deal with integration of applications. Fourth, it doesn't take someone shoving something in my hand to recognize a good idea. Fifth, if we really DO have to have it in our hands to intelligently discuss it, this whole thread is BS as well. Sixth, I pointed out RAZR as an example of other, non-feature-related properties having an affect on how well a device does in the market despite other shortcomings (see title of original post: iPhone Faces Uncertain Market). Seventh, tactile feedback is not needed if the interface is reasonably accurate, responsive, and predictable and the market has shown it's really not a big issue anyway. Eighth, the interface integration through the touchscreen doesnt help texting itself, it helps the specificity of the controls on screen at any given time so you dont rely on one key doing 4 different things in different contexts which, from a useability standpoint, tends to be the better option. Ninth, why are you limiting the context to texting so much - have you considered that maybe people rely on texting so much because doing more than that on existing devices is a pain in the ass? I could go on...it either way...good product or not...you seem to have a pretty emotional response to it, so it must be doing something right. That kind of emotional kick is what'll make it succeed in the market if nothing else ;)
The whole QWERTY argument is bunk. RAZR's have a very very similar problem (very little touch-sense of what key youre pressing) and still are exceedingly popular. The crappy keys there didn't limit them at all. The rest your post misses the point. Every single one of your complaints is just technical evolution. They'll happen - for the iphone and every other device. The new new in the iphone is HOW it does the integration and it's approach to the interfact useability, not that nothing else does this feature or that or that they dont do specific aspects better. The fact is, there is no single device out there (except this) that has integrated the features (all of them) together in any remotely useable/intelligent way.The rest is just product roadmap crap that'll happen.
A resilient system in this context just means it can deliver more spam. The issue isn't that spam is causing mail systems to collapse, it's that people are collapsing - and they're generally collapsing before the IT systems do. Resilient systems don't help with that.
Junk like this is why the iPhone will sell: (just one example) http://www.baddesigns.com/cell-phone.html
Go back before Ipods. Go back to the mid 90's or earlier. This is the same conversation as "Why do I need a GUI? It just makes things slow and expensive. I can do everything by commandline and do it faster! Geeze. Whoever would get a GUI based OS? morons."
Why use a Wordprocessor instead of a pen and paper? The pen and paper have much better resolution. Really, I just want something to put my thoughts down with. "It's the interface, stupid" not the features.
Actually, we're almost completely in agreement. Even if you rebaseline your understanding of the project (and what's important to build first) weekly (Ive done it daily for some things), you're still planning before you code and making sure you completely understand your requirements before you code. The two go (as you rightly point out) hand in hand.
The only thing that I think really needs to be done up front that is much much harder to change in the middle of the project is the basic operating architecture of your project. In many cases, that's going to be the messaging bus and other similar components. Hell, most (??? my experience, don't know if that's fact) complex projects don't even have a robust messaging/services layer architected in at all. If you do that right up front, it makes making changes, adding new features, and scaling the project much easier down the road.
If you don't have that at all, your project will be much more painful.
I see more projects go bad because of poor communication and lack of architectural efforts than anything else.
A sufficiently detailed question needs no answer. Likewise, with software development (and really most computer systems development), everyone wants to rush out and start coding as fast as possible...but if they'd made sure there were no assumptions, defined their problem specifically, and spent way more time than they wanted to developing an architecture, the coding afterwards would just be data entry for the most part.
But...people tend to be averse to taking the up-front costs of not only gathering their requirements, but also -understanding them- and making them -fit together-. Frameworks and Architectures tend to be poorly developed and understood ahead of time. Features are developed in isolation from each other. Test cases need to be developed at every step to keep people in agreement and to make find issues early. If your project isn't working in a manner where every new addition to it can't be tested as it's written, you're doing something wrong.
Requirements need to be reviewed and revised and reviewed and revised constantly with all staekholders against those test cases.
But...maybe I'm off base.
Good question. If we don't limit ourselves to money and the poorest 90% of the world (said in jest, but in reality I'm guessing those 90% dont have access or machines...) then I'd honestly say RFID (or equiv). Not something that contains your identity per se, but at least a remote "key" to your online identity tokens. If you're not close by, things aren't done in your name (unless theyve previously been signed by the same means and are scheduled). Biometrics would work as well, but I like the data of authorization not being stored on the machine...prefer the constant reverification with RFID. I can't (and not sure anyone can) get away from the reality that if it's a system self-contained within the computer/network, someone can shove something between you and the auth mech. Even so, then we get into broader computer security issues that will really take a complete reworking of how computers are internetworked to solve. Namely the fact that we can't semantically descibe our intent in security policy...so any walls/mitigations we put up tend to be static. Without all data objects having self-contained security attributes which require legitimate participating systems for access and a real semantic security policy taking advantage of those attributes, pretty much any data on the network can be intercepted, altered, or denied somehow.
No one issues them. Everyone issues them. It doesn't matter at this point because we don't even have a universally recognized container/object for them. If we did, it still wouldn't (hypothetically) matter in some potential scenarios. For example, you could allow end-user and ISP and ____ level tagging of the credentialing source in addition to the crdentials themselves. If you consistently allow spammers to be authenticated, you'll end up with a low trust level and people will be less likely to trust your users. (Obviously, this would probably also be done at a user level as well, but I'm not sure that piece would be as valuable.) Different credentialing services could figure out their own methods for authentication.
This sounds a lot like IP lists, except it splits the trust away from an object tied to location and machine it ties it more closely with who is sending. And it takes it out of the -transport- protocols altogether.
And this conversation, with all of the problems with the scenario I've just described, is still (to me) far more productive than one focusing on "should we use THIS service that won't ever fix the problem or THAT service that won't ever fix the problem".