> The German law you cite about getting a password is applicable if you plan to or actually access data they are not authorized to. Which is not the case (assuming they do not).
Usually this is the case. The user and Microsoft are not the only parties involved here. The Email provider is also involved in that they provide an email account, often e.g. for work or educational purposes. In those cases, handing over account credentials is forbidden by the workplace or educational institution, providing other people such as Microsoft with access is usually forbidden as well. Other commercial email providers often have similar rules. Therefore either Microsoft is doing unauthorized accesses en masse (since they do know that the aforementioned clauses are widespread common practice) or the users are illegally providing access to Microsoft.
> GDPR deals with privacy. The user name is personal identifiable data. The password is only personal data. The emails themselves can be PII or just personal data.
There is no such distinction in GDPR. There is only personal data according to GDPR article 4. A password is personal data because it is "personal" in that it can be (and is almost always) tied to a person. "PII" is something that only occurs in US law. The definitions are different, "personal data" in GDPR is far broader.
> GDPR legally wise, the password is the least risky set of data here (as absurd as it is)
Depends on what else is in that Inbox and what else this password can access.
> And these properties are not mentioned in the consent but just are part of the process. This is nothing else, just that we are very worried about that the property is a password.
Interesting idea, and yes, GDPR allows for not informing the user about what the user already knows, i.e. a kind of implicit consent. However, the surprise that even experts on HN show about this news demonstrates that the average user doesn't know. So this doesn't apply, Microsoft should have explicitly informed and asked about permission to use username and password.
No, they are not. GDPR notices (which this is) must be understandable to the layman. Including all consequences like "this will also allow access to other services secured with the same university/company-wide password".
MS doesn't need to do anything. They don't need to pay anyone off. EU bureaucracy is extremely strongly wedded to MS products like Windows, Office, Teams, Outlook etc. As are all EU national bureaucracies and public institutions.
There are firm opinions by e.g. the BSI (German IT security office, comparable to something between NSA, mostly NIST, DHS and ANSI) and other equivalent European national offices that it is practically impossible to operate modern MS products securely. E.g. there are guidelines from BSI like "we know that in that exact version (which is years old, because the guideline took ages to write) you need to set the following registry keys to prevent data exfiltration. Btw. this won't help you, because you also HAVE to upgrade within a few weeks of each available update". There are firm opinions by multiple European data protection offices that basically say the same about GDPR compliance in MS products. Practically impossible to achieve, there might have been that one configuration, "Once upon a time of writing the report, with that specific version of Windows and Office, when firewalling off half of azure, setting those 300 registry keys, manually deleting the following files, illegal telemetry could no longer be observed. Also, you are obliged by GDPR to follow good practice and update regularly, so good luck with that...".
Basically it is illegal to process any personal data using MS products in the EU if the processing system has any kind of outgoing internet connection. All the bureaucracies ignore this systematically, citing the "impossibility" of working without said MS products. Migration plans away from those illegal processes are regularly cancelled, ignored or never completed. MS is free to do whatever it wants, they are never really investigated, fined or held to any laws.
Meanwhile, other big IT firms like Meta, Google, Twitter/X and lots of others are held to far higher standards. Where tons of your local government's data about you like tax report, criminal records, school records and similar things are subject to being exported to the US via Azure, MS telemetry and what not. With FAANG there is complaining about comparably laughable stuff like "well, that IP address that Google Fonts could observe...".
The problem, why this doesn't change, is that the local government institution is responsible for their data processing (according to GDPR and other laws), MS being only their contractor. And those government institutions are usually (in almost all EU states) free from GDPR and other penalties, and those penalties would be left-pocket-to-right-pocket anyways.
This is why MS gets a free pass on everything. Imho this must end.
Would be irrelevant, because the DNT-header will be sent with every request, so for all practical purposes will be later than any other kind of consent.
GDPR specifies tracking to be necessarily default-off and opt-in anyways. Therefore the browser sending DNT:1 by default would just repeat the legal status quo. A tracker could not successfully argue that this is to be ignored, because the technical default that the browser sends is the legal default anyways.
If an attacker knows about some exploit involving someservice.com, which you are using. That attacker will try to find out where he can use that exploit of his. E.g. he might use something like shodan, google or DNS to get a list of users of someservice.com. Those potential victims that turn up in that list will get attacked first. Later on, if that list is used up, the attacker might then look at other means of getting new victims, like e.g. just trying out the exploit on targets where he doesn't know they are vulnerable. So in that case, not being "visible" to an attacker buys you time to fix the vulnerability.
On the other hand, if you are on the attacker's hotlist, he'll try you first and you gain nothing.
Even stupid age-old BIND zone files can be version controlled and commented. Anything inferior to that level of documentability should be an instant no-no.
This kind of thing is pointless against a targeted attack. But it can hide you long enough in case of zero-days/fresh unpatched vulnerabilities because attackers will first target the more easily visible victims.
Domain validation TXT records are poor infosec hygiene. If used at all, those records should never include any hint as to what service they are intended for.
E.g. the record should NOT be:
example.com IN TXT "someservice.com-validation=029845yn0sidng0345randomnyosndgf03548yn"
instead, it should be something like
example.com IN TXT "029845yn0sidng0345randomnyosndgf03548yn"
Of course there will be multiple such records for different service providers. The service providers will just have to check all those (handful) of TXT records for the random assigned token in their database instead of pre-filtering them by the someservice.com-validation prefix.
As jelavich pointed out, there is also https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-veri... which suggests another improvement on that. To avoid polluting the example.com name with tons of TXT records and to avoid problems with CNAME records and such, those records should be further down in the tree like
_validation_mv0395ng035.example.com IN TXT "029845yn0sidng0345randomnyosndgf03548yn"
The record name token "mv0395ng035" could either be another random number assigned to example.com by someservice.com they just put in their database. Or it could be something like HMAC(example.com, <common secret known to someservice.com>), so they don't have to save all those tokens. In any case, the check will be just one DNS lookup, one comparison and done. Quicker, equally easy and more privacy-preserving and infosec-hygienic.
Double or triple that of a car, for a small plane, because of the higher fuel consumption.
But this only affects avgas, which is high-octane gasoline for propeller-driven aircraft. Jet-A1, which is light diesel fuel or kerosene-like for jets doesn't contain lead.
The LibreOffice CSV import is configurable. The Excel one isn't.
You can do things in PowerQuery, but that is far from obvious and still buggy. Not to mention all the woes after import, like date/time auto-interpretation and autocorrections that cannot be switched off.
I stand by what I said. Excel imports are a huge mess.
Yes, I have. What Excel is still lacking is an easy solution for the input side. You can bind tons of data sources, but all are weird, hard-to-use, manual. There is no easy "grab this from that website, get the current data of what I just pasted there, mash it together, publish it"
Hell, it cannot even do proper CSV import. You need to reformat your CSV to match the locale Excel is running under!
The problem here is that you usually do not have ~1k users with all the same requirements. You have 200 groups of average 5 users each, all with their own department-specific, country-specific or workflow-specific requirements. Of course a central solution will be better and cheaper. But it will never be quicker, because you will take ages to just gather requirements from all 200 distinct user groups. As soon as you have those requirements, they will have changed already, so you are working on yesteryear's problems.
And of course, given a working system, the users can drop you a quick email, explain their problem (yes, in an ideal world they could do that, and you would understand them right away...) and you implement a 5min change. In reality however, their problem will first have to be specified in a user story, with a ton of clarification requests until the story is really understood by the dev team, then you need goodwill, time and money for the implementation. And maybe their problem can only be solved by an ugly hack, a weird special case for the ternary currency and ages-old lunar-calendar-based tax-system of lampukistan. Would that really be quicker than just the lampukistan team throwing together a few formulas and be done faster than the initial email? Even when multiplied by the special requirements of the other 100 country sales teams?
Also, I've had similar change requests where is was explicitly asked to provide a spreadsheet prototype of what the statistics should look like. Well, thanks, why again do we need a dev team?
I know that spreadsheets suck. They are ugly, undebuggable hacks, always and without exception. You need tons of time to implement in hours what would be a quick one-liner SQL query. With terrible error behaviour, weird edge cases and hell knows how many hidden bugs when the locale uses the lampukistan-currency-separator instead of a decimal dot...
...Except that they provide those office drones with velocity, which, as the usual wisdom around here goes, is everything.
To be somewhat constructive: What you rather should have done is not create more elaborate dashboards. What imho the world needs is an easy way to use a spreadsheet tool to generate and publish a dashboard. A "make web dashboard" button right next to the print button. With auto-updates when input data changes of course.
All these cool-looking dashboards are just too inflexible. You cannot add your own aggragates beyond trivialities. You cannot just "color that one value that bugs you". You cannot just generate a readable report plus some explanatory text.
Spreadsheet export + pivot table gives you all that. Doable for any moderately competent office drone without a round-trip through some endless backlog-spec-sprint-program-test-respec-sprint-... loop
Usually this is the case. The user and Microsoft are not the only parties involved here. The Email provider is also involved in that they provide an email account, often e.g. for work or educational purposes. In those cases, handing over account credentials is forbidden by the workplace or educational institution, providing other people such as Microsoft with access is usually forbidden as well. Other commercial email providers often have similar rules. Therefore either Microsoft is doing unauthorized accesses en masse (since they do know that the aforementioned clauses are widespread common practice) or the users are illegally providing access to Microsoft.
> GDPR deals with privacy. The user name is personal identifiable data. The password is only personal data. The emails themselves can be PII or just personal data.
There is no such distinction in GDPR. There is only personal data according to GDPR article 4. A password is personal data because it is "personal" in that it can be (and is almost always) tied to a person. "PII" is something that only occurs in US law. The definitions are different, "personal data" in GDPR is far broader.
> GDPR legally wise, the password is the least risky set of data here (as absurd as it is)
Depends on what else is in that Inbox and what else this password can access.
> And these properties are not mentioned in the consent but just are part of the process. This is nothing else, just that we are very worried about that the property is a password.
Interesting idea, and yes, GDPR allows for not informing the user about what the user already knows, i.e. a kind of implicit consent. However, the surprise that even experts on HN show about this news demonstrates that the average user doesn't know. So this doesn't apply, Microsoft should have explicitly informed and asked about permission to use username and password.