The Ionic JS SDK documentation mentions that the postMessage API is used to communicate with an iframe running core SDK code. Device profiles are kept in localStorage scoped to the origin of the iframe.
What prevents the SDK JS code (and subsequent iframe) from being loaded on a malicious site and used to access the profiles a user has created to encrypt/decrypt data?
To create a new device profile, applications should call the enrollUser function; see: https://api.ionic.com/jssdk/latest/Docs/tutorial-device_enrollment.html
From the docs
Upon successful authentication within the 10-minute timeout window, an enrollment profile is stored encrypted in localStorage under the appId, userId, and the origin of the calling application.
So the profile is stored encrypted. The profiles are also stored nested and namespaced by origin, appid, and userId, like this (see the queryProfiles function in ProfileManager.js):
profiles[origin][appId][userId]
Note that the origin information is pulled from the postMessage event object received by the sdk core code running inside the iframe.
The loadUser function accepts the same params as enrollUser and performs the reverse operation, loading a profile from localStorage and decrypting it.
So in summary
What prevents the SDK JS code (and subsequent iframe) from being loaded on a malicious site and used to access the profiles a user has created to encrypt/decrypt data?
An application must have access to the same appId, userId, and userAuth values and be running on the same origin to gain access to a profile created by another application.
In practice
appId is hardcoded for a give application (i.e. in the js/html)userId and userAuth are stored on the application user's session object. These values can either be fetched via an ajax request to the application's origin server or written into the application html. This is similar to normal handling practices for CSRF tokens.