Techtician @techtician - Tumblr Blog

Raeid Saqur lecture on p-hacking and multiple comparisons bias.

SSH key persistence in Mac OS Sierra

Codifying the fix for the plethora of techies who have been (or will be) going through this excruciating pain of ssh key persistence.

Add the following key step:

You will need to modify your ~/.ssh/config file to automatically load keys into the ssh-agent and store passphrases in your keychain.

Host * AddKeysToAgent yes UseKeychain yes IdentityFile ~/.ssh/id_rsa

#ssh

Contribute to teachings-ios-animation-playground development by creating an account on GitHub.

Easily play around with the Animation code in XCode Playground.

#Xcode Playground Animations

protobuf-setup - Python script for quick environment setup for using swift protobuf

A simple bash script for setting up your environment for tinkering with Swift protobuf and python.

Nothing more satisfying than seeing your code in action: Ecobee3 with Siri and HomeKit capability.

#homekit #ecobee3 #IoT #smarthome

Decided to show off my deep web mining python script in action - what you see is of course a tiny sample of its capabilities.

#python #Quant #finance

Enterprise Mobile Keywords Explained

Chatting with a few friends unfamiliar with some of the common technical terms used in the enterprise world (e.g.: banking, educational institution realm) for EMM (case in point), may sound like nonsensical, esoteric jargons to the uninitiated ears.

Hence, wanted to quickly throw down some of the key ones that I can think on the top of my head right now - basically a brain dump/codification of hard earned knowledge from my days as ‘Mobile Enterprise Thought Leader’ (yeah, sounds heavy doesn’t it?) and enterprise consulting. (Note: definitions are compiled from the web)

EMM: Enterprise Mobility Management

Enterprise mobility management suites enable organizations to integrate and manage mobile devices in their IT infrastructures.

EMM Is the "Glue": EMM is the starting point, if you are planning to opt into managing anything on a mobile platform. Because it is the presumptive foothold agent, EMM is the logical choice to broker policies for other services and tools on the platform. EMM provides a common, cross-platform baseline to set, contain, validate, enforce and update device policies for gateways, proxies, VPNs, network access controls (NACs) and certificates, application certificates, content and rights management systems, IAM, version controls, backups, system updates, and device initialization, as well as wipe and countless other practice areas that enter the mobile space from adjacent markets.

As a single point of policy and accountability, EMM provides the opportunity to avoid agent bloat, which is so often seen on PCs, where an endless parade of add-on utilities steals local resources, duplicating and complicating the task of policy coordination for system administrators. PCs have the resources to cope with this situation; however, users of small mobile devices and particularly BYOD cannot succeed with so much unnecessary complexity.

Security: EMM Executes File-Level Protection at the Edge

Protecting enterprise data on mobile devices has traditionally been based on a multi-pronged approach of encryption of data at rest, in use and in motion, as well as device- and app-level policies, such as screen lock timeouts, PIN enforcement and "open in" restrictions. However, these oblique protection approaches are incomplete, because once data leaves managed devices and networks, such protection schemes are rendered moot. Users can and often do get around such controls by emailing enterprise data to outside parties or personal email accounts, or copying data to their PCs, where open-in restrictions are absent. In response, there is a growing need to protect data intrinsically, and/or implement a rights-management-based approach to mobile data protection.

File-level encryption products encrypt the individual files themselves (rather than simply encrypting stored data and network tunnels) and facilitate managed file access through PKI, such that data can be protected wherever it is stored or accessed. No one without the encryption keys can access files protected in this manner.

Rights management products extend IAM frameworks to provide control over file operations for frequently used file types, in addition to file access. These products enable an organization to restrict who has permissions to read, edit or delete a file, or forward a file via email. Such products typically also facilitate file-level encryption as part of their mobile data protection schemes. Effective data classification is thus critical in making a rights management approach work in a given environment.

Some EMM vendors are building file-level protection and/or rights management capabilities as adjuncts to their core products, whereas others are enabling file-level protection by synergistically and tightly integrating their EMM systems with general-purpose identity and access management products. As with device-, app- or content-level policies, EMM should provide a single point of administration for encryption and access/rights policies where these capabilities are present.

