> European companies selling only to non-European customers don’t have to comply with GDPR.
Usually they do. European company processing personal data of non-EU customers falls with article 3(1) "This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not."
Of course if they do not process any personal data then it wouldn't apply but that's pretty unlikely (and if that was the case the EU customers data wouldn't fall within GDPR either).
Not quite true. In Finland YEL (yrittäjän eläkevakuutus, pension insurance for entrepreneurs) is required and it's based on estimated value of the entrepreneur's work input. Even if you pay yourself 0 euros your YEL income is likely higher. The models that insurance companies use take revenue in account.
There seems to be grey deny button at top-right on first view but it disappears if you select the details. You need hide the details first if you want to click it.
> In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC6125]. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4]) MUST reject names that would be interpreted as IPv4 addresses.
"You DON’T need consent for: First-party cookies used just for your own analytics (in most cases)"
They claim that, but the page they link to as the source says "You must...Receive users’ consent before you use any cookies except strictly necessary cookies.". So what exactly makes them think that first-party analytics cookies are "strictly necessary"? The Mastodon link in the at the start of page doesn't seem to work.
that might be overdoing it. I don't know where is the current case law, but IMHO storing a random number and identifying the retuning user is not PII (to count how many times that user returned).
now of course if it gets joined with other data it can become PII.
IP address is usually treated as PII, because it can have very high "selectivity" (and with a subpoena can be turned into PII, whereas a site specific cryptorandom cookie id cannot)
This is what European Commission has determined to be acceptable for them. One very important distinction here is, as far as I understand, that EC is not bound by ePrivacy Directive as directives bound member states and require them to include them on their national law.
The text on that website does state that some DPAs have found some first-party analytics acceptable, but that's not something that is confirmed by CJEU. And ePD does not have single-stop shop so you need to follow every DPAs directions if you are offering services to that DPA's country.
> Also /bin vs /sbin believe is that the latter is meant for statically linked binaries such that if your system is corrupted these at least will keep working.
My understanding is that sbin for system binaries, not necessarily statically linked. Normally /sbin is only in root's PATH, not normal user's. They are likely world executable, but in many cases you cannot actually run them as non-root since they usually touch things only root can access without special access (e.g. raw devices, privileged syscalls, /etc/shadow etc.). Not always though, like you can run /sbin/ifconfig as normal user in read-only mode.
The 's' is for 'static' version of the explanation of the name of sbin is not actually supported by any 20th century Unix doco. The books on AT&T Unix System 5 (before which, things were in /etc) that actually give an explanation for sbin all say system binaries, or system administration commands; and none of them says anything about linkage.
The 'static link' story came from Linux people years afterwards. Here's Ian McCloghrie correcting this misconception in a Linux discussion back in 1993:
I would disagree somewhat on his stance that video quality is not affected by container format (especially on part "Here is a list of things that people commonly associate with a video's quality"). Different container formats have different limitations regarding what video (and audio) formats they support. And while it subtitles support doesn't directly affect video quality, it does do so indirectly. If you cannot add subtitles without hardsubbing or subtitle formats are so limited that you end up needing hardsubbing anyway then the choice of the container format ends up affecting the video quality.
Did you confirm it was a scam? Primarily wondering if it's possible that the company itself contracted someone to do phishing test for new employees. I know there are plenty that do email version of this.
I got these around the same time frame. The funny thing is that the named CEO was for a company I'd left the year prior. I was still in touch with coworkers from that company, and they told me that it wasn't a training exercise by the infosec team. The infosec team had actually warned people about it after hearing about people getting those texts.
I would hope they don’t do that before I start using my personal number.
If someone did fall for it, the potential that your employees would spend real money that they wouldn’t get reimbursed for would definitely piss a lot of people off.
If they did it I would assume they would do it in a way that the employee would need to get some information first (e.g. the amount or type of gift card) before committing to anything. Or directing to buy it from some fake web shop.
Ceo scam is very common. Anytime someone claims to be a ceo verify! CEO is a popular target because they have power and can request weird things of employees who don't know them in normal business.
I know. That's why I wondered if some companies had started running training exercises for the phone variants. Personally I have only encountered the email ones previously.
> I mean, it absolutely worked for effectively sinking the DMCA, where pretty much everyone now equites that law with obnoxious 'cookie banners', to the point that these regulations are being relaxed.
I don't think DMCA has anything to do with that though I did wish everyone hated it. You probably meant GDPR.
It doesn't require consent for cookies or similar data that are strictly necessary to do what the user has asked for - a token for logging in or the contents of a shopping cart are the two canonical examples.
It certainly does require informed consent in other situations though and the dreaded cookie banners were the industry's attempt to interpret that legal requirement.
No, it's now entirely accurate. Nothing in the GDPR requires 'cookie banners', and your Wikipedia link doesn't 'dispell' that 'misconception', but nice try...
My point is that it was never the GDPR that required any sort of "cookie banner" in the first place.
The cookie banner requirement is itself a widespread misconception because the actual rule is neither specific to cookies (it would also cover other locally stored data) nor universal (for example it doesn't require specific consent for locally storing necessary data like session/login mechanics or the contents of a shopping basket).
The requirements for consent that do exist originate in the ePrivacy Directive. That directive was supposed to be superseded by a later ePrivacy Regulation that would have been lex specialis to the GDPR - possibly the only actual link between any of the EU law around cookies and the GDPR - but in the end that regulation was never passed and it was formally abandoned earlier this year.
So for now rules about user consent for local data storage in the EU - and largely still in the UK - do exist but they derive from the ePrivacy Directive and they are widely misunderstood. And while there has been a lot of talk about changes to EU law that might improve the situation with the banners so far talk is all it has been.
Usually they do. European company processing personal data of non-EU customers falls with article 3(1) "This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not."
Of course if they do not process any personal data then it wouldn't apply but that's pretty unlikely (and if that was the case the EU customers data wouldn't fall within GDPR either).
reply