Φυσικά όταν ένα καινούργιο μοντέλο ασφάλειας εμφανίζεται στο προσκήνιο αυτό είναι σίγουρο ότι θα δεχτεί κριτική. Και όσο παρουσιάζονται σφάλματα τόσο η κριτική αυτή γίνεται πιο έντονη και ο σκεπτικισμός μεγαλώνει. Αυτό που πρέπει να ξέρουμε και να παραδεχθούμε είναι ορισμένες αρχές πάνω στις οποίες θα προχωρήσουμε. Η πρώτη είναι ότι δεν υπάρχει σύστημα εκατό τις εκατό ασφαλές. Η δεύτερη είναι ότι δεν υπάρχει σύστημα φτιαγμένο από ανθρώπινο χέρι που να μην έχει σφάλματα. Επίσης όσοι ασχολούνται με την ασφάλεια ξέρουν τους γνωστούς συμβιβασμούς, ασφάλεια-ευχρηστία και ασφάλεια-κόστος, όπου στην πρώτη περίπτωση είναι αντιστρόφως ανάλογα και στην δεύτερη ανάλογα. Έχοντας όλα αυτά υπ’ όψη και παραδεχόμενοι ότι ούτε η Java είναι πανάκια μπορούμε να παρακολουθήσουμε την σκέψη κάποιων ανθρώπων που ξέρουν από πρώτο χέρι την ασφάλεια.

Είναι γεγονός ότι το επίπεδο ασφάλειας που παρέχει η Java κάποιους θα τους ικανοποιήσει και κάποιους όχι. Είναι θέμα αυτού που αγοράζει την ασφάλεια να αποφασίσει αν αυτό που του προσφέρει η Java σ’ αυτόν τον τομέα του κάνει ή όχι. Και το βασικότερο είναι να ξεπεραστεί ο “μύθος” περί απρόσβλητου από επιθέσεις προϊόντος και να μπουν τα πράγματα στην πραγματική τους διάσταση.

Υπάρχει μια διχογνωμία σχετικά με το κατά πόσο μια λύση ασφάλειας που βασίζεται στο λογισμικό είναι καλύτερη από μια αντίστοιχη που βασίζεται στο υλικό.

Αν τελικά καθιερωθεί το μοντέλο του αμμοδοχείου, όπου τα applets περιορίζονται σε ένα συγκεκριμένο χώρο κάνοντας συγκεκριμένα πράγματα ίσως αυτό να αποτελεί και την καταδίκη τους. Το ζητούμενο είναι να μπορούν τα applets να δράσουν ελεύθερα προκειμένου να κάνουν κάτι πραγματικά χρήσιμο και αποδοτικό. Αν σήμερα κάνουν κάποια απλοϊκή εργασία, αύριο θα μπορούν να εκτελούν ένα πρόγραμμα εντοπισμού ιών, να εγκαθιστούν μια εφαρμογή, να κάνουν ένα τυπικό έλεγχο στο σύστημα μας για σφάλματα, με την προϋπόθεση όμως ότι θα είναι ασφαλή.

Μια άλλη άποψη είναι ότι η προσβολή του συστήματος ασφάλειας της Java είναι ολοκληρωτική. Έτσι και κάποιο applet ξεφύγει απ’ το αμμοδοχείο του δεν υπάρχει άλλη γραμμή άμυνας και το σύστημα είναι στην διάθεση του εισβολέα. Ακόμη μια καλή επίθεση μπορεί να επιτευχθεί αν βασίζεται στο στοιχείο του αιφνιδιασμού. Δηλαδή αν ο εισβολέας προβλέψει κάτι που δεν έχει προβλέψει ο σχεδιαστής. Γενικά είναι ενδιαφέρουσα η ιστορία όπου οι πιο σημαντικές διεισδύσεις σε συστήματα δεν έγιναν με την εκμετάλλευση κάποιου σφάλματος αλλά αντίθετα κάποιου σχεδιαστικού χαρακτηριστικού του οποίου την κακή χρήση δεν μπορούσε ούτε ο ίδιος σχεδιαστής να φανταστεί.

Ας τελειώσουμε με κάτι θετικό και αισιόδοξο. Στο παρελθόν πολλά δίκτυα και συστήματα προσπαθούσαν να διατηρήσουν την ασφάλεια τους κρύβοντας την εσωτερική τους δομή και τις πολιτικές του συστήματος. Αυτή η πρακτική υπέθετε ότι αν το σύστημα παρουσιαζόταν σαν “μαύρο κουτί” κανένας δεν θα έκανε την προσπάθεια να ανακαλύψει τις κρυμμένες του αδυναμίες. Η πράξη έδειξε το άτοπο αυτής της υπόθεσης και απέδειξε ότι τελικά το “μαύρο κουτί” δεν ήταν τόσο μαύρο τελικά. Αυτό είναι ακόμη πιο πιθανό για επιτυχημένα εμπορικά προϊόντα όπου πολλοί άνθρωποι γνωρίσουν την εσωτερική δομή του αλλά και όπου η ανταμοιβή απ’ το “σπάσιμο” του συστήματος είναι σαφώς επικερδής.

Η εταιρεία Sun ακολούθησε τελείως διαφορετική πορεία και δημοσιοποίησε όλες τις λεπτομέρειες του μοντέλου ασφάλειας της Java. Αυτό περιελάμβανε τις προδιαγραφές της γλώσσας, το αμμοδοχείο και την πλήρη πηγαία υλοποίηση. Αυτή η προσέγγιση, ασφάλεια μέσα απ’ την δημοσιοποίηση, είχε την πρόθεση να ενθαρρύνει τους ανθρώπους του ερευνητικού τομέα της ασφάλειας να εξετάσουν το μοντέλο της Java και να αναφέρουν οποίο σφάλμα βρήκαν. Τα σφάλματα αυτά θα μπορούσαν να διορθωθούν πριν δημιουργήσουν σοβαρά προβλήματα στο Internet. Επίσης αυτή η προσέγγιση δίνει την ευκαιρία σε κάθε οργανισμό να μελετήσει το μοντέλο ασφάλειας με λεπτομέρεια και να κάνει μια εκτίμηση ορθολογική των πιθανών ρίσκων σε σχέση με τα οφέλη απ’ την χρήση της Java.