MDM: Mobile Device Management

MDM is the key enabler to the glue of EMM. MDM has changed from being a stand-alone product category doing basic policy management, such as passcode enforcement and device wipe, to a key required feature within EMM suites. MDM controls have evolved across all OSs and have expanded into traditional desktop management with Windows 10 and OSX. Each OS offers similar basic controls; however, advanced controls — such as OS version control for Windows 10 devices, automatic device staging for iOS with Device Enrollment Protocol (DEP), and the ability to apply different policies to work and personal environments with Android for Work and Samsung's Knox — vary greatly.

MAM: Mobile Application Management

MAM facilitates the deployment and operational life cycle management of mobile apps. This includes administrative push, the user-initiated deployment and updating of custom and public (app store) apps, and the management of associated app licenses. User-initiated deployment is facilitated via an enterprise app store, which is typically presented as a web-based portal or a mobile app. License management should support the major enterprise or volume-licensing mechanisms, such as Apple's VPP. MAM also includes the ability to identify or tag apps as "managed" enterprise apps (versus personal apps in BYOD and corporate-owned, privately enabled [COPE] use cases), apply management and security policies to these apps, and selectively wipe them from the device, along with any associated data.

Policies commonly applied to enterprise apps include security policies and DLP policies, such as:

Require initiation of per-app VPN connections on app launches

Encrypt enterprise app data at rest (or at the file level, in some cases), sometimes with stronger encryption than that used by the underlying OS

Restrict "open in" and similar app data exchange to only managed (enterprise) apps

Restrict cut/copy/paste

Require conditional launch or access — for example, device in approved state, no jailbreak or rooting detected.

Differentiating features of MAM manifest in several areas. Enterprise app stores, for example, range from rudimentary to highly functional, some approaching the usability and features of major commercial app stores, such as Apple's App Store or Google Play. At the low end, these products may be little more than rudimentary web portals or simple apps that present all available apps to all users, provide no feedback or app-rating mechanisms, and are poor tools to help users discover apps.

Moreover, differentiation can manifest in OS support or the support of different MAM-enablement mechanisms. App policies can be applied by leveraging one of three common mechanisms:

Native OS MAM APIs

Proprietary SDKs compiled into apps during development

App wrappers (code injection into the binary, post development)

An EMM vendor may support all three mechanisms across all major mobile OSs, while another supports only a subset. As an example, a vendor may include support for Apple's built-in MAM APIs, but no support for Google's Android for Work built in MAM APIs.

MI (Mobile Identity) and Access

Users no longer have a single device. They now frequently have a smartphone, a tablet and a laptop. More often than not, they want to use devices as part of a BYOD program. As a result, it has become important to determine not only who is connected to the network, but also whether they are connected with a corporate-authorized device. This is why MI is a recognized key pillar in EMM. MI is typically done using digital certificates, but can also be accomplished with other technologies, including biometric and token-based authentication.

Initial convergence of EMM with IAM tools has been observed in the industry. This has resulted in several EMM vendors enabling IAM functionality, such as SSO and acting as identity providers. Several identification as a service (IDaaS) vendors now offering basic EMM functionality.

The next wave of mobile identity is context-based, with authentication identifying not only the user and device, but also where and how a user connects to the network (that is, in the office, at home, on a public Wi-Fi or out of the country), and based on these contextual values, granting the user different levels of access. Over the next three years, context-based mobile identity is expected to become standard functionality within EMM products.

MCM: Mobile content management

EMM tools use MCM to manage access rules for content distribution on mobile devices. The MCM function has three fundamental roles:

Policy enforcement: The EMM tool can enforce policies down to individual files, including device-independent encryption keys, authentication, file-sharing rules and copy/paste restriction. Examples include conditional access to attachments in email, files synced with a back-end repository or files synced with a cloud repository.

Content push: The EMM tool enforces rules for push-based file distribution, replacement and deletion.

