FunnyMonkey


Bill Fitzgerald

Bill Fitzgerald

When Will Apple, Google, and Microsoft Require Encryption For Educational Apps?

1 min read

Microsoft, Google, and Apple all maintain app stores with sections dedicated to education.

Unfortunately, within the EdTech space, many vendors lag behind broader industry standards around security - including basic things like encrypting connections and logins via SSL.

If Microsoft, Apple, and Google all started requiring basic encryption as a condition for continued inclusion in their respective marketplaces, vendors would up their game. All marketplaces already review apps as part of their approval process. A check for basic security practice for educational apps would improve the quality of the apps, and the quality of the services offered by vendors.

This wouldn't solve every issue related to privacy and security in edtech, but it would eliminate many of the obvious weaknesses.

So, Apple, Google, and Microsoft - how about it? When will you start requiring encryption for educational app developers?

, ,

0 stars 1 comment

For Google, at least, I think the question should be why are they pushing hard for security in other areas except in their education offerings. Google has not been afraid to ruffle some feathers when it comes to pushing what they believe is good security. Here are some recent examples:

1. Accelerating the end of SHA-1: This hash will expire in 2017. Right now the hash is still secure, but experts believe that it will be broken with relative ease. 2017 was chosen as a date to give certificate authorities plenty of time to use a new hash. 2017 is also not expected to be a time when SHA-1 will be broken. Google, however, will soon have Chrome issue some kind of warning that the site you are looking at is not secure because of the SHA-1 hash. Nobody else will be doing this, and SHA-1 is not yet a threat. However, Chrome will tell many users that certain websites are vulnerable when they are really not. It should also be noted that Google will be using the SHA-1 hash on their certificates. The difference is that Google's certificates are signed for a very short period of time, while the average certificate is signed for multiple years.

2. Releasing Bugs: Google made a lot of waves by releasing Windows bugs to the open before Microsoft released their patch. Google gave Microsoft something like 90 days to issue the patch. Microsoft did not issue the patch within this time frame, so Google went public with the bug. Not only did they go public, but they showed how the bug can be exploited. Microsoft claims the patch was going to go out in the next "patch Tuesday." By releasing the bug publicly, Google forced Microsoft into action, but they also opened up many computer users to attack by showing how the bug can be exploited.

3. Certificate Revocation: This is a pretty complicated issue unto itself, and I don't fully understand it myself. But, Chrome handles certificate revocation in a very different way. Most browsers have a protocol for revoking expired or bad certificates, thus preventing man in the middle attacks. Google claims that this system is flawed, and actively tells its users to turn of the certificate revocation protocol as it slows down the browsing experience. Google maintains its own list that it manually updates of bad certificates. There was a proof of concept of Chrome accepting a bad certificate. There is a lot of nuance to this argument, and Google does make some good points about security. You can read more about this here, https://www.grc.com/sn/sn-454.txt.

Bottom line, Google has taken a hard stance on security. They are not afraid of how they are perceived by the tech community at large as the fight for security is more important than popularity. It is interesting that they would go to such lengths for security aspects that are not so obvious to the average person. By taking a hardline with education apps and encryption, Google could improve security AND win a few popularity points.

Patrick, Mar 06 2015 on funnymonkey.com