c4mpute

> 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".

This could also be a punishable crime in Germany: https://www.gesetze-im-internet.de/stgb/__202c.html and other articles around that one.

It is even worse.

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 but 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.

Because a DNSSEC attestation is usually public, except if you maybe use NSEC 3 and hide the RR behind some random name.

No. Ambiguous consent is no consent. And continuing to send DNT is ambiguous, because the tracker can not distinguish between intent and accident.

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.

Agreed. Torx might not be ideal, but it is widespread and (relatively) cheap. And miles better than anything else that is widespread and cheap.

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.

Ah, now I get it. Yes, that is a possible problem.

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.

You could use your DNSSEC signing key to sign a validation message (offline, because that doesn't work over DNS).

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

It would sink into the center of the earth and then oscillate around the center until friction stops it dead center. Materials in the earth's crust and mantle are not strong enough to stop that mass from sinking ever deeper.

But that assumes that this spoon of matter were stable in that state, which it isn't. That kind of density can only be held up with some force like gravity keeping up the pressure. The gravity of that spoonful is insufficient, so the internal pressure will drive apart the neutrons. The effects would probably look like a very very large nuke or large asteroid impact.

Even better: Each user can have his own locale and charset, and may even change that per program/shell/session. One may save filenames as UTF-8, one as ASCII, one as ISO8859-13, one as EBCDIC.

However, the common denominator nowadays is UTF-8, which has been a blessing overall getting rid of most of the aforementioned mess for international multi-user systems. And there is the C.UTF-8 locale which is slowly gaining traction.

No. Because the API is fragmented into old, not-so-old and new parts, some higher-, some lower-level[0]. You need things from all of them, the new API isn't complete enough and has warts in places where using one of the older ones is better/easier/safer. So in the end you will have to use all the ways, and know when to use which one.

All this can of course be fixed with another layer of indirection. But if you ever wanted to know why Windows file APIs and filesystems are so dog-slow, here is (part of) your answer.

[0] e.g. there are lower level APIs that can create and access files and filenames that higher level APIs will filter out or disallow.

It may be a response to specific circumstances like carrying blockade gear, announcements made by the people in question or past crimes: https://www.gesetze-bayern.de/Content/Document/BayPAG-17

> Die entsprechenden Verfahren enden regelmäßig lediglich mit Geldstrafen.

This is plain wrong. Repeat offenders in this matter have been sentenced to jail time, in excess of the two months of possible preventative arrest: https://www.merkur.de/deutschland/kleber-aktivisten-letzte-g...

Usually that believe stems from the fact that those people explicitly announced they would do it again. And again. After being sentenced. In front of a judge.

https://www.merkur.de/deutschland/kleber-aktivisten-letzte-g...

We had technical know-how. Past tense. Then technology became evil incarnate.

Nowadays we are scared of everything, ignorant of any kind of science. All policy and all public outrage is purely based on ideology and wishful thinking. If one kind of wishful thinking fails, we do not reconsider, we double down or replace by another, even weirder kind of wishful thinking.

Basically, we are back to a pre-renaissance way of thinking. We are back in the dark ages.

And I'm honestly scared of that.

Most reasons in §14PAG for preventative arrest include a crime or misdemeanor that has been committed and will likely be repeated, or the proven announcement or planning of such an offense. So most will be suspects in the literal sense, otherwise they wouldn't be in preventative arrest: http://www.lexsoft.de/cgi-bin/lexsoft/justizportal_nrw.cgi?x...

Road blockades are very often judged to be coercion, "Nötigung", a crime according to §240 StGB. Repeat offenders in this matter have been sentenced to some jail time: https://www.merkur.de/deutschland/kleber-aktivisten-letzte-g...

Further sources for your side note: https://www.merkur.de/welt/verdienst-klima-krise-kleber-geha... https://www.businessinsider.de/wirtschaft/letzte-generation-... https://www.sueddeutsche.de/wirtschaft/letzte-generation-akt... https://www.magdeburger-news.de/?c=20221228093058

Oh, and the best source, their own wiki: https://wiki.letztegeneration.org/de/%C3%B6ffentlich/allgeme...

> But being imprisoned without having committed a crime is very unlikely to be considered a fault of the employee.

I would (without being a lawyer and without having a case to cite) suspect that in those cases it would be considered to be the fault of the employee. In many, if not all cases, they had prior arrests, indictments and some were even found guilty, yet announced further blockades. I guess to a judge, that should make it their fault.

> Your work contract or collective bargaining agreement may modify or specify where this paragraph is applicable.

That might very well be the case, since actually many protesters are being employed as protesters: https://www.stern.de/gesellschaft/letzte-generation--so-viel...

Absence is reason to withhold payment in Germany, you can only expect continued payment if you are absent because you are ill (and then only for a certain period). There are some provisions like having to pay out leftover holidays and overtime before stopping payments altogether, but payment is contingent on really working in general.

Note that this is different from ending employment: If you are in jail, only an extended length of absence (usually 2 years) or a work-related crime is reason for dismissal. If you are in jail for 23 months you'll keep your job usually, you are just not getting paid.