Yes, “accidental” DOS certainly could apply, which is why I say that simple measures (like limiting the number of bytes that PreferredClassLoader will download before giving up) are a good idea. But I think that any radical re-imagining of object serialization is outside the scope of the River project.
Cheers, Greg Trasuk On Feb 19, 2015, at 11:39 AM, Patricia Shanahan <p...@acm.org> wrote: > I generally agree, but do have a question. > > In other contexts, I've seen unintentional bugs, rather than deliberate DOS, > lead to behavior similar to DOS. A program goes wrong, and tries to e.g. > allocate far too much memory, or goes into a loop. In contexts where that can > happen, work to protect against DOS also makes the software more robust. > > In shared service situations, an apparently non-critical program can cause a > DOS that also affects more important programs. Either all programs have to be > designed, reviewed, and tested to the reliability requirements of the most > sensitive program with which they share resources, or there has to be > isolation between them. > > Does this sort of consideration apply in reality to River? > > On 2/19/2015 6:58 AM, Greg Trasuk wrote: >> >> The type of issues you’re talking about seem to be centred on putting >> Jini services on the open internet, and allowing untrusted, unknown >> clients to access those services safely. >> >> Personally, my interest is more along the lines of Jini’s original >> goal, which was LAN-scoped or datacenter-scoped SOA. Further, I use >> it on more controlled networks. As far as I’m concerned, only code >> that I trust gets on the network. In a larger corporate scenario, I >> might lock down access to Reggie, but beyond that, I don’t consider >> DOS a threat. I think it would make sense to be able to put a byte >> limit on the stream used to load the class, and possibly a time >> limit, but beyond that, I think you’re adding complexity that isn’t >> needed. If you want to put a service on the web, use RESTful >> services, not Jini. I’m sure there’s a discoverability tool out >> there, if needed, but typically it isn’t. >> >> Also, since object serialization is not specific to River, I wonder >> if there’s a better forum for these kinds of deep discussions. I >> think it makes River look far harder than it is. >> >> Cheers, >> >> Greg Trasuk. >> >> On Feb 19, 2015, at 9:03 AM, Peter <j...@zeus.net.au> wrote: >> >>> What are your thoughts on security? >>> >>> Is it important to you? Is it important for River? >>> >>> Regards, >>> >>> Peter. >>
