Re: [Fed-Talk] iPhone not allowed at NIH - comments?
Re: [Fed-Talk] iPhone not allowed at NIH - comments?
- Subject: Re: [Fed-Talk] iPhone not allowed at NIH - comments?
- From: "William G. Cerniuk" <email@hidden>
- Date: Sun, 28 Oct 2007 09:28:22 -0400
In some ways it is actually a superior security model.
• iPhone is a stand alone system. It performs its own SMTP, POP,
IMAP, and HTTP.
• BlackBerry is a thin client back to a BES server which performs
most of the BB's critical functions and hands the data back to the BB
in a terminal session.
-- BES is a single point of failure enabling a hacker or a virus to
take out 100's if not 1000's of BBs with one compromise ( it happened
just recently too ). To exaserbate the issue, the BES is based on
Windows with its Swiss cheese security model. It is not "if" your BES
gets hacked, it is "when" and "how often".
• iPhone permits only web applications to be run, allowing only HTML
and JavaScript to be interpreted by Safari. iPhone applications
execute at the server, not at the iPhone.
• BlackBerry units actually allow code to be loaded into the phone in
the form of Java applications. Java is a powerful complied pcode
language. The BB system itself runs as a Java engine and permits
outside developer code to run within the core operating engine of the
phone.
-- Java can be used to write an entire operating system where as
JavaScript relies on a browser for execution and is very limited in
its capbility. A stand alone word MS Office like can and has been
written in Java where the same effort is a futile in JavaScript which
is more like an excel macro. Given this, opening up the internals of a
BB to foreign applications opens up a huge liability in contrast to
keeping application execution away from the phone, over at the server,
as the iPhone does. While Apple will eventually provide the ability to
load apps at the phone, today's model of "applications" on iPhone
beats BB's by not allowing malware to even potentialy exist in the
system.
There is more but my thumbs are cramping ;-)
V/R,
Wm. Cerniuk
Time is Short and the Water Rises
(sent via my iPhone)
On Oct 27, 2007, at 11:04 AM, Amanda Walker <email@hidden> wrote:
On Oct 25, 2007, at 4:39 PM, Michael Johnson wrote:
2. No centralized management (Password policies can not be
applied, device data cannot be wiped if lost or stolen)
Resetting the device is trivial. There is a passcode to lock it.
Note "if lost or stolen." The device cannot be reset remotely (as
Blackberries can be, for example). This is a big deal, and is a
reason that iPhones are having trouble getting IT buy-in in private
sector enterprises as well. The passcode is a step, but you can't
enforce any kind of policy on it (like forcing on "auto-lock" mode).
I know of at least one large enterprise where iPhones can only
access corporate email by VP decree, over the active opposition of
the IT and information security organizations. This is not
political--the IT and security guys were the first to buy iPhones,
and love them. They just can't enforce the company's information
security policies on them.
Hopefully, this is a "not yet" issue, though.
3. No enterprise connectivity (E-mail, contacts, calendar)
Have the people at CIT seen and iPhone? NIH has IMAP turned on, so
the iPhone will connect to the Exchange servers. Contacts and
calendaring are there. All you have to do is use a standard .ics
file.
It's possible to use it this way, though it's not as well integrated
as Blackberry Enterprise Server.
We apologize for any inconvenience. Thank you for your
understanding!
Apple would be thankful if NIH/CIT understood what they were
talking about.
It's not just NIH. The iPhone has a ways to go before it's
enterprise-friendly. In every way besides manageability and
security, it wins big, but it's no Blackberry replacement yet.
--Amanda
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden