Exchange enhancements in iPhone 3.1 cause some users grief
Improved support for Microsoft's Exchange Server's security policy features, delivered in the iPhone 3.1 firmware update, has left some users angry after discovering that their mobile device is no longer compatible with the policy defined by their company.
At issue is Apple's iPhone client implementation of Exchange ActiveSync, the Microsoft specification Apple licensed last year in order to provide official support for Exchange Server sync to the iPhone and iPod touch.
EASy to wipe
EAS defines not only how Exchange server syncs data to mobile clients, but also involves remote management features like remote wipe and security policy such as mandating that all devices be set to use a PIN to lock the screen when not in use.
Microsoft has evolved EAS over time, adding new options that allow Exchange admins additional control over the devices they choose to support. For example, in Exchange 2007 Service Pack 1, Microsoft added a new security policy option to require device encryption on mobile devices in order to support a new feature of Windows Mobile 6.0.
With file level device encryption, administrators can rapidly remote wipe a lost or stolen device, minimizing the risk of its data falling in the wrong hands. Without device encryption, a remote wipe takes longer because the remote device must zero all of its files. This makes it more likely that a thief could interrupt the wipe process, although once a phone is stolen, a savvy thief can disable its network connection and attempt to prevent any remote wipe from ever occurring.
Client-side EAS
Client manufacturers who license EAS from Microsoft, including Apple, Palm and Sony Ericsson, can implement the EAS specification on their client devices however they like. For example, the Palm Pre's Exchange support currently doesn't support security policy involving PIN use or remote wipe at all. Even Microsoft's own Windows Mobile 5.x implemented support for EAS differently than the current WiMo 6.x.
For example, under WiMo 5, EAS remote wipe couldn't also clear any data stored on an installed SD Flash card. Since most WiMo phones shipped with very little included storage, any important data was most likely kept on this impossible to wipe Flash memory.
This effectively meant that Exchange admins simply could not really wipe a WiMo 5.0 phone, even though the devices were described as supporting a form of remote wipe. That detail didn't stop pundits from favorably comparing WiMo 5.x's ineffectual wipe with the lack of any remote wipe feature on the original iPhone up until the release of the 2.0 firmware.
Policy respect
An Exchange server has no way to demand that clients obey all of its security policies; it has to trust that client devices respect them. When administrators specify a given policy on the server, mobile devices that fully support those feature options will stop working if the server-side policy settings raise the bar beyond the devices' capabilities.
That's what happened to many iPhone users who upgraded to iPhone 3.1 only to discover that their device stopped syncing with any Exchange Servers using the default "RequireDeviceEncryption" policy set to "True." Only the iPhone 3GS and the newly released 32 and 64GB iPod touch models support this hardware encryption feature; earlier models of the iPhone and iPod touch do not, and subsequently, their expanded support for Exchange policy settings forced them to no longer work.
In order for affected iPhone 3.1 users to reestablish a connection with Exchange, server-side administrators need to create a policy exception (for either that user or the entire server) which will allow connections to mobile devices that do not support device encryption. This was the status quo prior to Exchange 2007 SP1, which introduced the policy option, so it really isn't a drastic reduction in security as some have suggested. It involves unchecking a box and clicking OK (below).
The only other alternative is for those users to either upgrade to phone hardware that meets the minimum requirements configured on their company's Exchange Server, or downgrade back to iPhone 3.0 and simply ignore the security policy set by their company. The reason for the change on Apple's end is to comply with legal security requirements such as HIPAA, enabling the new iPhone 3GS to be suitable for approval in secure enterprise environments such as within the healthcare industry.
Oh the humanity
This change in the iPhone 3.1 update was poorly communicated to users by Apple, which should have at least alerted users of the potential impact of the upgrade during the installation process. The same update also quietly disabled tethering support on AT&T for certain users who had enabled the software feature against the terms of their AT&T contract.
The result was confusion and frustration by users, many of whom lack any capacity to motivate their company's Exchange admins to help them understand what had happened, let alone accommodate them with security policy changes from the default settings many Exchange Server shops never bother to change.
Similar security policy problems have resulted in problems for Mac users. Windows Server introduced changes that broke compatibility with existing clients while trying to enhance the network's security profile in tandem with the launch of Vista, for example. Support for alternative platforms like the iPhone and the Mac is not Microsoft's top priority, of course. However, Apple's increasing popularity among consumers, particularly among executives and mobile road warriors, has helped to promote improved support for Apple clients in many Windows-oriented companies.
Still, when unexpected things happen, many pundits are ready revile Apple's security credentials and denounce the company in scathing terms. Writing for InfoWorld, Galen Gruman stated Apple had "betrayed the iPhone's business hopes" and accused the company of misrepresenting the security profile of its iPhone devices, based on the speculation that iPhone 3.0 software must have "lied" by reporting that it was performing encryption prior to the update.
The problem with proprietary standards
In reality, iPhone 3.1 simply improved its support for EAS's defined security policy options, with unfortunate results for anyone who wanted to sync with an Exchange Server set to the default policy settings that happened to exclude their model of iPhone.
The proprietary nature of EAS, along with its constantly changing specifications tied to Microsoft's business decisions rather than industry consensus, creates a problem for consumers who want competition and choice along with the assurance that the phone they buy will work with their company's servers.
Right now however, the enterprise messaging industry's leading vendors have no desire to craft an open standard for mobile sync. Instead, RIM is promoting its own BlackBerry Enterprise Server product, which rakes in profits, while Microsoft is working to establish EAS as a way to anchor its dominance in corporate email with Exchange Server.
Imagine if Palm had paid Apple for the rights to sync the Pre with iTunes, but that part of the deal required Palm to only support features Apple allowed. This wouldn't be ideal or open. On the other hand, it's challenging for community consensus to build open standards that don't hamper the potential for innovation. Emerging web standards are a great example of finding a common ground in between, where vendors can innovate with different engines and browsers that also implement common, compatible features.
Whether something similar will ever happen in the mobile world remains to be seen. Apple is rapidly becoming a significant player in the smartphone industry, having passed Microsoft's combined Windows Mobile market share. With so many iPhone users, Exchange administrators have more reason than ever to accommodate them.
Apple is also taking its first real opportunity to enter the enterprise market seriously, and iPhone 3.1 is evidence of that, even if it results in short-term pain for some users right now. To help, Apple has revised its iPhone 3.0 Enterprise Deployment Guide (PDF) to include the new changes in iPhone 3.1.
Without much life left in its own mobile platform, Microsoft is likely to become increasingly supportive of third party mobile platforms on Exchange, and could someday even release EAS as an open specification to prevent a rival, alternative open specification from being launched.
Microsoft is actually making some use of the Open Mobile Alliance Device Management (OMA DM) protocol, which is also used by Symbian and in mobile device management tools sold by IBM. OMA DM is an offshoot to the SyncML consortium. Apple hasn't attempted to support SyncML since the original version of iSync, and neither the iPhone nor Android seem to be paying any attention to OMA DM.
At issue is Apple's iPhone client implementation of Exchange ActiveSync, the Microsoft specification Apple licensed last year in order to provide official support for Exchange Server sync to the iPhone and iPod touch.
EASy to wipe
EAS defines not only how Exchange server syncs data to mobile clients, but also involves remote management features like remote wipe and security policy such as mandating that all devices be set to use a PIN to lock the screen when not in use.
Microsoft has evolved EAS over time, adding new options that allow Exchange admins additional control over the devices they choose to support. For example, in Exchange 2007 Service Pack 1, Microsoft added a new security policy option to require device encryption on mobile devices in order to support a new feature of Windows Mobile 6.0.
With file level device encryption, administrators can rapidly remote wipe a lost or stolen device, minimizing the risk of its data falling in the wrong hands. Without device encryption, a remote wipe takes longer because the remote device must zero all of its files. This makes it more likely that a thief could interrupt the wipe process, although once a phone is stolen, a savvy thief can disable its network connection and attempt to prevent any remote wipe from ever occurring.
Client-side EAS
Client manufacturers who license EAS from Microsoft, including Apple, Palm and Sony Ericsson, can implement the EAS specification on their client devices however they like. For example, the Palm Pre's Exchange support currently doesn't support security policy involving PIN use or remote wipe at all. Even Microsoft's own Windows Mobile 5.x implemented support for EAS differently than the current WiMo 6.x.
For example, under WiMo 5, EAS remote wipe couldn't also clear any data stored on an installed SD Flash card. Since most WiMo phones shipped with very little included storage, any important data was most likely kept on this impossible to wipe Flash memory.
This effectively meant that Exchange admins simply could not really wipe a WiMo 5.0 phone, even though the devices were described as supporting a form of remote wipe. That detail didn't stop pundits from favorably comparing WiMo 5.x's ineffectual wipe with the lack of any remote wipe feature on the original iPhone up until the release of the 2.0 firmware.
Policy respect
An Exchange server has no way to demand that clients obey all of its security policies; it has to trust that client devices respect them. When administrators specify a given policy on the server, mobile devices that fully support those feature options will stop working if the server-side policy settings raise the bar beyond the devices' capabilities.
That's what happened to many iPhone users who upgraded to iPhone 3.1 only to discover that their device stopped syncing with any Exchange Servers using the default "RequireDeviceEncryption" policy set to "True." Only the iPhone 3GS and the newly released 32 and 64GB iPod touch models support this hardware encryption feature; earlier models of the iPhone and iPod touch do not, and subsequently, their expanded support for Exchange policy settings forced them to no longer work.
In order for affected iPhone 3.1 users to reestablish a connection with Exchange, server-side administrators need to create a policy exception (for either that user or the entire server) which will allow connections to mobile devices that do not support device encryption. This was the status quo prior to Exchange 2007 SP1, which introduced the policy option, so it really isn't a drastic reduction in security as some have suggested. It involves unchecking a box and clicking OK (below).
The only other alternative is for those users to either upgrade to phone hardware that meets the minimum requirements configured on their company's Exchange Server, or downgrade back to iPhone 3.0 and simply ignore the security policy set by their company. The reason for the change on Apple's end is to comply with legal security requirements such as HIPAA, enabling the new iPhone 3GS to be suitable for approval in secure enterprise environments such as within the healthcare industry.
Oh the humanity
This change in the iPhone 3.1 update was poorly communicated to users by Apple, which should have at least alerted users of the potential impact of the upgrade during the installation process. The same update also quietly disabled tethering support on AT&T for certain users who had enabled the software feature against the terms of their AT&T contract.
The result was confusion and frustration by users, many of whom lack any capacity to motivate their company's Exchange admins to help them understand what had happened, let alone accommodate them with security policy changes from the default settings many Exchange Server shops never bother to change.
Similar security policy problems have resulted in problems for Mac users. Windows Server introduced changes that broke compatibility with existing clients while trying to enhance the network's security profile in tandem with the launch of Vista, for example. Support for alternative platforms like the iPhone and the Mac is not Microsoft's top priority, of course. However, Apple's increasing popularity among consumers, particularly among executives and mobile road warriors, has helped to promote improved support for Apple clients in many Windows-oriented companies.
Still, when unexpected things happen, many pundits are ready revile Apple's security credentials and denounce the company in scathing terms. Writing for InfoWorld, Galen Gruman stated Apple had "betrayed the iPhone's business hopes" and accused the company of misrepresenting the security profile of its iPhone devices, based on the speculation that iPhone 3.0 software must have "lied" by reporting that it was performing encryption prior to the update.
The problem with proprietary standards
In reality, iPhone 3.1 simply improved its support for EAS's defined security policy options, with unfortunate results for anyone who wanted to sync with an Exchange Server set to the default policy settings that happened to exclude their model of iPhone.
The proprietary nature of EAS, along with its constantly changing specifications tied to Microsoft's business decisions rather than industry consensus, creates a problem for consumers who want competition and choice along with the assurance that the phone they buy will work with their company's servers.
Right now however, the enterprise messaging industry's leading vendors have no desire to craft an open standard for mobile sync. Instead, RIM is promoting its own BlackBerry Enterprise Server product, which rakes in profits, while Microsoft is working to establish EAS as a way to anchor its dominance in corporate email with Exchange Server.
Imagine if Palm had paid Apple for the rights to sync the Pre with iTunes, but that part of the deal required Palm to only support features Apple allowed. This wouldn't be ideal or open. On the other hand, it's challenging for community consensus to build open standards that don't hamper the potential for innovation. Emerging web standards are a great example of finding a common ground in between, where vendors can innovate with different engines and browsers that also implement common, compatible features.
Whether something similar will ever happen in the mobile world remains to be seen. Apple is rapidly becoming a significant player in the smartphone industry, having passed Microsoft's combined Windows Mobile market share. With so many iPhone users, Exchange administrators have more reason than ever to accommodate them.
Apple is also taking its first real opportunity to enter the enterprise market seriously, and iPhone 3.1 is evidence of that, even if it results in short-term pain for some users right now. To help, Apple has revised its iPhone 3.0 Enterprise Deployment Guide (PDF) to include the new changes in iPhone 3.1.
Without much life left in its own mobile platform, Microsoft is likely to become increasingly supportive of third party mobile platforms on Exchange, and could someday even release EAS as an open specification to prevent a rival, alternative open specification from being launched.
Microsoft is actually making some use of the Open Mobile Alliance Device Management (OMA DM) protocol, which is also used by Symbian and in mobile device management tools sold by IBM. OMA DM is an offshoot to the SyncML consortium. Apple hasn't attempted to support SyncML since the original version of iSync, and neither the iPhone nor Android seem to be paying any attention to OMA DM.
Comments
I just called to say how much I care
I just called to say I love you
And I mean it from the bottom of my heart
Because I'm first!!!!
An honest question: I know there are a ton of iPhones out there, but how many are really being pressed into corporate use? Corporations wouldn't typically (stress typically) allow a BYO phone so a lot of the phones out there in consumerland wouldn't be relevant to this discussion.
It's not just corporations using Exchange. Most big institutions like Hospitals, Universities etc. would also be using it.
That being said, there's no excuse for forcing people to use Exchange and then not keeping up with the latest version. Either they should be serious about it or just let people use Gmail or whatever they want.
An honest question: I know there are a ton of iPhones out there, but how many are really being pressed into corporate use? Corporations wouldn't typically (stress typically) allow a BYO phone so a lot of the phones out there in consumerland wouldn't be relevant to this discussion.
I do not know any statistical data, but I am a consultant for several companies (two with over 1,000 seats and one with over 10,000 seats among them) and every single one of them does allow BYO phones and there was one Apple rep stating they had several Fortune 100 companies buying thousands of them (not sure if it was during a conference call)... but this is really not the point. If a company does really require device encryption (most don't), it uses Blackberries. The security features in EAS (and subsequently the iPhone) are neither tried and tested (they are simply too new, even Windows Mobile 6.1 devices were not fully supporting them until a patch released in March 2009 fixed most issues) and, as the article clearly states, it is fully up to the device manufacturer to support them and ensure the status information given by the device is truthful... setting a policy that can't be enforced is pointless.
I do not know any statistical data, but I am a consultant for several companies (two with over 1,000 seats and one with over 10,000 seats among them) and every single one of them does allow BYO phones and there was one Apple rep stating they had several Fortune 100 companies buying thousands of them (not sure if it was during a conference call)... but this is really not the point. If a company does really require device encryption (most don't), it uses Blackberries. The security features in EAS (and subsequently the iPhone) are neither tried and tested (they are simply too new, even Windows Mobile 6.1 devices were not fully supporting them until a patch released in March 2009 fixed most issues) and, as the article clearly states, it is fully up to the device manufacturer to support them and ensure the status information given by the device is truthful... setting a policy that can't be enforced is pointless.
Well said.
Frustrating as hell, but well said.
Pre 3.1 OS phones were indeed lying to the policy enforced servers they were attached to. This wouldn't have cropped up as an issue if that wasn't the case, because pre 3GS phones would never have been allowed on the server in the first place.
1. Apple licensed Active Sync... so they should know what policies can be set against a device and comply. Especially given they want traction in the Enterprise space. Enforcing Encryption is a pretty big one these days. They seem to be going down that path with the 3GS and the 3.1 OS. Unfortunatley it will probably upset some people who are not ready to upgrade their year old HW in an Enterprise environment.
2. Microsoft...Why put in a "policy" that can be ignored??? That, I imagine, is very frustrating to admins trying to secure the enterprise.
Bzzzt. Wrong, Apple disabled tethering for everyone who wasn't on an Apple approved network. And that means many of those with a full price unlocked phone. That was a huge screw up.
Could you elaborate?
I am tethering now.
Improved support for Microsoft's Exchange Server's security policy features, delivered in the iPhone 3.1 firmware update, has left some users angry after discovering that their mobile device is no longer compatible with the policy defined by their company.
At issue is Apple's iPhone client implementation of Exchange ActiveSync, the Microsoft specification Apple licensed last year in order to provide official support for Exchange Server sync to the iPhone and iPod touch.
EASy to wipe
EAS defines not only how Exchange server syncs data to mobile clients, but also involves remote management features like remote wipe and security policy such as mandating that all devices be set to use a PIN to lock the screen when not in use.
Microsoft has evolved EAS over time, adding new options that allow Exchange admins additional control over the devices they choose to support. For example, in Exchange 2007 Service Pack 1, Microsoft added a new security policy option to require device encryption on mobile devices in order to support a new feature of Windows Mobile 6.0.
With file level device encryption, administrators can rapidly remote wipe a lost or stolen device, minimizing the risk of its data falling in the wrong hands. Without device encryption, a remote wipe takes longer because the remote device must zero all of its files. This makes it more likely that a thief could interrupt the wipe process, although once a phone is stolen, a savvy thief can disable its network connection and attempt to prevent any remote wipe from ever occurring.
Client-side EAS
Client manufacturers who license EAS from Microsoft, including Apple, Palm and Sony Ericsson, can implement the EAS specification on their client devices however they like. For example, the Palm Pre's Exchange support currently doesn't support security policy involving PIN use or remote wipe at all. Even Microsoft's own Windows Mobile 5.x implemented support for EAS differently than the current WiMo 6.x.
For example, under WiMo 5, EAS remote wipe couldn't also clear any data stored on an installed SD Flash card. Since most WiMo phones shipped with very little included storage, any important data was most likely kept on this impossible to wipe Flash memory.
This effectively meant that Exchange admins simply could not really wipe a WiMo 5.0 phone, even though the devices were described as supporting a form of remote wipe. That detail didn't stop pundits from favorably comparing WiMo 5.x's ineffectual wipe with the lack of any remote wipe feature on the original iPhone up until the release of the 2.0 firmware.
Policy respect
An Exchange server has no way to demand that clients obey all of its security policies; it has to trust that client devices respect them. When administrators specify a given policy on the server, mobile devices that fully support those feature options will stop working if the server-side policy settings raise the bar beyond the devices' capabilities.
That's what happened to many iPhone users who upgraded to iPhone 3.1 only to discover that their device stopped syncing with any Exchange Servers using the default "RequireDeviceEncryption" policy set to "True." Only the iPhone 3GS and the newly released 32 and 64GB iPod touch models support this hardware encryption feature; earlier models of the iPhone and iPod touch do not, and subsequently, their expanded support for Exchange policy settings forced them to no longer work.
In order for affected iPhone 3.1 users to reestablish a connection with Exchange, server-side administrators need to create a policy exception (for either that user or the entire server) which will allow connections to mobile devices that do not support device encryption. This was the status quo prior to Exchange 2007 SP1, which introduced the policy option, so it really isn't a drastic reduction in security as some have suggested. It involves unchecking a box and clicking OK (below).
The only other alternative is for those users to either upgrade to phone hardware that meets the minimum requirements configured on their company's Exchange Server, or downgrade back to iPhone 3.0 and simply ignore the security policy set by their company. The reason for the change on Apple's end is to comply with legal security requirements such as HIPAA, enabling the new iPhone 3GS to be suitable for approval in secure enterprise environments such as within the healthcare industry.
Oh the humanity
This change in the iPhone 3.1 update was poorly communicated to users by Apple, which should have at least alerted users of the potential impact of the upgrade during the installation process. The same update also quietly disabled tethering support on AT&T for certain users who had enabled the software feature against the terms of their AT&T contract.
The result was confusion and frustration by users, many of whom lack any capacity to motivate their company's Exchange admins to help them understand what had happened, let alone accommodate them with security policy changes from the default settings many Exchange Server shops never bother to change.
Similar security policy problems have resulted in problems for Mac users. Windows Server introduced changes that broke compatibility with existing clients while trying to enhance the network's security profile in tandem with the launch of Vista, for example. Support for alternative platforms like the iPhone and the Mac is not Microsoft's top priority, of course. However, Apple's increasing popularity among consumers, particularly among executives and mobile road warriors, has helped to promote improved support for Apple clients in many Windows-oriented companies.
Still, when unexpected things happen, many pundits are ready revile Apple's security credentials and denounce the company in scathing terms. Writing for InfoWorld, Galen Gruman stated Apple had "betrayed the iPhone's business hopes" and accused the company of misrepresenting the security profile of its iPhone devices, based on the speculation that iPhone 3.0 software must have "lied" by reporting that it was performing encryption prior to the update.
The problem with proprietary standards
In reality, iPhone 3.1 simply improved its support for EAS's defined security policy options, with unfortunate results for anyone who wanted to sync with an Exchange Server set to the default policy settings that happened to exclude their model of iPhone.
The proprietary nature of EAS, along with its constantly changing specifications tied to Microsoft's business decisions rather than industry consensus, creates a problem for consumers who want competition and choice along with the assurance that the phone they buy will work with their company's servers.
Right now however, the enterprise messaging industry's leading vendors have no desire to craft an open standard for mobile sync. Instead, RIM is promoting its own BlackBerry Enterprise Server product, which rakes in profits, while Microsoft is working to establish EAS as a way to anchor its dominance in corporate email with Exchange Server.
Imagine if Palm had paid Apple for the rights to sync the Pre with iTunes, but that part of the deal required Palm to only support features Apple allowed. This wouldn't be ideal or open. On the other hand, it's challenging for community consensus to build open standards that don't hamper the potential for innovation. Emerging web standards are a great example of finding a common ground in between, where vendors can innovate with different engines and browsers that also implement common, compatible features.
Whether something similar will ever happen in the mobile world remains to be seen. Apple is rapidly becoming a significant player in the smartphone industry, having passed Microsoft's combined Windows Mobile market share. With so many iPhone users, Exchange administrators have more reason than ever to accommodate them.
Apple is also taking its first real opportunity to enter the enterprise market seriously, and iPhone 3.1 is evidence of that, even if it results in short-term pain for some users right now. To help, Apple has revised its iPhone 3.0 Enterprise Deployment Guide (PDF) to include the new changes in iPhone 3.1.
Without much life left in its own mobile platform, Microsoft is likely to become increasingly supportive of third party mobile platforms on Exchange, and could someday even release EAS as an open specification to prevent a rival, alternative open specification from being launched.
Microsoft is actually making some use of the Open Mobile Alliance Device Management (OMA DM) protocol, which is also used by Symbian and in mobile device management tools sold by IBM. OMA DM is an offshoot to the SyncML consortium. Apple hasn't attempted to support SyncML since the original version of iSync, and neither the iPhone nor Android seem to be paying any attention to OMA DM.
[ View this article at AppleInsider.com ]
I thought that this matter was addressed a couple of days ago.* As my IT guys said, "Doesn't anybody read (manuals) anymore?"?
* http://news.cnet.com/8301-13579_3-10354209-37.html
? http://manuals.info.apple.com/en_US/...ment_Guide.pdf
Could you elaborate?
I am tethering now.
http://discussions.apple.com/thread....art=0&tstart=0
I can't quite tell from the writing of the article if Prince is an apologist for Apple on this issue, or not...
Pre 3.1 OS phones were indeed lying to the policy enforced servers they were attached to. This wouldn't have cropped up as an issue if that wasn't the case, because pre 3GS phones would never have been allowed on the server in the first place.
This was my understanding of the issue as well, but I don't see that claim addressed in the article.
I can't quite tell from the writing of the article if Prince is an apologist for Apple on this issue, or not...
Pre 3.1 OS phones were indeed lying to the policy enforced servers they were attached to. This wouldn't have cropped up as an issue if that wasn't the case, because pre 3GS phones would never have been allowed on the server in the first place.
I can tell -- he is. But I can tell that Grman's piece was also unbalanced. This is even more a failure of Exchange security than it is of Apple's. Basically this exposes that MS does nothing to verify that devices are actually following their security requirements (or at least not enough). MS should have a certification process for devices with some teeth. Of course, this in no way excuses Apple -- Apple would have failed such a certification process.
On a related note, I understand that there are cases where this type of security truly is needed. Some people really do carry around very sensitive information on their phones and are therefore targets of spies, thieves, etc. But there are also some corporate security people out there who push security way, way too far. I work for such a company. The security and IT guys have a totally distorted view of the benefits/costs of protecting the e-mails of company employees. There is a far greater risk of competitors learning company secrets through overheard conversations in a restaurant or on the train than from a lost iPhone, and frankly our "secrets" aren't that interesting or useful to competitors anyway.
So there's a lot of blame to go around here -- MS, Apple, and over-zealous security freaks.
I can't quite tell from the writing of the article if Prince is an apologist for Apple on this issue, or not...
Pre 3.1 OS phones were indeed lying to the policy enforced servers they were attached to. This wouldn't have cropped up as an issue if that wasn't the case, because pre 3GS phones would never have been allowed on the server in the first place.
Either you don't understand, or you are deliberately misleading.
Pre 3GS phones WOULD have been allowed on the server AND still are. If the client (phone) doesnt support a particular server implemented protocol, the server DOES NOT disallow access. This is the whole issue. It is only when the client DOES support a particular protocol, but can't act on that protocol, that the client is disallowed access.
3 scenarios to put it simply:
1) (server): I RequireDeviceEncryption!
(client): I understand, and I have the ability to adhere to your request!
Result: Win-Win (ahem) and client gets access. This is the ideal situation.
2) (server): I RequireDeviceEncryption!
(client): I know what you are asking, but I can't do that because I lack the ability
Result: Client does not get access.
3) (server): I RequireDeviceEncryption!
(client): I don't know what you are asking me to do.
Result: Client DOES get access, because it is up the the CLIENT to support the security protocols for them to be effective.
This might not be what you expect, but this is how it works.
Every iPhone and iPod Touch with 3.0 software falls (and has always fallen) into category 3, so they get access. There is no lying, there is nothing misleading about it. The clients just didnt have the functionality to understand the server's request. This choice on Apple's behalf (whether technical or not) had the benefit of allowing the iPhone/iPod to have access to servers that say "I RequireDeviceEncryption!" (like MANY other devices out there), but it also meant that these iPhones were not able to be used in security concious organisations that require devices to be up to a certain functionality spec (which require any client on the network to understand the request for "RequireDeviceEncryption" using a whitelist or something similar - this is not normally done, and these are not the servers that are giving the "new" problem talked about in this thread).
With 3.1 software, the ability to understand the server saying "I RequireDeviceEncryption!" was given to all iPhone/iPod hardware that chose to upgrade. This brings ALL of these phones up to spec with "security concious" organisations that do more than just rely on EAS.
Now, if upgraded to 3.1 software, the 3GS and new Touch falls into category 1 above, and all other iPhone and iPod Touch fall into category 2. Any iPhone/iPod Touch (whether it has hardware encryption or not) that is still 3.0 remains in category 3.
There has been no lying or attempt to mislead. The problem lies with the shitty proprietry security protocols that allow access to clients that do not understand server requests, rather than requiring that all devices understand all requests (although admittedly this would require a lot of hardware upgrading, or some decent future planning for backwards compatability, something MS certainly isnt good at). The current system doesnt make logical sense to Joe Blow, and that is what has lead to this situation being blown so far out of proportion.
If you attack Apple for not including the ability to understand "I RequireDeviceEncryption!" earlier than 3.1, you must also attack the Palm Pre and every other device that STILL does not support (understand) this request, whether they have hardware encryption or not. It is certainly the exception, not the rule, for a smartphone to be up to this level of security today.
An honest question: I know there are a ton of iPhones out there, but how many are really being pressed into corporate use? Corporations wouldn't typically (stress typically) allow a BYO phone so a lot of the phones out there in consumerland wouldn't be relevant to this discussion.
when you set up Exchange you have to disable ActiveSync because it's on by default allowing anyone with a compatible phone to grab their email. Unless there is a need for strict security practices, a lot of organizations will leave it as is and let employees pull their email.
some other companies give people an extra allowance every month and tell them to buy their own phone
To me it seems there are a couple of issues...
1. Apple licensed Active Sync... so they should know what policies can be set against a device and comply. Especially given they want traction in the Enterprise space. Enforcing Encryption is a pretty big one these days. They seem to be going down that path with the 3GS and the 3.1 OS. Unfortunatley it will probably upset some people who are not ready to upgrade their year old HW in an Enterprise environment.
2. Microsoft...Why put in a "policy" that can be ignored??? That, I imagine, is very frustrating to admins trying to secure the enterprise.
When ActiveSync came out, MS was playing catch up to RIM because that's when BB's first started getting very popular. By design blackberries are still a lot more secure than any activesync devices.
Since no one upgrades everything at once, MS had to put a way for people to upgrade their Exchange and WinMo phones over time and still have everything work.
Bzzzt. Wrong, Apple disabled tethering for everyone who wasn't on an Apple approved network. And that means many of those with a full price unlocked phone. That was a huge screw up.
Could you elaborate?
I am tethering now.
To your response to the above:
http://discussions.apple.com/thread....art=0&tstart=0
So it is based on what you have read and not from personal experience?
Do you own an iPhone? I think not.
On a related note, I understand that there are cases where this type of security truly is needed. Some people really do carry around very sensitive information on their phones and are therefore targets of spies, thieves, etc. But there are also some corporate security people out there who push security way, way too far ... frankly our "secrets" aren't that interesting or useful to competitors anyway.
Couldn't agree more. I work for a publisher and, although we do share some "secrets" via email, there's nothing our competitors would learn from scanning our emails that would ever give them a noticeable edge in the marketplace. And really, how many of us are important enough to be stalked and robbed by a competitor. We'd like to think we're that important, but come on ...
deleted