Facebook are currently disputing the idea that they listen in on real-world conversations through over-reaching it’s permissions to access the microphone. Yes – users want the apps to access the microphone when actively recording video or using audio – but not when having a private conversation with someone in the ‘real world’ – with the phone off.
The biggest issue I have with this is the denial. They explicitly denied listening via the core Facebook app; and also their messenger app. However, we’re all using a variety of additional apps curated and managed by Facebook.
Facebook.
Messenger.
Whatsapp. (need microphone for audio/video calls)
Instagram. (needs microphone for video)
It’s not practicable to manage access or revoke access based on individual use. What’s required here is for iOS/Android to provide better UX around which apps are accessing which features each time they’re accessed. In the same way we have the battery monitor, the OS providers should be providing an audit log of what exactly your phone has been doing.
I’m not sure what privacy campaigners are calling it yet – I need to have a read up and familiarise myself. I’d call it overreach. We should be protected from such overreach; and the OS creators need to provide better tools by default, rather than requiring rooting and/or technological expertise to understand what a device that you’re paying for and is with you for practically 24 hours a day is doing with your data.
One of the things I’ve always loved doing is creating throwaway apps that solve very simple problems. Historically these have been to educate me on the ‘art of the possible’, rather than actually produce something workable. I’d always fall at a hurdle, or find a gap in my learning that would take me off on a tangent – the next gap to try and fill. It’s been a lifetime of constant learning, challenging myself to fill more and more of the gaps with oodles of potentially useless information.
Ionic Framework
Luckily (or with amazing foresight), lots of this information is now becoming appropriate and useful.
As an example, a few years ago I was working at an organisation who got hit with a DDoS. The site was down for 36 hours before we got it back up, and I learnt an awful lot then that I thought would be pertinent for my future career. I discovered low level things about networking that I didn’t think much of learning at the time, yet it’s these small pieces of knowledge that make up the experience I have now.
I remember discovering Ionic around 2013 and following its creator, Max Lynch, on twitter. We exchanged a few platitudes and he helped me out with a couple of early gotchas. It was a great introduction to a community, and another advocate of my preconception that HTML5 would be ‘good enough’ for native apps – It wasn’t long after the HTML5 LinkedIn post that blasted the idea that HTML5 was the future.
I’d also been working on an app for the Oxford & Cambridge boat race. I was adamant that using the accelerometer functionality in Cordova, it was possible to mimic a rowing motion and use your phone like a wii-mote. I prototyped a very simple solution and touted it round a few app development companies. They mostly laughed and suggested that I specified either iOS/Android, or double my costs. I then took it to the excelled team at Inviqa, who despite not having long started their app development journey at the time, agreed that I’d seen the potential and were able to complete the project under the budget that we’d originally ballparked.
HTML5 FC 1 – 0 Native FC
Since then I’ve played with Ionic at each stage of its development. It helped me establish my understanding of AngularJS, and been probably the exclusive partner to my investigations into Angular2+. I don’t ply my trade as a developer, but as a technical generalist – and the concepts, documentation and community around Ionic have been superb in offering the support, patterns and scaffolding to help shape the new propositions that I nurture.
It was with fair trepidation that I ended up advocating a relatively straightforward application at my place of work; for internal use only and running on Ionic2. I’ve had my battles (with myself, not the framework) in deciding on my application structure, but I’ve got there. I have a wonderfully clean and well organised application that fulfils the role of PoC admirably. The code is clean and well written enough for me to be comfortable in handing it over to a more established developer. The README.md file could simply state: “Built using https://ionicframework.com – see the docs! (Of course the documentation is slightly more comprehensive than that…)
With the advancement of web APIs (see https://whatwebcando.today/) enabling frameworks like cordova to start to get ‘native’ functionality ‘in the browser’ and Ionic’s support for building Progressive Web Apps (PWAs) out of the box, I can see a very bright future for HTML5. My biggest concern is that whilst competing on functionality may be the sexier opportunity, the HTML5 apps community can design these new APIs with the UX around security built in from the start.