Integration: Beyond basic file access policies, MCM tools are adding mobile compatibility for third-party rights management systems, as well as enterprise data loss protection (DLP) and enterprise digital rights management (EDRM) infrastructures.

Advanced MCM tools are also often full-featured enterprise file synchronization and sharing (EFSS) suites, offering additional functionality, such as collaboration and more advanced policy management, but are bundled as part of the EMM product suite.

Containment

EMM tools provide methods to encapsulate MDM, MAM, MI and/or MCM in quarantined environments designed to isolate business from personal usage, and to facilitate data and function isolation on shared multiuser devices. This capability is increasingly provided by mobile OS APIs. However, when built-in APIs are not available or are undesirable to use, containment within EMM tools is necessary to segment enterprise data. Containment can be a stand-alone, self-contained application, such as a personal information management (PIM) client. This capability can improve cross-platform compatibility by removing app dependence on specific APIs, and can add self-defending/hardening features that are particularly advantageous for apps running on unmanaged devices — that is, no MDM profile is installed. Containment technology can include:

Preconfigured apps: EMM vendors provide proprietary mobile apps or integrate with particular third-party apps to provide enhanced levels of manageability and security for commonly requested functions, such as email calendaring and contact management, browsing, and file sharing.

Application extensions: These apply policies to applications through the use of a software development kit (SDK) or by wrapping individual apps with a security and management layer.

UEM: Unified Endpoint Management

Organizations have historically used different management tools for PCs and mobile devices. IT organizations are increasingly consolidating their PC and mobile device support groups and treating their devices as "endpoints." Meanwhile, the PC and mobile architectures continue to fuse together, blurring the boundaries between the EMM and CMT capabilities. This trend continues with Windows 10, which added to the MDM APIs introduced with Windows 8.1. It presents organizations with the potential to manage PCs with either EMM tools or agent-based CMTs. Large organizations will adopt both approaches, based on user segmentation. As Win32 applications decline in number, organizations will manage PCs, smartphones and tablets with the same toolset. This is easier said than done, as Win32 applications still provide many critical functions for most organizations today. It will take several years for most organizations to get to this point. Once organizations have retired their Win32 applications, the descriptor "unified" will not be necessary; at that point, the term will be "endpoint management."

UEM is not limited to PCs, tablets and smartphones. Smart devices, broadly grouped as part of the IoT, will increasingly become included in UEM. Devices such as Apple TVs, printers and smartwatches are identifiable examples of IoT devices managed by EMM tools. However, not all IoT objects will fall under the realm of EMM tools. Some devices may be managed directly by manufacturers. Other types of devices will have proprietary management tools. And many devices will not need to be managed at all. However, it is clear that the diversity and number of devices will continue to grow, and IT organizations must be ready.

#EMM MDM MCM EnterpriseMobility Mobile

Machine Learning - Backpropagation Algo using Octave/Matlab

One of my students was having difficulty with the week 5 backprop algo exercise in Stanford’s Machine Learning course (Andrew Ng). I added the (vectorized implementation) solution here:

https://github.com/raeidsaqur/coursera-machine-learning

Please use only as a helping guide, as simple copy pasting won’t help the main cause, i.e. learning!

Shoot me questions on Twitter @RaeidSaqur

#machinelearning #ML backpropagation

ML - AMA with Dr. Geoff Hinton

As some of my close friends may already know, I’ve been working on some machine learning stuff as pet side project for a few weeks now. Wanted to share this random byte of interested answer from Dr. Geoff Hinton, UofT professor (yay - go Toronto!) and one of the foremost figures in the ML realm. Got this from my extremely bright and talented friend Ivan Cheung (of Singspiel fame).

Quoting the excerpt for your reading plea’z’ure:

1. Are we any closer to understanding biological models of computation?

G.H.: I think the success of deep learning gives a lot of credibility to the idea that we learn multiple layers of distributed representations using stochastic gradient descent. However, I think we are probably a long way from understanding how the brain does this.

