Hi, > One thing you repeatedly mention is that sniffing data/credentials > may be possible on the public server. I don't think this is ever high > risk, as anyone doing "sensitive" computations shouldn't be using > someone else's hardware to do it (SSL encrypted connection or not), > especially as it is so easy to run your own personal copy of Sage > (locally or somewhere that you trust). Also, by default, there's a > big warning on running without https on anything but localhost.
With the same argument you could say one shouldn't use webmail or e-mail at all if one thinks e-mail is private. Also, it is not only issues with sensitive computations but SSL would mitigate quite a few threats Yoav pointed out (spoofing, attacks on others, etc.) > Encrypting and authenticating worksheets seems beyond the scope of > what the Sage notebook should do, there are plenty of 3rd party tools > to do this cleanly and it's obvious (I hope) that sharing worksheets > is sharing code. The %auto keyword could be bad though. I agree that downloading and mailing worksheets might be beyond the scope of Sage but sharing within Sage certainly isn't. Also, for the download-and-share situation it would be very easy to add some protection because Sage has all the relevant crypto-protocols available anyway. It would send a clear signal that we care about security and would be relatively easy to implement. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: [email protected] --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
