hawkett said: <slight political rant (IMO)> A good example is the recent financial crisis. The banking sector took risks, understanding that the worst possible outcome (for them) was not actually as bad as is being portrayed - they felt that they would still not fail because they commanded enough political power to rely on federal funds. So what seemed incredibly risky behaviour by the banks, was, in fact, not all that risky - because they had shored up their political power to mitigate their risk. Consequently, the worst that could possibly happen with all the risks the banks took was that they would be fine. And largely, they are fine. Good risk management they would say - it wasn't all that risky. Not for them. Incredibly risky for the taxpayer, but that risk wasn't their concern - at least not from their perspective. You can be sure that it was a possibility they were aware of. The nation(s), however, totally lost a handle on their risk management - the banks should never have been allowed to reach a position where they could mitigate their risk with federal funds - essentially the risk was transferred to the tax payer. If they were unable to do that, then they wouldn't have taken the risks in the first place, because they could not have answered 'yes' to the last question. It is difficult to see how the nation(s) could have avoided this problem though - the stakeholders (the citizens) have very limited means by which to limit the subversion of power from within their political process - most of these powerful people within government are not elected. </slight political rant (IMO)>
I have started this work in 1994 a lot before the last crisis. Yes they solved that one for reason I won't explain here. If I worked for 15 years on that system it is because I knew that ultimately there would be no way to save the system. There are mathematical limits to the extent to which such a crisis can be solved and that no matter how much liquidity you put in. This is why, we economists, call it a Liquidity Trap. The Fed is well aware of that just Google: " 'Liquidity Trap' 'Zero Lower Limit' Site:federalreserve.gov" On 25 May 2010 00:40, Keren Or Shalom <v07768198...@gmail.com> wrote: > hawkett: > > 2. You need to do some risk assessment. There are always risks, and > many of them - there is no perfectly secure system, and it is > important not to try and sell such a thing. It is just a matter of how > you rate each risk, and important that the stakeholders understand the > risk and agree to it - the last thing you want to have is a > conversation where someone says 'You told me it was secure!!!'. It > can't be secure unless it is truly inaccessible to everything and > everyone, and you can't build a system around that :). Risk assessment > is generally subjective - what is the chance of someone obtaining a > password they shouldn't? What is the chance of the cloud vendor > exposing data? What is the chance that your code contains bugs? What > is the chance of the cloud vendor losing your data entirely - > > http://gigaom.com/2009/10/10/when-cloud-fails-t-mobile-microsoft-lose-sidekick-customer-data/ > ? > > The list goes on. If you build a system where there is perceived value > in subverting it, then it will probably be subverted. It is much > better to cope with it than try to prevent it (you can't prevent it). > What you need to prevent against is the possibility that any > particular problem or combination of problems results in total > failure. > > > I am not worried if a few thousand of password or account were broken into > we can insure that. > The problem is a system wide breach like the provider exposing or > destroying data. > This is the subject we are dealing with. I don't believe in fixing a bad > solution I believe in designing a good system > then implementing it. If people use that system and it fails no one will be > willing to listen to my excuses. > > You are asking me questions you never asked your banks: why do you hold me > to a higher standard than your banks. > > On 25 May 2010 00:34, Keren Or Shalom <v07768198...@gmail.com> wrote: > >> hawkett: >> >> 1. The cloud is *much* cheaper than any custom hardware installation >> you can come up with. Security isn't just data security - you need to >> manage backups, uptime, support, maintenance, facilities, redundancy, >> disaster recovery - long list of stuff that will cost you buckets >> before you even get started. >> >> >> You are right but I am not more in a hurry than anyone else and after the >> crash the number of cheap idle resources available will be tremendous. I am >> a very patient man I have waited for that for 15 years I bet you $1 that the >> owners of these resources have more money than I but a lot less patience. >> >> On 25 May 2010 00:29, Keren Or Shalom <v07768198...@gmail.com> wrote: >> >>> hawkett said: >>> >>> When you say credit free currency, do you mean credit free society? >>> How do you plan to make it credit free - through legislation? What's >>> to stop me lending some currency I have in your system to someone - or >>> making a purchase on their behalf in exchange for a purchase by them >>> of something more valuable at a later date? That scenario is >>> essentially an interest bearing loan. The system and those that use >>> it exist in a symbiosis - you can't change one without addressing the >>> other - it's hard to see how you will create a credit free society >>> without addressing the psychology of the people within that economy - >>> people need to *want* to avoid credit, and when you haven't got much, >>> and others seem to have so much, credit is an insidiously attractive >>> proposition - it's easy to market and sell. You'll probably need to >>> address the gulf between rich and poor, and marketing of impossible, >>> unaffordable goals to remove credit from society - perhaps you feel >>> that economic collapse will do that. Does your plan deal effectively >>> with the reality of the flawed, selfish human being? I guess I'm >>> asking about your second point - is it based on a global societal >>> enlightenment occurring due to the economic collapse? >>> >>> >>> I am an economist not a dreamer: a credit is a contract. The willingness >>> to sign it is based on the belief that it will be enforced. >>> If there is no enforcement of such a contract I bet you $1 that no body >>> will do enter that kind of contract. Moreover I don't have to explain how >>> data mining can help spot a transaction that is not a regular economic >>> transaction but a credit. >>> >>> On 25 May 2010 00:25, Keren Or Shalom <v07768198...@gmail.com> wrote: >>> >>>> Please make your remarks shorts and focussed: >>>> >>>> I will answer to all I have received but break them down to something we >>>> can digest: >>>> >>>> hawkett said >>>> >>>> >>>> A small issue if the economy goes down the drain on the scale you are >>>> talking about is that an internet where everyone has the capability to >>>> connect to a cloud system is going to be difficult to maintain. It's >>>> not going to be easy for google to make money, for individuals to pay >>>> their internet bills, for internet companies to continue to deliver >>>> access - indeed you may find it difficult for yourself to make money >>>> or pay for the developers you are proposing to hire. What value will >>>> money have? How will google pay its employees to continue to deliver >>>> app engine - ad revenues are going to plummet. I think if your system >>>> is anticipating the total collapse of the economy, then you may find >>>> it difficult to deliver your system to what remains. >>>> >>>> >>>> It all depends on how much my system can create demand: you are reacting >>>> just as if the previous system didn't existed and we stayed in a vacuum. My >>>> system is designed to feel the vacuum. >>>> >>>> >>>> On 24 May 2010 16:08, hawkett <hawk...@gmail.com> wrote: >>>> >>>>> @gops this style of system is the holy grail of distributed systems, >>>>> however the model you have suggested perhaps suffers from lack of >>>>> redundancy. If only you have your data (or some of your data), and >>>>> only you have access to it, then failure at that point represents >>>>> total loss. The solution is a network of trust and redundant copies of >>>>> your data and multiple people with the capacity to access it. The >>>>> biggest problem we have with this solution is bandwidth and network >>>>> latency. Keeping copies of data in different locations is expensive >>>>> on both those fronts - especially if you want decent consistency, and >>>>> especially between your computer and my computer. Another problem is >>>>> that if publicly available data on your node is popular - then you >>>>> need massive resources to be able to meet that demand - as you noted, >>>>> a problem is the need for you to maintain your node. Perhaps the data >>>>> distribution you mention is intended to solve these problems. >>>>> >>>>> For many classes of application, the cloud is actually the best we can >>>>> do at the moment with the state of technology. Companies like google, >>>>> amazon etc. *do* distribute data like this. However to solve the >>>>> bandwidth and latency issues that come with the need for good >>>>> consistency, they need to manage the clusters. I expect that one of >>>>> the major reasons google is pushing hard for better bandwidth and >>>>> lower latency for everyone is to expand the possibilities for this >>>>> type of architecture. It won't be too long before our web browser is >>>>> also a web server. I don't doubt that this forms a large part of the >>>>> vision for Chrome OS. Another huge help will be getting people >>>>> comfortable with eventual consistency. >>>>> >>>>> One of the key future applications of the social web is the >>>>> application of networks of trust that allow us to distribute data to >>>>> trusted nodes - the best people to store redundant copies of your data >>>>> are the people you trust personally. It sounds like the guys on that >>>>> link you posted are really pushing the boundaries of this stuff. >>>>> >>>>> Resistance is futile :) >>>>> >>>>> >>>>> On May 24, 12:52 pm, gops <patelgo...@gmail.com> wrote: >>>>> > @hawkett last line was the perfect answer to @keren. >>>>> > >>>>> > instead of making a central system on cloud , designing a software >>>>> > that is very highly distributed using highest encryption standard is >>>>> a >>>>> > way to go. >>>>> > >>>>> > on some level , people athttp://www.joindiaspora.com/are doing that >>>>> > thing at social networking level. ( personally i dont think doing >>>>> this >>>>> > on top of other http or https protocol is good idea. even >>>>> > though creating/defining protocol is hard work , it should be done >>>>> > directly on top of tcp/ip level. ) >>>>> > >>>>> > that way, i own my own server at my own location with my own data >>>>> > fully encrypted and accessible only to me. then i delegate >>>>> > data through defined protocol to other person or system ( be it a >>>>> > company , a bank , a friend , a community etc.. ) with different >>>>> level >>>>> > of data and security access. same way, other system, >>>>> > users and bank etc will delegate their data to my server to similar >>>>> > encryption channels. >>>>> > >>>>> > distributing data this way will remove "scalability need" altogether. >>>>> > and application complexity will reduce dramatically as they do not >>>>> > have to take care of 1000's of connection or users. but it will arise >>>>> > problem for myself to maintain my server , will force to learn a new >>>>> > software etc and learn the system, may be your own private virtual >>>>> > server is a new commodity of the future. >>>>> > >>>>> > my two cents. :D >>>>> > >>>>> > On May 24, 4:08 pm, hawkett <hawk...@gmail.com> wrote: >>>>> > >>>>> > >>>>> > >>>>> > > A small issue if the economy goes down the drain on the scale you >>>>> are >>>>> > > talking about is that an internet where everyone has the capability >>>>> to >>>>> > > connect to a cloud system is going to be difficult to maintain. >>>>> It's >>>>> > > not going to be easy for google to make money, for individuals to >>>>> pay >>>>> > > their internet bills, for internet companies to continue to deliver >>>>> > > access - indeed you may find it difficult for yourself to make >>>>> money >>>>> > > or pay for the developers you are proposing to hire. What value >>>>> will >>>>> > > money have? How will google pay its employees to continue to >>>>> deliver >>>>> > > app engine - ad revenues are going to plummet. I think if your >>>>> system >>>>> > > is anticipating the total collapse of the economy, then you may >>>>> find >>>>> > > it difficult to deliver your system to what remains. >>>>> > >>>>> > > When you say credit free currency, do you mean credit free society? >>>>> > > How do you plan to make it credit free - through legislation? >>>>> What's >>>>> > > to stop me lending some currency I have in your system to someone - >>>>> or >>>>> > > making a purchase on their behalf in exchange for a purchase by >>>>> them >>>>> > > of something more valuable at a later date? That scenario is >>>>> > > essentially an interest bearing loan. The system and those that >>>>> use >>>>> > > it exist in a symbiosis - you can't change one without addressing >>>>> the >>>>> > > other - it's hard to see how you will create a credit free society >>>>> > > without addressing the psychology of the people within that economy >>>>> - >>>>> > > people need to *want* to avoid credit, and when you haven't got >>>>> much, >>>>> > > and others seem to have so much, credit is an insidiously >>>>> attractive >>>>> > > proposition - it's easy to market and sell. You'll probably need to >>>>> > > address the gulf between rich and poor, and marketing of >>>>> impossible, >>>>> > > unaffordable goals to remove credit from society - perhaps you feel >>>>> > > that economic collapse will do that. Does your plan deal >>>>> effectively >>>>> > > with the reality of the flawed, selfish human being? I guess I'm >>>>> > > asking about your second point - is it based on a global societal >>>>> > > enlightenment occurring due to the economic collapse? >>>>> > >>>>> > > If you don't have much money to back this venture then a few points >>>>> > > stand out >>>>> > >>>>> > > 1. The cloud is *much* cheaper than any custom hardware >>>>> installation >>>>> > > you can come up with. Security isn't just data security - you need >>>>> to >>>>> > > manage backups, uptime, support, maintenance, facilities, >>>>> redundancy, >>>>> > > disaster recovery - long list of stuff that will cost you buckets >>>>> > > before you even get started. >>>>> > >>>>> > > 2. You need to do some risk assessment. There are always risks, and >>>>> > > many of them - there is no perfectly secure system, and it is >>>>> > > important not to try and sell such a thing. It is just a matter of >>>>> how >>>>> > > you rate each risk, and important that the stakeholders understand >>>>> the >>>>> > > risk and agree to it - the last thing you want to have is a >>>>> > > conversation where someone says 'You told me it was secure!!!'. It >>>>> > > can't be secure unless it is truly inaccessible to everything and >>>>> > > everyone, and you can't build a system around that :). Risk >>>>> assessment >>>>> > > is generally subjective - what is the chance of someone obtaining a >>>>> > > password they shouldn't? What is the chance of the cloud vendor >>>>> > > exposing data? What is the chance that your code contains bugs? >>>>> What >>>>> > > is the chance of the cloud vendor losing your data entirely - >>>>> http://gigaom.com/2009/10/10/when-cloud-fails-t-mobile-microsoft-lose. >>>>> .. >>>>> > > The list goes on. If you build a system where there is perceived >>>>> value >>>>> > > in subverting it, then it will probably be subverted. It is much >>>>> > > better to cope with it than try to prevent it (you can't prevent >>>>> it). >>>>> > > What you need to prevent against is the possibility that any >>>>> > > particular problem or combination of problems results in total >>>>> > > failure. >>>>> > >>>>> > > Some key questions you need to ask - >>>>> > >>>>> > > 'What is the worst that can possibly happen?' >>>>> > > 'How likely is it?' >>>>> > > 'What can I do to reduce the worst that can possibly happen, and >>>>> the >>>>> > > chance that it will happen - i.e. how do I mitigate my risk?' >>>>> > > 'Can I afford to implement mitigation strategy X, Y or Z?' >>>>> > > 'Am I prepared to accept the consequences of the risk being >>>>> realised?' >>>>> > > Usually it is easier to answer yes to this question when the >>>>> rewards >>>>> > > (not necessarily financial) are higher. >>>>> > >>>>> > > You need to deliver a system that allows you to answer yes to the >>>>> last >>>>> > > question, for every risk you identify. Sometimes you cannot reach >>>>> the >>>>> > > point where the answer is 'yes' - the risk is not worth the reward. >>>>> > >>>>> > > <slight political rant (IMO)> >>>>> > > A good example is the recent financial crisis. The banking sector >>>>> took >>>>> > > risks, understanding that the worst possible outcome (for them) was >>>>> > > not actually as bad as is being portrayed - they felt that they >>>>> would >>>>> > > still not fail because they commanded enough political power to >>>>> rely >>>>> > > on federal funds. So what seemed incredibly risky behaviour by the >>>>> > > banks, was, in fact, not all that risky - because they had shored >>>>> up >>>>> > > their political power to mitigate their risk. Consequently, the >>>>> worst >>>>> > > that could possibly happen with all the risks the banks took was >>>>> that >>>>> > > they would be fine. And largely, they are fine. Good risk >>>>> management >>>>> > > they would say - it wasn't all that risky. Not for them. Incredibly >>>>> > > risky for the taxpayer, but that risk wasn't their concern - at >>>>> least >>>>> > > not from their perspective. You can be sure that it was a >>>>> possibility >>>>> > > they were aware of. The nation(s), however, totally lost a handle >>>>> on >>>>> > > their risk management - the banks should never have been allowed to >>>>> > > reach a position where they could mitigate their risk with federal >>>>> > > funds - essentially the risk was transferred to the tax payer. If >>>>> they >>>>> > > were unable to do that, then they wouldn't have taken the risks in >>>>> the >>>>> > > first place, because they could not have answered 'yes' to the last >>>>> > > question. It is difficult to see how the nation(s) could have >>>>> avoided >>>>> > > this problem though - the stakeholders (the citizens) have very >>>>> > > limited means by which to limit the subversion of power from within >>>>> > > their political process - most of these powerful people within >>>>> > > government are not elected. >>>>> > > </slight political rant (IMO)> >>>>> > >>>>> > > You might also consider an approach to security like Google's - >>>>> they >>>>> > > offer a platform so compelling that many customers will use the >>>>> system >>>>> > > despite google making no promises on security or reliability - 'use >>>>> at >>>>> > > your own risk'. Is your product so compelling that you can mitigate >>>>> > > some of your risk by transferring it to your customers? Google >>>>> also >>>>> > > benefits here from significant goodwill and reputation, but that >>>>> takes >>>>> > > time and evidence - we have seen in their reaction to the Chinese >>>>> > > hacking scandal that they take the compromise of customer data very >>>>> > > seriously. >>>>> > >>>>> > > My gut feel is that the security you want, you can't afford - so >>>>> use >>>>> > > the cloud, encrypt the personal data you need to, and mitigate the >>>>> > > remaining risk by transferring it to your users. Just make them >>>>> aware >>>>> > > of the risk they are taking - you might find they'll accept that >>>>> risk >>>>> > > and use your system anyway. Where google basically says 'Trust us, >>>>> > > we're Google', you need to say 'Trust me, it's on Google'. Most of >>>>> the >>>>> > > customers that would go for the first statement will go for the >>>>> > > second. >>>>> > >>>>> > > You say it would not be responsible to trust google - but this is >>>>> what >>>>> > > you are asking of your customers - to trust you with the security >>>>> of >>>>> > > their information. Trust is a huge factor in risk assessment and >>>>> > > security. Many banks trust third party organisations with customer >>>>> > > information, or to write software that secures customer >>>>> information. >>>>> > > You're going to have to trust someone. >>>>> > >>>>> > > I think history and common sense tells us that our economy will >>>>> > > probably go down the chute at some point - our system is pretty >>>>> > > tightly strung, and doesn't cope very well with fairly minor >>>>> > > disturbances. It's utterly dependent upon confidence, and totally >>>>> > > global. Natural systems manage risk through redundancy and >>>>> diversity - >>>>> > > failure doesn't bring the whole thing down. I doubt our brilliant >>>>> idea >>>>> > > of having one global economy is going to have nature going - 'Hey, >>>>> why >>>>> > > didn't I think of that?' - more like - 'Tried that, didn't work - >>>>> you >>>>> > > should have asked. In the meantime, here's a small icelandic >>>>> volcano >>>>> > > to deal with - get the idea?'. We are selfish idiots ruled by >>>>> selfish >>>>> > > idiots, urging each other to become more so. Probably not the best >>>>> > > architecture we could come up with. Our society could learn >>>>> something >>>>> > > from the way we build distributed software. >>>>> > >>>>> > > On May 24, 7:06 am, Keren Or Shalom >>>>> > >>>>> > ... >>>>> > >>>>> > read more ยป >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Google App Engine" group. >>>>> To post to this group, send email to google-appengine@googlegroups.com >>>>> . >>>>> To unsubscribe from this group, send email to >>>>> google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com> >>>>> . >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/google-appengine?hl=en. >>>>> >>>>> >>>> >>>> >>>> -- >>>> V07768198309 >>>> >>> >>> >>> >>> -- >>> V07768198309 >>> >> >> >> >> -- >> V07768198309 >> > > > > -- > V07768198309 > -- V07768198309 -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