Evolution must have found an efficient way to adapt features that are early in a sensory pathway so that they are more helpful to features that are several stages later in the pathway. I now think there is a small chance that the cortex really is doing backpropagation through multiple layers of representation. The only way I can see for this to work is for a neuron to use the temporal derivative of the underlying Poisson rate of its output to represent the derivative of the error with respect to its input. Using this representation in a stack of autoencoders makes the idea that cortex does multi-layer backprop not totally crazy, though there are still lots of other issues to solve before this would be a plausible theory, especially the issue of how we could do backprop through time. Interestingly, the idea of using temporal derivatives to represent error derivatives predicts one type of spike-time dependent plasticity for bottom-up connections and a different type for top-down connections. I talked about this at the first deep learning workshop in 2007 and the slides have been on the web for 7 years with zero comments. I moved them to my web page recently (left-hand column) and also updated them.

I think that the way we currently use an unstructured "layer" of artificial neurons to model a cortical area is utterly crazy. Its just the first thing to try because its easy to program and its turned out to be amazingly successful. But I want to replace unstructured layers with groups of neurons that I call "capsules" that are a lot more like cortical columns. There is a lot of highly structured computation going on in a cortical column and I suspect we will not understand it until we have a theory of what its for. My current favorite theory is that its for finding sharp agreements between multi-dimensional predictions. This is a very different computation from simply adding up evidence in favor of a binary hypothesis or combining weighted inputs to compute some scalar property of the world. Its much more robust to noise, much better for dealing with viewpoint changes and much better at performing segmentation (by grouping together multi-dimensional predictions that agree).

2. Are you aware of any studies that validate deep learning in the neuroscience community?

I think there is a lot of empirical support for the idea that we learn multiple layers of feature detectors. So if thats what you mean by deep learning, I think its pretty well established. If you mean backpropagation, I think the best evidence for it is spike-time dependent plasticity (see my answer to your question 2).

3. What is your most controversial opinion in machine learning?

G.H.: The pooling operation used in convolutional neural networks is a big mistake and the fact that it works so well is a disaster.

If the pools do not overlap, pooling loses valuable information about where things are. We need this information to detect precise relationships between the parts of an object. Its true that if the pools overlap enough, the positions of features will be accurately preserved by "coarse coding" (see my paper on "distributed representations" in 1986 for an explanation of this effect). But I no longer believe that coarse coding is the best way to represent the poses of objects relative to the viewer (by pose I mean position, orientation, and scale).

I think it makes much more sense to represent a pose as a small matrix that converts a vector of positional coordinates relative to the viewer into positional coordinates relative to the shape itself. This is what they do in computer graphics and it makes it easy to capture the effect of a change in viewpoint. It also explains why you cannot see a shape without imposing a rectangular coordinate frame on it, and if you impose a different frame, you cannot even recognize it as the same shape. Convolutional neural nets have no explanation for that, or at least none that I can think of.

4. Can we ever hope to train a recognizer to a similar degree of accuracy at home?

G.H.: In 2012, Alex Krizhevsky trained the system that blew away the computer vision state-of-the-art on two GPUs in his bedroom. Google (with Alex's help) have now halved the error rate of that system using more computation. But I believe it's still possible to achieve spectacular new deep learning results with modest resources if you have a radically new idea.

5. Are there diminishing returns for data at Google scale.

It depends how your learning methods scale. For example, if you do phrase-based translation that relies on having seen particular phrases before, you need hugely more data to make a small improvement. If you use recurrent neural nets, however, the marginal effect of extra data is much greater.

6. What have your most successful projects been so far at Google?

G.H.: One big successs was sending my student, Navdeep Jaitly, to be an intern at Google. He took a deep net for acoustic modeling developed by two students in Toronto (George Dahl and Abdel-rahman Mohamed) and ported it to Google's system. This gave a significant improvement which convinced Vincent Vanhoucke that this was the future and he led a Google team that rapidly did the huge amount of engineering needed to improve it and deploy it for voice search on the Android. That's a very nice feature of Google.

When I was visiting Google in the summer of 2012, I introduced them to dropout and rectified linear units which made things work quite a lot better. Since I became a half-time Googler in March 2013, I have given them advice on lots of different things. As one example, I realised that a technique that Vlad Mnih and I had used for finding roads in aerial images would be very useful for deciding whether a sign is actually the number of a house. The technique involves using images at several very different resolutions and Google has made it work very well.

The two ambitious projects that I have put the most work into have not yet paid off, but Google is much more interested in making major advances than small improvements, so that's not a problem.

7. Your Coursera course on neural networks was a huge benefit to me as a follow up to Andrew Ng's introductory Machine Learning course. It was only a few years ago, but there have been a ton of interesting research areas that have cropped up in the time since you created the course. Are there any topics you would add to that course if you redid it today? Any content you would focus on less?

Training of deep RNNs has recently seemed to get much more reasonable (at least for me), thanks to RMSProp, gradient clipping, and a lot of momentum. Are you going to write a paper for RMSProp someday? Or should we just keep citing your Coursera slides? :)

