C.Interaction generation between applications and rules However,after implementing the foregoing method,we find In this stage,we design an algorithm to generate the that the final result is not accurate,so we manually check the interaction between two IoT applications or the interaction generated application,to ensure that it can be simulated in the between an application and a rule,using the intra-interaction online IDE of SmartThing correctly. and the relations between the capabilities and the physical B.Intra-interaction and relations between capabilities and environments in stage II. environments extraction D.Interaction analysis and risk mitigation We find all the applications subscribe to the events of After obtaining the interactions between applications and devices and then trigger the action of other devices.The devices need to match the application with the corresponding rules,we discover the risk interactions according to the risk of the action in the interactions.For the found risky interactions, capabilities during the installation.Only the device with the we propose two strategy to mitigate risk for application designated capabilities can obtain the sensed data and perform developers and users. corresponding actions.The configuration information of these devices can be directly extracted from the SmartApps'source III.SYSTEM IMPLEMENTATION code,including the event subscribed by the application and the corresponding event handlers. A.Application collection and rule conversion It can be seen from the example SmartApp code shown in We collect all open-sourced smart applications as our re- Listing I,SmartApp's infomation such as name,description is search object from Samsung's SmartThings platform.And we passed in by using definition method.The preference section choose IFTTT as our Trigger-Action rule platform,because claims all the capabilities and inputs of the application,this it already has 11 million users and 54 million rules,and section is configured by device users.What's more,these it directly provides control rules for SmartThings devices. configurations may be set incorrectly.And in the installed We collect 187 SmartApps and 244 IFTTT rules suitable method.the subscribe method receive the parameters like the for SmartApps in April 2019.but not all of them can be name of subscribed device,the trigger event and the event analyzed.In order to analyze applications and rules in a unified handler.We use the syntax analysis class CompilationUnit of manner,we convert the IFTTT rules into the form of SmartApp the Groovy language to generate an abstract syntax tree(AST) for subsequent analysis.Since IFTTT rules are described by of the application's source code,and traverse the AST to natural languages,and they have no standard format,which complete the extraction of the intra-interaction within the brings great challenges to the conversion at this stage. application. IFTTT rule conversion:The goal of this process is to We extract the list of capabilities and inputs from the extract the trigger conditions and trigger actions of the IFTTT preference method of AST.which contains sensor name rules,and convert it into an application supported by the and capabilities.The subscribe,runln and schedule meth- SmartThings platform.For example,for the rule"Start Skybell ods define the trigger conditions and actions of the sen- video record when motion is detected",we construct an sors,so we traverse all these three methods to extract application that subscribes to the event "motionSensor.active" the trigger and action tuples.After extracting the trig- and triggers the "videoCamera.on()"action when an action is gers and actions,we link these information as our intra- detected.Thus,we design a code template with some blank interaction whose format is like (capability.motion Sensor: to be filled.The name and description of the application are motion.detected,capability.switch on). directly generated by the rule description,the corresponding We also extract the name.description and the annotations sensing device's name is fixed,the device-subscribed event,the of the application,because these pieces of information can triggered action and the capability applied for are generated determine the relations between the capabilities and the phys- by using the NLP technology. ical environments,for example,"Turn your lights on when There are generally two category of IFTTT rules:one is it gets dark"means when it's sunset (about 6 o'clock pm). action execution,such as "Lock your SmartThings device", turn the light on.This description indicates that the capability and the second is rules containing keyword "when",which capabiliry.switch corresponds to light,and of course capabil- describes the event trigger conditions and the corresponding iry.switch can also have an impact on other environments,such to-be-taken actions.In order to comply with the event seman- as temperature. tics of the IoT platform,we only select 98 rules containing As mentioned in literature [6],the environment involved keyword "when"from 244 IFTTT rules.We use the word in IoT devices includes temperature,humidity,light,location, segmentation methods in NLTK [11]and remove stop words motion,smoke,and leakage.In addition,there are four system to divide the description into two parts.One is the condition environment variables:time,location mode,switch,and lock, part after keyword "when"and the other part is the action 11 physical channels in all.Based on the method to extract before keyword "when".We traverse all the token resulted physical channels in the literature [6],in addition to the from NLTK.and check whether the word or word list is above 11 channels,we newly discover 2 physical environments an action or condition according to its part of speech and such as color and voice.Therefore,in order to determine the frequency of occurrence. relations between capabilities and the physical environments, 992C. Interaction generation between applications and rules In this stage, we design an algorithm to generate the interaction between two IoT applications or the interaction between an application and a rule, using the intra-interaction and the relations between the capabilities and the physical environments in stage II. D. Interaction analysis and risk mitigation After obtaining the interactions between applications and rules, we discover the risk interactions according to the risk of the action in the interactions. For the found risky interactions, we propose two strategy to mitigate risk for application developers and users. III. SYSTEM IMPLEMENTATION A. Application collection and rule conversion We collect all open-sourced smart applications as our re￾search object from Samsung’s SmartThings platform. And we choose IFTTT as our Trigger-Action rule platform, because it already has 11 million users and 54 million rules, and it directly provides control rules for SmartThings devices. We collect 187 SmartApps and 244 IFTTT rules suitable for SmartApps in April 2019, but not all of them can be analyzed. In order to analyze applications and rules in a unified manner, we convert the IFTTT rules into the form of SmartApp for subsequent analysis. Since IFTTT rules are described by natural languages, and they have no standard format, which brings great challenges to the conversion at this stage. IFTTT rule conversion: The goal of this process is to extract the trigger conditions and trigger actions of the IFTTT rules, and convert it into an application supported by the SmartThings platform. For example, for the rule “Start Skybell video record when motion is detected”, we construct an application that subscribes to the event “motionSensor.active” and triggers the “videoCamera.on()” action when an action is detected. Thus, we design a code template with some blank to be filled. The name and description of the application are directly generated by the rule description, the corresponding sensing device’s name is fixed, the device-subscribed event, the triggered action and the capability applied for are generated by using the NLP technology. There are generally two category of IFTTT rules: one is action execution, such as “Lock your SmartThings device”, and the second is rules containing keyword “when”, which describes the event trigger conditions and the corresponding to-be-taken actions. In order to comply with the event seman￾tics of the IoT platform, we only select 98 rules containing keyword “when” from 244 IFTTT rules. We use the word segmentation methods in NLTK [11] and remove stop words to divide the description into two parts. One is the condition part after keyword “when” and the other part is the action before keyword “when”. We traverse all the token resulted from NLTK, and check whether the word or word list is an action or condition according to its part of speech and frequency of occurrence. However, after implementing the foregoing method, we find that the final result is not accurate, so we manually check the generated application, to ensure that it can be simulated in the online IDE of SmartThing correctly. B. Intra-interaction and relations between capabilities and environments extraction We find all the applications subscribe to the events of devices and then trigger the action of other devices. The devices need to match the application with the corresponding capabilities during the installation. Only the device with the designated capabilities can obtain the sensed data and perform corresponding actions. The configuration information of these devices can be directly extracted from the SmartApps’ source code, including the event subscribed by the application and the corresponding event handlers. It can be seen from the example SmartApp code shown in Listing 1, SmartApp’s infomation such as name, description is passed in by using definition method. The preference section claims all the capabilities and inputs of the application, this section is configured by device users. What’s more, these configurations may be set incorrectly. And in the installed method, the subscribe method receive the parameters like the name of subscribed device, the trigger event and the event handler. We use the syntax analysis class CompilationUnit of the Groovy language to generate an abstract syntax tree(AST) of the application’s source code, and traverse the AST to complete the extraction of the intra-interaction within the application. We extract the list of capabilities and inputs from the preference method of AST, which contains sensor name and capabilities. The subscribe, runIn and schedule meth￾ods define the trigger conditions and actions of the sen￾sors, so we traverse all these three methods to extract the trigger and action tuples. After extracting the trig￾gers and actions, we link these information as our intra￾interaction whose format is like capability.motionSensor : motion.detected, capability.switch : on. We also extract the name, description and the annotations of the application, because these pieces of information can determine the relations between the capabilities and the phys￾ical environments, for example, “Turn your lights on when it gets dark” means when it’s sunset (about 6 o’clock pm), turn the light on. This description indicates that the capability capability.switch corresponds to light, and of course capabil￾ity.switch can also have an impact on other environments, such as temperature. As mentioned in literature [6], the environment involved in IoT devices includes temperature, humidity, light, location, motion, smoke, and leakage. In addition, there are four system environment variables: time, location mode, switch, and lock, 11 physical channels in all. Based on the method to extract physical channels in the literature [6], in addition to the above 11 channels, we newly discover 2 physical environments such as color and voice. Therefore, in order to determine the relations between capabilities and the physical environments, 992