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: Boyd Fletcher <email@hidden>
- Date: Mon, 29 Oct 2007 00:51:45 -0400
- Thread-topic: [Fed-Talk] iPhone not allowed at NIH - comments?
On 10/28/07 9:28 AM, "William G. Cerniuk" <email@hidden> wrote:
> In some ways it is actually a superior security model.
On corporate BBs using BES, in additional to server based kill, you also
can enforce disabling bluetooth, set password lengths, and number of
password tries before the BB automatically wipes, etc... None of this can be
done on an iPhone
>
> 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.
actually that is not correct. the BB does approximately same amount of
processing on it as does the iPhone. You can also do SMTP, POP, IMAP, and
HTTP on a BB.
> -- 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".
How is that any different that the SMTP and IMAP servers the iPhone is
connecting to?
>
> 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.
And that's good thing? Apparently most people want native apps for the
iPhone thus the reason apple is finally releasing an SDK for it.
> 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.
JavaScript implementations (including the one in Safari) have been shown
repeatedly have security vulnerabilities.
> 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.
BB's can enforce digital signing of apps so only authorized apps can be
loaded. I suspect the digital signing of apps is one of the reasons for the
delay in Apple's iPhone SDK. I suspect that are going to add new
capabilities in iTunes to install apps and digitally sign and publish
applications for iPhone. The BES server can also enforce which apps are
installed on the BBs. I suggest you take a look at the
BlackBerry_Enterprise_Server_Policy_Reference_Guide.pdf available at
www.blackberry.com.
If Apple wants the iPhone to compete with BBs for corporate/enterprise/gov
users then it really needs to add enterprise management capabilities to the
phone. Right now, its just a really cool and powerful phone for consumers.
>
> 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
_______________________________________________
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