G.H.: Just keep citing the slides :-)I am glad I did the Coursera course, but it took a lot more time than I expected. Its not like normal lectures where its OK to make mistakes. Its more like writing a textbook where you have to deliver a new camera-ready chapter every week. If I did the course again I would split it into a basic course and an advanced course. While I was doing it, I was torn between people who wanted me to teach them the basics and a smaller number of very knowledgeable people who wanted to know about advanced topics. I handled this by adding some advanced material with warnings that it was advanced, but this seemed very awkward.In the advanced course I would put a lot more about RNN's especially for things like machine translation and I would also cover some of the very exciting work at Deepmind on a single system that can learn to play any one of a whole suite of different Atari video games when the only input the system gets is the video screen and the changes in score. I completely omitted reinforcement learning from the course, but now it is working so well that it has to be included.

Interesting Excerpts:

The cortex is pretty much the same all over and if parts are lost early, other parts can take on the functions they would have implemented. This suggests its really worth taking a bet on there being a general purpose learning procedure.

The brain is clearly using distributed representations.

The brain does complex tasks like object recognition and sentence understanding with surprisingly little serial depth to the computation. So artificial neural nets should do the same.

The brain has about 1014 synapses and we only live for about 109 seconds. So we have a lot more parameters than data. This motivates the idea that we must do a lot of unsupervised learning since the perceptual input (including proprioception) is the only place we can get 105 dimensions of constraint per second.

Roughly speaking, spikes are noisy samples from an underlying Poisson rate. Over the short time periods involved in perception, this is an incredibly noisy code. One of the motivations for the idea of dropout was that very noisy spikes are a good way to get a very strong regularizer that can help the brain deal with the fact that it has thousands of times more parameters than experiences.

Over a short time period, a neuron really is a binary all-or-none device (so far as other neurons are concerned). This was one of the motivations behind Boltzmann machines. Another was the paper by Crick and Mitchison suggesting that we do unlearning during sleep. There now seems to be quite a lot of evidence for this.

References

1. http://www.cs.toronto.edu/~rsalakhu/publications.html

2. http://www.cs.toronto.edu/~rsalakhu/papers/dbm.pdf

3. http://www.cs.toronto.edu/~rsalakhu/papers/DBM_pretrain.pdf

#machinelearning #deep learning #AI

Facebook iOS tools: Remodel, Retain Cycle Detector

Recently announced at the F8 Developer conference by Facebook.

Video link

Transcript of talk link

Github links for Remodel and Retain Cycle Detector.

#ios development #tooling

HomeKit Helper Framework

Apple’s IoT answer: HomeKit - has been growing and gaining much traction. Today, it’s almost given that any connected/smart home product makers will ensure their products’ compatibility with HomeKit. Consequently, the subset of iOS developers using this framework is steadily growing. A cursory search for ‘HomeKit’ on stack-overflow or Apple dev forum is a testament to that. A budding dev community indeed makes development and problem solving much easier as you get to use the collective intelligence of many. However, life wasn’t that easy when working with HomeKit at its nascent period. Like any first iteration of a framework, HomeKit was tremendously glitchy. Help wasn’t readily available as the community was small.

