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.
