A month or two ago I read an eye opening presentation called Shining the Light on Flashlight and the Security of Thousands of Mobile Apps. It’s worth a quick read, especially pages 42 onwards, where the risks of flashlight apps are unveiled. Although the presentation focuses on security risks among the most popular Android and iOS apps, I noticed that pretty much all of the Windows Phone flashlight apps have similarly questionable requirements.
Why does a flashlight need to know where I am? Or have access to my files? Or send a raft of data all over the place? Needless to say, I got rid of my flashlight app.
Fast forward a week or two, and I needed a flashlight (or a torch, as we say in the UK). I decided to use my screen, which was pretty week, and then it occurred to me that I could enable the flash on my camera while in video mode, which does precisely what a flashlight app would do, without the app. It’s not many more “clicks” than launching and enabling an app (especially if I use the hardware key for the camera), and achieves the same result. I don’t know how well this work on other platforms, but I’m struggling to see why it wouldn’t. Hope this helps someone.
Like a lot of people in the Microsoft partner community, I’ve been catching up with Lync this year and digging in to the finer details with a few of my colleagues. One thing we wanted to understand better was the routing between two users over a LAN, a private WAN, or some other connection where all the necessary network ports would be open. Would these clients communicate peer-to-peer? If so, does it always behave the same way, how is it accomplished and what might go wrong?
First, consider an organisation with offices across multiple floors or buildings. Lync may be a very effective means of connecting these employees despite their relatively close proximity. If this traffic can route locally it can be a big plus – especially if there’s lots of media traffic. Second, consider an organisation with multiple branches. They invested in private WAN links to connect these branches and don’t necessarily want to route Lync traffic over their internet connections if they can avoid it. For some organisations these will be non-issues, since Lync traffic is optimised for the WAN, but for other organisations this may be important – particularly if they’re in a part of the world where internet connections are slow or expensive (or both). So we went about testing this with the Lync 2010 client and Office 365 users (the behaviour is the same with Microsoft Online IDs or federated users).
Continue reading “Lync, Strings and Cans”