Having working with HomeKit from its nascent beginning, I am well-acquainted with the framework’s pain-points, and certainly empathize with the amount of plumbing needed sometimes to do a simple task.

I have shared a (insignificant) HomeKit helper framework to alleviate that - a trivial contribution.

The framework exposes utility APIs abstracting tasks like looking up accessory serial numbers, filtering out characteristics, accessories by manufacturer, action sets by accessories etc.

The framework also include recursive description functions to aid debugging.

To elucidate, calling [HomeKitUtility detailedDescriptionOfHMHome:aHome] will recursively print out all HomeKit entities under that home. If the full detail is not necessary, descriptions of a room or an accessory can be printed out likewise too.

Checkout the framework on github. You can reach out to me with comments and/or questions on Twitter.

#homekit #IoT #ios developers

Using FB Chisel for lldb debugging

Facebook Chisel is a collection of lldb commands to assist debugging of iOS apps.

Simply follow the steps outlined for installation. Here, I wanted to quickly outline where to look for your fblldb.py file to add its path to the .lldbinit file.

Open the .lldbinit file using your favourite text editor, for e.g. (using terminal):

XCode: open -a XCode ~/.lldbinit

Sublime Text: subl ~/.lldbinit

Append the following at the very end:

## Commmand from FB Chisel command script import /usr/local/opt/chisel/libexec/fblldb.py ## End of Commands from FB Chisel

Test Install

Type ‘lldb’, hit enter. Then type ‘help’ once in the lldb prompt. You should be able to see a slew of commands under the line: ‘Current user-defined commands:’.

Type ‘help border’ and you should see something similar to this:

#XCode LLDB Debugging iOS

Home Automation: HomeKit Enabled Door Lock Setup

This is the first installation of a series I’m hoping to write as I continue to review connected home products. The video demonstrates the lock working after a lengthy setup period.

The need for an aggregator platform, medium etc. becomes painfully more obvious as you continue to add more connected devices. Apple, Google and a plethora of other players are all competing hard in this space (ecosystem adoption).

I am pretty satisfied with Schlage Sense - so far working great and serving its purpose beautifully. The life-time warranty adds to your peace of mind. One thing to note is that you need to have a 3rd generation and above Apple TV in order for the Siri (HomeKit) commands to work remotely - however, this can be circumvented by downloading and using the Schlage Sense app.

Caution: the lock installation is relatively easy when replacing existing door locks (with all the required holes already in place), but if you are trying to add the lock to a door with no existing locking mechanism, then I’d be wary. I wouldn’t expect an average tech Josh to be able to install this; in fact, I’d advise against it, as you may very well end up destroying your door frame (especially if it’s a thinner frame) if you are not extremely precise - better let a lock-smith handle it, and you will thank me later.

I found the installation guide booklet very poor. It’s tedious, too wordy and hard/boring to follow. More (colour) pictures and concise wording would help.

Overall verdict: 4 out of 5 stars. Once you get over with the installation phase - you will be very impressed and happy with the product.

Got questions? Reach out to me on #Twitter: @RaeidSaqur

#IoT #smart home #connected home #Siri #homekit #ios #schlage #diy projects #DIY #home automation

bigzaphod

Provisioning

A summary-ish of things related to code signing, the developer portal, and provisioning profiles.

I believe this is mostly accurate - but I admit that I have not dug deep into the internals because this rough understanding has served me well enough so far. Don’t take this as some kind of technical gospel to swear by. Instead this is meant more to help anyone who might be really confused to start to find meaning in what can seem like chaos and pointless complexity. Putting this together helped me clarify the reasons for the different parts and roughly how they fit together and why they’re necessary. If you want to know precise technical details about this stuff, I’m not your guy - I just want to build apps and not spend all my time fighting the technology. I hope this helps someone find peace without adding too much confusion.

* An “App ID” represents a class of capabilities (entitlements) for things that require an “account” or “identity” or “permission” of sorts on Apple’s servers and/or on device. It is used when generating a provisioning profile to configure the profile to allow iOS to grant an app permissions to certain capabilities.

