I think it's "Cargo Cult Security". My hypothesis is that someone once realized that having a password stored in the clipboard could be bad, so let's just ban pasting passwords. The logic here is obviously completely backwards, but once a meme is out there it's hard to stop it.
And that is why I never do automatic OS/platform upgrades on a development machine. When something stops working that was known to work before, I want to know exactly what things have changed, and not have to troubleshoot multiple concurrent changes.
The article uses two example theorems to justify this: a * (b/c) = b * (a/c), which can be extended to cover the c=0 case, and a/a = 1, which can be extended to cover the a=0 case. I can see how this can be useful in some situations, but it's not natural in the same way as e.g. analytical continuations of complex functions are.
Ah, the memories! I did some third-party development for Macintosh in 1985, and we used Apple Lisas as our development workstations. These Lisas usually booted into Apple Pascal, which looked very much like the UCSD Pascal development environment that was very popular in the early 1980s. But I don't know if Lisa Pascal shared any common code with UCSD. That development environment also included a pretty good 68000 assembler that we made heavy use of.
Even before the Lisa was officially rebranded "Macintosh XL", developers could boot the Mac OS and test their programs on their Lisa. This was great, because the Lisa had 1MB memory while the original Mac had only 128k (and later 512k). The only issue was that the Lisa pixels weren't square, so all Mac graphics looked noticeably squished on the Lisa. We also had an issue with the floppy drives on some of the Lisas: their ejection springs were too strong so dragging a floppy to the trash icon sometimes resulted in the floppy disk flying over the office floor.
This is a good story that illustrates the problem very well. I don't want to be treated according to what my statistical cohort in a certain particular context suggests. But I have no problem with a personalized treatment from my bank personnel, from my cleaning staff, or from the undertaker. Or from the bartender who knows me.
It's primary purpose is as a unit of account, i.e., to quantify the value of an asset. It's the assets themselves that are the long-term store of wealth.
Yes, I have used it to mount document servers as remote drives via WebDAV, and then use standard Unix one-liners to do queries and updates. Much more convenient than working with custom APIs.
I also once integrated an open-source WebDAV server into my own code, in order to expose parts of an SQL database as a remotely mountable filesystem. This would have taken much more effort without the existing WebDAV infrastructure.
A designated DPO is only required for companies that have over 250 employees. Surely that can't be a huge burden? Just appoint the head of security to be the DPO. He can google the GDPR requirements and then be all set after 15 minutes.
If you are smaller than that and you outsource processing of the personal data of your customers, then all you have to do is make sure the customers consent to this, and you are good to go with GDPR. It's practically effortless, unless your business model relies on monetizing innocent victimes without their consent.
I'm not talking about the DPO. That's from article 37 and has nothing to do with the representative required under Article 27.
The Article 27 representative must be in the Union, which is why it can be problematical for a company whose office and employees are all outside the Union.
But Article 27(2) explicitly excludes the requirement of designating a representative according to 27(1), if the processing of personal data is limited within perfectly sound limits.
Article 27(2) excludes that requirement for "processing which is occasional, does not include, on a large scale, processing of special categories of data as referred to in Article 9(1) or processing of personal data relating to criminal convictions and offences referred to in Article 10, and is unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope and purposes of the processing".
To be excluded, the processing has to satisfy three requirements:
• "is occasional"
• "does not include, on a large scale, processing of special categories of data as referred to in Article 9(1) or processing of personal data relating to criminal convictions and offences referred to in Article 10"
• "is unlikely to result in a risk to the rights and freedoms of natural persons"
Most businesses probably won't process any of the Article 9(1) special categories or the Article 10 criminal stuff, so that shouldn't my much of a hurdle for most.
All kinds of data pose a risk to the rights and freedoms of natural persons. See Recital 75 for examples. Of particular note, if it can lead to identity theft, fraud, or financial loss it poses such a risk. This is going to snag a lot of businesses.
Then there is that "is occasional" requirement for being excluded. I have no idea how that is going to be interpreted.
This is a hasty conclusion. For example, the city of Kiruna in northern Sweden (latitude 67 degrees north) has about three weeks of total darkness each winter. So there is no sun exposure at all during that time. And even south of the arctic circle, the chance of getting 5-30 minutes of sun exposure twice a week is not guaranteed in northern countries. For example, you might be stuck in an office building while the sun is above the horizon.
