Wayne Wilson wrote: > > From: "Tim.Churches" <[EMAIL PROTECTED]> > > > > > >Any other ideas for S3? > > > 1) Wait for Google to offer it for free :) > > Seriously, Google already offers 2GB of free web 'mail' space. Someone > has already figured out how to make a file system like interface to that.
Yeah, I mentioned that in my post: TC> I suspect that Google will follow suit, as they, like Amazon, TC> already have the required infrastructure to host this sort of thing, TC> and their Gmail service is already being used by many as an TC> unofficial Internet file store (see, for example, TC> http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html TC> However, such use of GMail is unsanctioned and, if you read it carefully, in conflict with the spirit of the usage agreement. Thus, Google could pull the plug on such (ab)use of GMail at any time. The difference with the Amazon S3 facility is that it is designed from the outset for bulk data storage and access, and they do not dredge the data to try to match advertisements against it (encryption prevents that anyway). In fcat, there is no user interface to S3 - it is just an API which you build into your application. Google are rumoured to offer something similar quite soon, working name "GDrive", but in the absence of a way to obtain revenue from it via adverts, they will probably charge for it - but Amazon has set the bar for such charges at a remarkable low level. > This is the tip of an iceberg in the developed countries that further > widens the gap between the 'Netties' and network impoverished. > What if storage on the net is free and unlimited? What if all electronic > information is indexed on the net? How would one design distributed > systems when the storage and retrieval of data became decoupled (and > replaced with a web service) from the systems you use to manipulate > that data? > > What are the issues? > Who is in control of the data? Where are the boundaries of control? > How can I trust them to do what they say they will do with the data? You can't, as I pointed out in my post: TC> I wouldn't trust the Amazon assurances of privacy for the data (as TC> Amazon are still subject to US search warrants and court orders for TC> example, as well as simple security blunders - so any patient data TC> would need to be strongly encrypted before sending it to S3 for TC> off-site backup storage - but that should be routine practice for TC> any off-site back-ups [or any other storage] of patient data on TC> removable or transportable media anyway). > Just so you don't think these are abstract issues, where I work we just > promulagated policy that strongly suggested that google desktop be > uninstalled or otherwise disabled on all organizational owned workstations. Sure - the issue Wayne is referring to is the ability for the latest version of Google Desktop to send copies of your local documents to the Google servers for retrieval from a different computer - but that is orthogonal to the uses of Amazon S3 which I suggested in my post, which all involve the archival, back-up or temporary storage of *encrypted* data - I suppose I should have spelt it out more clearly - things like Amazon S3 are not useful for storage, even temporary or transient storage - of confidential data unless it is strongly encrypted. Nor can their reliability be absolutely relied on - it is likely to be very good, but they provide no guarantees that they won't lose your data or that it won't be inaccessible. Thus, I think that they should only be used for back-ups or transient storage. Until Google brings out a competing service. Then if you store your data on *both* Amazon S3 *and* Google Gdrive, the risk of your data disappearing is vanishingly small. But the data that your store on them still needs to be strongly encrypted, OK? Tim C Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/openhealth/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/