* A wildcard App ID is like an “abstract class" which allows the same “identity” for Apple’s services (like GameCenter, Push, IAP, iCloud, etc) to be shared by all apps that implement the “abstract class”. Implementation is done simply be using a bundle ID for your app that matches the App ID’s pattern. (This is probably not a perfect understanding, but that seems like the intent. It can behave a bit like a superclass for sets of entitlements and data containers. While I’ve never used this, I believe you can even share a single iCloud storage container across multiple apps this way.)

* The entitlements *file* that’s part of an app’s bundle acts as *configuration* for certain entitlements or even opting-out of some entitlements that the specific app doesn’t want but which may have been enabled by the provisioning profile that was made with an App ID that matched the app’s bundle identifier when it was launched. It does not itself grant you anything just by virtue of it existing! (Otherwise that wouldn’t be very secure and Apple wouldn’t have much control!)

* A certificate uniquely identifies a developer (individual or company). It is used to check that a given code signature is valid.

* A device, as far as we’re concerned here, is just a unique identifier that represents a single individual piece of hardware.

* Adding an app to iTunes Connect is how you tell the store itself about a specific app and gives the *store* permission to communicate with your app for IAP (as opposed to entitlements specified by the matching App ID which just gives your app permission to talk *to* the store using the builtin frameworks but does not promise your app will get a useful reply from the store). To use and test IAP, you must add your app using your your app’s bundle ID to iTunes Connect and add IAP products (not necessary to submit the app or products for review) or else the store will ignore your app when it tries to use it’s IAP entitlements to talk to the store itself. Think of adding things to iTunes Connect as granting the App Store specific permissions that can affect the behavior of your app (by it offering products for sale, etc).

* Provisioning profiles are where the vasty majority of the confusion is. They represent a union of almost everything mentioned so far and act as a single solution that addresses several issues. The important thing to remember is that they exist to grant an iOS device permission to grant your app specific permissions.

Code signing requires specifying a certificate. That certificate is usually your personal development certificate or your main distribution certificate depending if you’re building for development or getting ready to submit to the store. The code signing process searches your keychain for a private key that matches the specified certificate and uses that private key to generate the signature. (Both the public and private keys are created and stored in your keychain when you initiate the CSR in Keychain Access when you are first setting up your certificates in the developer portal, but only the public key is signed by Apple and turned into your certificate.) Signing marks the binary in such a way that it can be shown that it has not been tampered with since it was signed and that it was signed specifically by you. Any tampering will invalidate the signature - but that only matters if something actually checks and requires the signature to be valid in the first place! Without access to the public key necessary to validate the signature, your binary’s integrity cannot be determined. Having a signed binary alone doesn’t confer it any special privileges.

So how does iOS know that your app is really yours and that you are approved by Apple and that the app has not been tampered with? That’s one of the things that a provisioning profile solves by including exactly which certificates are allowed to be used to sign apps matching a specific App ID. When the provisioning profile is created, the selected certificates are encoded right within the provisioning profile itself so that iOS can use the public keys from those certificates to ensure an app’s binary was signed by one of them before deciding to grant that binary access to anything. This is why provisioning profiles need to have certificates added to them when they are configured.

Another thing that provisioning profiles do is restrict the set of devices allowed to run a given app. This is, in a way, like a second “signature” for the hardware itself. Not only does the binary need to be signed by an approved certificate included in the profile, but the device itself must have a specific “signature” in the form of it’s hardware ID and that ID must also be listed in the provisioning profile before the app is allowed to run.

Provisioning profiles grant access to an app to certain capabilities that Apple wants to control - these are the entitlements that are specified for a given App ID in the portal. The entitlements themselves are encoded within the provisioning profile when it is generated so that iOS knows which things to allow or deny when the app is launched.

Also encoded within the provisioning profile is the distinction between Distribution and Development. This distinction determines which backends some of Apple’s cloud services will connect to if the app has permission to use them (such as sandbox mode for the store or game center) and the certificates used to validate push notifications in either context (which enables you to have separate development and production push notification services and behaviors if you want).

