You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The entire thing is just a custom xml string attached to the package (the security aspect is therefore similar to printing "Confidential" on each page of a document, just that this is at least visible. Outside of MIP environments the sensitivity label is no longer visible. So if someone shares a file marked as confidential with somebody in the outside world, this other person would not be aware of any confidentiality requirements, when opening the file and you can simply remove the sensitivity label by removing the xml string from the file ...).
Each MIP environment can provide custom roles for access. These roles have a custom id known only to the MIP environment and this is stored with the xml string. (Think of it as a corporate id string added to the "Confidential" stamp. For the sensitivity to apply, the stamp is not only "Confidential", but "Confidential for Corporation"). This id is required to write a valid sensitivity label. The id and the possible sensitivity levels could be obtained using the power shell commandGet-Label, but access might be restricted.
Therefore extracting the custom.xml string from a template file should be the way to go. I somehow doubt that there is any security risk involved if the string is public, worst thing, somebody could stamp documents with this (similar to printing "Confidential for Corporation" on non confidential pages not from the Corporation). Still it might be a good idea to store the string in an option, so that if the user shares code, it will be obvious that the MIP string should not be passed along to everyone everywhere, but first and foremost, so that the user wont have to remember passing the string to every function.
We have to make sure that we do not duplicate these strings (Excel might complain if we do). Even if we do not yet provide a way to create or alter custom.xml, our function should not remove existing custom.xml strings. Not sure how to handle a situation, where the user might want to raise or lower the sensitivity of a document.
As discussed in an
openxlsx
issue (ycphs/openxlsx#461 (comment)) it is possible to load and apply sensitivity labels withopenxlsx2
.There are things to consider
They are only visible in corporate environments that have MIP (Microsoft information protection) enabled (https://learn.microsoft.com/en-us/information-protection/develop/concept-mip-metadata) and there is no way for us to test this without such an environment that at the moment is not available.
The entire thing is just a custom xml string attached to the package (the security aspect is therefore similar to printing "Confidential" on each page of a document, just that this is at least visible. Outside of MIP environments the sensitivity label is no longer visible. So if someone shares a file marked as confidential with somebody in the outside world, this other person would not be aware of any confidentiality requirements, when opening the file and you can simply remove the sensitivity label by removing the xml string from the file ...).
Each MIP environment can provide custom roles for access. These roles have a custom id known only to the MIP environment and this is stored with the xml string. (Think of it as a corporate id string added to the "Confidential" stamp. For the sensitivity to apply, the stamp is not only "Confidential", but "Confidential for Corporation"). This id is required to write a valid sensitivity label. The id and the possible sensitivity levels could be obtained using the power shell command
Get-Label
, but access might be restricted.Therefore extracting the
custom.xml
string from a template file should be the way to go. I somehow doubt that there is any security risk involved if the string is public, worst thing, somebody could stamp documents with this (similar to printing "Confidential for Corporation" on non confidential pages not from the Corporation). Still it might be a good idea to store the string in an option, so that if the user shares code, it will be obvious that the MIP string should not be passed along to everyone everywhere, but first and foremost, so that the user wont have to remember passing the string to every function.We have to make sure that we do not duplicate these strings (Excel might complain if we do). Even if we do not yet provide a way to create or alter
custom.xml
, our function should not remove existingcustom.xml
strings. Not sure how to handle a situation, where the user might want to raise or lower the sensitivity of a document.A few additional links:
The text was updated successfully, but these errors were encountered: