hawkett says: You're talking about the difference between a waterfall project methodology and an iterative project methodology. Your 'design, implement, finished' approach sounds attractive, but is usually significantly less effective than an iterative approach when developing software.
When you talk about preventing against a system wide breach, if you take on the work yourself - then *you* need to be responsible for preventing against total breach or total loss of data - the problem doesn't go away if you do it yourself. This is a massive undertaking - even if you had an army of low costs resources - a project can only improve efficiency so much no matter how many resources you throw at it. If you are talking about a global currency system, then it will be a target for attack. My point is that I doubt you can start from scratch and build a cloud platform that has the scalability, security and reliability characteristics you are after, and convince your customers that you have done so. Building it yourself doesn't sound like a good risk mitigation strategy to me. For the position you are in, it would seem the cloud is the right choice, and the risks you can't mitigate you have to be prepared to cope with - tell your customers what the risks are - 'It's on Google, but your account number is encrypted'. No venture is guaranteed to succeed. I agree 100% with you still it does not allow me not to do due diligence as they say in the financial market. I am a risk taker but I never play roulette. On 25 May 2010 13:05, Keren Or Shalom <[email protected]> wrote: > Colin > > Be sure that people at Google are fully aware of the issue and anyway the > Market will > take care of it: very few decider would give away the control of strategic > data at any price > very few will do it but being so dumb it is probable that they will be out > of business long before > the first data leak. > > On the other way any decider given that he has technological assurance that > his data are > secure would gladly put his IT on the cloud. > > Myself I decided that for efficiency and privacy reason I wouldn't collect > private information > about my 'customers' I don't need to tell them I won't do evil they know I > can't. > > > On 25 May 2010 12:40, hawkett <[email protected]> wrote: > >> Hi Ikai, >> >> I'd like to draw a distinction between (a) the platform being able to >> see the data, (b) employees being able to see the data (c) the >> policies by which employees look at data (sanctioned by google) (d) >> ilegal data access (not sanctioned by google - either by an employee >> or an external attack) (e) the protections against d at a high level >> >> At the moment google seems to pull all these elements into the one >> basket - and say 'we can see your data'. That statement doesn't >> actually carry any useful information, except perhaps by implication - >> 'we're not saying much because you wouldn't like it if you knew.' >> >> Take for example this FAQ statement for Google Apps - >> http://www.google.com/support/a/bin/answer.py?hlrm=en&answer=106887 - >> it is an exceptionally helpful statement. With App Engine, unless I >> have missed it, there are no such statements - just 'we can see your >> data'. >> >> Additional security is one thing, clarity and transparency is >> another. You don't need cryptographic keys and ACL's to achieve an >> improvement in people's ability to *understand* the data security of >> their app on app engine. >> >> Cheers, >> >> Colin >> On May 24, 11:44 pm, "Ikai L (Google)" <[email protected]> wrote: >> > Guys, I want to encourage you to stay on topic. >> > >> > The issue here is encryption for data store in App Engine. As several >> > posters have pointed out, there are no easy solutions for this. A shift >> > towards the cloud has all the implications of not being able to >> physically >> > secure the data. Using a service such as App Engine, something we common >> > describe as a platform-as-a-service, you have much less control over >> your >> > data, though we will bear the responsibility of providing as much >> security >> > as we can. There is probably a workable compromise somewhere involving >> where >> > we store cryptographic keys and ACLs, but for the foreseeable future, >> you >> > will have to accept that if you are running your software on Google's >> > platform, then Google's platform will be able to access your data. If >> you >> > build a rich client, you can encrypt the data on the client. >> > >> > -- >> > Ikai Lan >> > Developer Relations, Google App Engine >> > Twitter:http://twitter.com/ikai >> > Delicious:http://delicious.com/ikailan >> > >> > ---------------- >> > Google App Engine links: >> > Blog:http://googleappengine.blogspot.com >> > Twitter:http://twitter.com/app_engine >> > Reddit:http://www.reddit.com/r/appengine >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "Google App Engine" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> [email protected]<google-appengine%[email protected]> >> . >> > For more options, visit this group athttp:// >> groups.google.com/group/google-appengine?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-appengine%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> >> > > > -- > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