The reason all of this works and is secure is that Apple generates the provisioning profiles in the portal and then signs them with their own private keys before delivering them to you. The signing of the provisioning profiles is something only Apple can do. The file you download can therefore not be tampered with without rendering it invalid. An invalid provisioning profile will not be accepted by iOS and thus Apple can control exactly what can and cannot be provisioned by a developer by simply restricting access to the signing of the provisioning profile to things the the developer portal gives you permission to configure in the first place - even though provisioning profiles can support any number of other awesome options you can’t use without jailbreaking. This is why you have to register testing devices in the portal, add your certificates to the portal, etc - only things in the portal (and thus the numbers of which can be controlled and limited arbitrary by Apple) can be included in a generated and properly signed provisioning profile. The portal is where Apple’s provisioning policies and limitations are actually enforced.

In Xcode, the setting for provisioning profile is listed under Code Signing, but I believe it is not actually referenced in the app bundle nor is it specifically required even when code signing! This may seem surprising, but that’s because the provisioning profile actually has nothing to do with building your app - it’s all about permission when *running* the app on device. That permission is specified from the point of view of the *device*. The device must have a relevant provisioning profile installed for your app and for the device itself in order to run your app’s code, but you do not need one to compile or sign that code! (You only need a public/private key pair to sign your code.) I tested this by simply deleting the provisioning profile from the Xcode’s project settings and cleaning and building and running the project. There was no complaint at all - the app still built was signed and ran on device just fine. Deleting the provisioning profile from the device itself caused the app to stop launching, of course. I think all the provision profile setting in Xcode does is ensure that build & run installs the one you wanted on the device for you automatically and, if there’s any conflicts of found keys in your keychain, it may help to disambiguate which key pair to use when signing (and maybe to aid with the “fix issues” feature).

On device, when attempting to launch an app, iOS will check all installed provisioning profiles and match the app’s bundle ID against the App ID of an installed provisioning profile. It will then use the most-specific one it finds (I think) - but not necessarily the one specified exactly in Xcode’s settings! This can cause problems from time to time if things get out of sync. Basically, the provisioning profile and the app itself are disconnected entirely from each other. You can have any number of apps that use the same provisioning profile (in the case of a wildcard, for example), or you can have any number of provisioning profiles with different combinations of device IDs. It does not need to be one-to-one! This also means you do not need to rebuild your device if you add a tester’s device to your provisioning profile or anything like that. Just get them to install the updated profile and things should be fine.

If iOS finds a relevant provisioning profile and all of the restrictions check out, code signing is validated, device IDs are validated, and the provisioning profile was signed by Apple, then the app is allowed to run. Otherwise you get a provisioning error of some kind and are left with a bunch of combinations of things to check for when attempting to correct it. Fun!

The main takeaway, I think, is that provisioning profiles grant the device permission to grant a set of other permissions to a particular app. Without a profile signed by Apple (or a jailbreak), iOS won’t grant your app any permissions at all and therefore it won’t launch.

(Check out https://github.com/chockenberry/Provisioning for a handy QuickLook plugin that can inspect provisioning profiles.)

#iOS provisioning

HomeKit: Getting serial number from a HMAccessory

Hey folks,

A short utility code snippet (in Objective-C) to get the serial number of a (paired) HMAccessory:

#homekit #ios #objective-c

Inside your home, you control your HomeKit accessories with Siri. Outside your home, Siri talks to your Apple TV. Your third-generation Apple TV may be getting a bit long in the tooth hardware-wise, but it stil has some skin in the new software features game: Its recent 7.0 update included support for extending communication with your HomeKit accessories outside your local Wi-Fi...

Posting as a part of a series of helpful articles and research materials with regards to the Apple HomeKit framework - and it’s integration with various HomeKit enable accessories: most notably thermostats (read #Ecobee).

This article lucidly describes how HK works in conjunction with an (third generation+) Apple TV.

#iphone #AppleTV HomeKit SmartHome

Trending Blogs

Recently Viewed Blogs

Techtician