For Knuth's sake: The GDPR is NOT about cookies! The older 'cookie directive' is also NOT about cookies! They're about a third party storing their data on your computer, or storing your personal data on their computers - no matter what technology is used.
Nothing in the GDPR stops websites from honoring "Do not track" and then _not asking_ if it's present. They don't have to ask if they don't track you! They don't have to ask for a technically necessary session cookie that appears after you actively log in!
Websites ask because they want to track you! A 'law targeting browsers' would not help because people would say no to cookies, and then websites would ask about some other way to track you. Because they want to track you.
Switched from Gmail to Fastmail about 10 years ago.
2-3 spam emails slip through every week, and sometimes a false positive happens when I sign up for something new. I don't see this as a huge problem, and I doubt Gmail is significantly better.
Luckily, GDPR isn't about cookies, it's about processing personal information.
Doesn't matter if you use cookies, localstorage, or carrier pigeon.
The older EU 'cookie directive' only mentions cookies as an example of storage in a footnote. The regulative is actually about any storage on the users computer.
Marketers would like you to believe that the stupid banners are about cookies. They're not - they're about processing your personal information.
Spam texts are not really a thing here in Norway, either.
I do get three to four phonecalls from spoofed UK numbers every month. I havn't picked up for a year or so, but last time I did, it was a fake "Microsoft Support" scam.
As I understand it, if you modify the xml, Keepass will silently export entries in the database once you load it (by providing the password).
Keepass will (by default) not ask for the password a second time before exporting - but you have to decrypt the database once before it can be exported.
So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".
Really not a lawyer, and not in the US, so not sure I understand the 'work for hire'. But 'work for hire' requires some sort of employment contract, surely? And the pay was part of that contract?
So if Disney doesn't uphold the contract, doesn't that mean it wasn't a work for hire, and therefore the copyright belongs to the author?
Also, "consent" has a specific meaning in GDPR, see article 4(11) [0]:
> Consent of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.
Which is why I suspect almost all "cookie banners" are worthless. They don't give a clear, informed consent, so the site operator is still not allowed to use the data for anything at all.
I've never actually used these, I just knew they existed.
I found them via DuckDuckGo, in the github repository of qBittorrent.
They have a step-by-step guide for using them, without mentioning kdevelop:
> My code is not theirs and this is the core issue.
This is _exactly_ why a lot of jurisdictions assign/assume copyright by default, and make it hard to 'remove'. Otherwise authors would see their work ripped off in a lot of inventive ways.
When the default state is that every work is copyrighted, that removes a lot of possible confusion, and possible excuses.
It's a fine article, but not a fine introduction. I read more as a list of all the things the author didn't understand (or pretended not to understand), because they couldn't describe them mathematically.
I assume it's written partly tongue-in-cheek, to show how arbitrary a lot of music tradition is, and how it creates a barrier to entry.
And the article didn't even mention different clefs or transposing instruments!
Professors could change the numbers in the questions every year, without really changing the questions.
And then give the answers after the homework was handed in, if they want to grade the homework. Or compromise, by giving answers to half the assignments, and not grading those.
Nothing in the GDPR stops websites from honoring "Do not track" and then _not asking_ if it's present. They don't have to ask if they don't track you! They don't have to ask for a technically necessary session cookie that appears after you actively log in!
Websites ask because they want to track you! A 'law targeting browsers' would not help because people would say no to cookies, and then websites would ask about some other way to track you. Because they want to track you.