## 7 Discussion of the Filtering Impact on Security and Privacy
### _Icm:_  
This vector is simply a collection of the two vectors _CME_ and _CML_, for which a rating of _some_ and _medium_ influence has been assigned, respectively. The minimum influence, which is _some_ is considered appropriate here (_ICM_). IDN:  
While the approach cannot change the name of a device, it might prevent others from becoming aware of it by blocking communication which would reveal the name. However, such names can also be part of broadcast or multicast traffic, e.g., in DHCP requests. Because _Bark_ seems to not control this type of communication in a fine-grained way, the effect on this sub-vector has to be considered low. On the other hand, a reverse lookup might not be possible if a device can only contact the DNS server with a whitelisted set of domain names. Therefore, there is still a rating of _some_ influence assigned here (_IDN_). IDS:  
This vector refers to the identified influence of _Bark_ on the corresponding _Information Disclosure_ impact in the STRIDE assessment in Tables 11-14. In case multiple impacts exist for the combination of element and threat, the smallest impact is taken. Therefore, no generic influence rating is given here. Iiii:  
This vector is based on the ability to know the user of a control device that is given by the impact _IUD_. The vector is further based on the ability to monitor messages in the first place, which is expressed by the corresponding _IDS_ vector. Because both of them are necessary, the maximum is taken here. Overall, no generic influence can be given here. MRD:  
This vector refers to a set of _IDS_ vectors. Some of the corresponding STRIDE threats might not have been considered relevant, and therefore, there is no entry for them in the STRIDE (Tables 11-14). Consequently, only those vectors, which have a counterpart in the tables are considered. Thus, no general influence rating can be given here. Nsl:  
If the rules are sufficiently detailed, they permit only such communication as is necessary. Consequently, an attacker is unable to discover any new hosts or ports by scanning the network. However, the scanning process may still reveal further information, such as the operating system that is running on a host. This does not apply to wired clients, which were not considered in the approach, and which can circumvent the filtering mechanisms by spoofing their MAC addresses. Under the assumption that most devices are wirelessly connected, the influence is rated as _medium_ here (_NSL_). Scenario-Specific Adjustments  
\(S_{\alpha}\) (_Communication with the Internet_):  
Because the communication to the _Unessential Server_ is by definition not necessary (see Section 5.1), it would not be whitelisted in _Bark_. Additionally, data which have never arrived at the server side can also also not be shared with any other party. Therefore, in the case of the _Unessential Server_, a _high_ influence rating is assigned for the vectors _BDS_, _BDT_ and _BST_. \(S_{\beta}\) (_Local Network Communication_):  
According to the definition of scenario \(S_{\beta}\) in Section 5.2, the _Smart Home Devices_ in the local network do not have to communicate with each other, which means that there would be no rules in place, which permit any traffic other than that which is originating from the _Owner Control Device_ to the _Smart Home Device_\(X\). Because the _Owner Control Device_ is explicitly not considered as a malicious device, the influence levels of the local attack vector _CML_ is increased to _high_ for the _Smart Home Device_\(X\) as well as traffic from or to it. \(S_{\gamma}\) (Guest Access):  
Just like in \(S_{\beta}\), there is no need for communication between the two _Smart Home Devices_ according to the specification of \(S_{\gamma}\). Because the _Accessible Smart Home Device_ is intended to be accessed by the _Guest Control Device_, there need to be rules in place that allow communication between the two appliances.