The mother had a claim because the house was literally given to her, which was the right of it's previous owner.
This person has no claim.
If the previous owners wanted it to remain with the family line they should have formalized that by placing the house in a trust.
These are protesters, not terrorists. A reputable news agency isn't going to take sides one way or the other. The reporting should be structured more like a debate, with both sides allowed to voice their positions in neutral language and offer a rebuttal.
If you can easily tell which side of the issue the presenter is on you're seeing an opinion piece, not news.
Sure, they don't rule the world. They only have the power to ban you (either the company per se or its individual owners, officers, and/or employees) from ever again doing any business in the EU. Which naturally includes business with any individuals or companies either based in the EU (as a seller or a buyer) or wanting to do business in the EU. Or from traveling to the EU, whether for business or personal reasons. Little things like that. Nothing too inconvenient. (/s)
They haven't taken things quite that far—yet. But they could. It's dangerous to assume that you can ignore them without consequences just because your company doesn't currently depend on revenue from EU customers. The world is more interconnected than that, and the consequences may not be limited to your company.
Geoblocking in such cases would not be sufficient. For one thing your geo-IP database will never be perfectly accurate, even without considering that "data subjects who are in the Union" can connect to your site via proxies or VPNs with non-EU IP addresses. For another you still need to respond to GDPR requests e.g. to remove data collected on a data subject currently residing in the EU, even if the data was collected while they were outside the EU, and you can't do that if you're blocking their access to the site. For a newspaper in particular the same would apply to any EU data subject they happened to report on, whether they had previously visited the site or not.
They never should have made opt-in an option in the first place. All the legitimate reasons to store data are already permitted without asking permission (required for the site to function, or storing data the user specifically asked the site to store such as settings). All that's left is things no one would reasonably choose to consent to if they fully understood the question, so they should have just legislated that the answer is always "no". That plus a bit more skepticism about what sites really "need" to perform their function properly. (As that function is understood by the user—advertising is not a primary function of most sites, or desired by their users, so "needed for advertising to work" does not make a cookie "functional" in nature. Likewise for "we need this ad revenue to offer the site for free"; you could use that line to justify any kind of monetization of private user data.)
In what sense do you think this isn't following the email standard? The plus sign is a valid character in the local part, and the standard doesn't say how it should be interpreted (it could be a significant part of the name; it's not proper to strip it out) or preclude multiple addresses from delivering to the same mailbox.
Unfortunately the feature is too well-known, and the mapping from the tagged address to the plain address is too transparent. Spammers will just remove the label. You need either a custom domain so you can use a different separator ('+' is the default but you can generally choose something else for your own server) or a way to generate random, opaque temporary addresses.
If you want to talk about non-compliant address handing, aside from not accepting valid addresses, the one that always bothers me is sites that capitalize or lowercase the local part of the address. Domain names are not case-sensitive, but the local part is. Changing the case could result in non-delivery or delivery to the wrong mailbox. Most servers are case-insensitive but senders shouldn't assume that is always true.
CVS and E*Trade both refused to accept my fairly standard user@mydomain.info address during initial registration, but had no issue changing to that address once the account was created. It would be nice if their internal teams communicated a bit better.
The full email address syntax described in the RFC cannot be precisely matched with a mere regular expression due to the support for nested comments. The need to track arbitrarily deep nesting state makes it a non-regular language.
If you remove the comments first the remainder can be parsed with a very complex regex, but it will be about a kilobyte long.
If someone said to me: we will meet two weekly...
You're essentially assuming the conclusion by grouping it like that. There are three parts to "biweekly", "bi-", "week", and "-ly". "Once per biweek", i.e. once per 14 days (or per fortnight), makes at least as much sense as "two" × "weekly".
I have no idea how anyone thinks that meaning semi-weekly means twice weekly.
Meeting semiweekly (semiweek-ly, if you must hyphenate it) means meeting every semiweek, or every half-week (3.5 days). Which is an odd internal to meet at if taken literally but would result in meeting twice each week. "Semiannually" is a more common example, and I've never seen or heard it used to refer to anything but a 6-month (half-year) interval.
bi-sect: cut into two parts; from Latin "bi-", two, and "secare", to cut.
The "sect" part is critical. "bi-" on its own doesn't imply division.
Good point. You'd need at least 215 bits to represent all measurably distinct times (in multiples of the Planck time, approximately 10^-43 seconds) out to the projected heat death of the universe at 100 trillion (10^14) years. That should be sufficient for even the most detailed and lengthy simulation.
This is incorrect. The distributor of derivative works in binary form is responsible for providing the source code. They can refer to a server operated by a third party, but if that third party stops providing the source code the distributor remains obligated to ensure that it is still available. The only exception is for binaries which were originally received with a written offer of source code, where the offer can be passed on as-is, but that only applies for "occasional and non-commercial" distribution which wouldn't work here.