- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
GDPR rights are being ignored. In practice, this leads to a situation where Microsoft is trying to contractually dump most of its legal responsibilities under the GDPR on schools that provide Microsoft 365 Education services to their pupils or students.
Trying to find out exactly what privacy policies or documents apply to the use of Microsoft 365 Education is an expedition in itself. There is a serious lack of transparency, forcing users and schools to navigate a maze of privacy policies, documents, terms and contracts that all seem to apply. The information provided in these documents is always slightly different, but consistently vague about what actually happens to children’s data when they use Microsoft 365 Education services.
Maartje de Graaf, data protection lawyer at noyb: “Microsoft provides such vague information that even a qualified lawyer can’t fully understand how the company processes personal data in Microsoft 365 Education. It is almost impossible for children or their parents to uncover the extent of Microsoft’s data collection.”
Felix Mikolasch, data protection lawyer at noyb: “Our analysis of the data flows is very worrying. Microsoft 365 Education appears to track users regardless of their age. This practice is likely to affect hundreds of thousands of pupils and students in the EU and EEA. Authorities should finally step up and effectively enforce the rights of minors.”
As the terms and conditions and the privacy documentation of Microsoft 365 Education are uniform for the EU/EEA, all children living in these countries are exposed to the same violations of their GDPR rights. Therefore, noyb also suggests that the authority should impose a fine on Microsoft.
The whole pointA big part of the problem is that it’s not clearly documented.Yes, there’s a ton of documentation, but correlating the settings across multiple different constantly changing web UIs plus the shit that’s only available through PowerShell is easily a full time job. That’s without talking about the vagueness, edge cases, and situations that simply aren’t discussed in the docs.
Good example: Litigation Holds on mailboxes. LitigationDate does not update when settings of an active hold are changed, only when the status changes from disabled to enabled. Duration has no connection to the LitigationDate, so setting a duration of 100 days does not mean that the hold expires 100 days after the LitigationDate. It means that each individual email in the box will be retained for 100 days past when it was created.
So let’s say for legal reasons you need to retain emails for a year, even if the user deletes them. Litigation Holds also will retain copies of deleted emails behind the scenes, so perfect. Pretty simple, set duration to 365 days and enable the hold.
What about if you need to hold onto all emails in the mailbox at the time when an employee is fired, but you only want to have those for 100 days past their firing date? You have to take the normal retention duration of 365, add how many days post firing you need to hold onto everything. So 465 days for how old the oldest email can be, so 465 days for the duration. But you only want to set that after the separation now, else you hold onto more while the person is still employed.
Automating this step is something not directly supported as some sort of automatic policy. You have to either do it manually whenever someone leaves, or start looking into automating manual changes using other tools.
Okay, so how do you ensure that at 100 days post-firing it all goes away? You must disable the 465 day duration hold entirely after 100 days. Again, manual change or welcome to learning automation land.
Now lets mix in email retention policies in Exchange, but you can’t solely rely on those because those only define the maximum time an email can live before deletion and don’t prevent a user from deleting everything themselves. Now you need to account for their maximum length with the duration you set when a user is fired as well.
Why not just make things easy and set all separated employees to unlimited? Now there’s too much exposure risk if you get a subpeona. Legal department says no, we need it exactly as described above. And no exporting a mailbox to file after someone is fired, for security reasons relating to data portability.
So we’re automating now. How do we track separation date in a way that the automation can use 100 days after it as a trigger?
Now how about having a verifiable audit trail for all of those changes?
I’ve fudged specifics but that scenario, requirements, and restrictions are not a hypothetical. I work in finance, so our requirements will be heavier than some other places, but it illustrates a point.
None of the little information I’ve given about how these features work is laid out nearly so straight forward in the official documentation.
Soumds like the thing they did with their 600-pages OOXML (.docx, .xlsx) specificaton during standardization, with most of it being proprietary extensions.
If you can’t hide, confuse.
Yes, it is a full time job and hard. That’s how MS is able to configure and sell it to so many different customers. For those without the capabilities there are more simple products. We should start taking legal action against AWS because you can implement things in a shitty way if you hire experts?
The issue is that Microsoft is marketing these as “easy” solutions (requiring less work and manpower than older on-prem options) for specific use cases (in this case education) where the defaults don’t match the requirements for said use case. It’s not easier, and it doesn’t meet the needs it is sold for out of the box.
I was only addressing your claim that it’s all documented and the implication that it was a simple matter of configuration.