buzer

Article 13(2)(f)

"In addition to the information referred to in paragraph 1, the controller shall, at the time when personal data are obtained, provide the data subject with the following further information necessary to ensure fair and transparent processing: the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject."

EDPB Guidelines on automated decision making: https://ec.europa.eu/newsroom/article29/items/612053 especially page 25 is relevant

C‑634/21 is also somewhat relevant to understand how courts have applied ADM in general context of credit reporting https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A... though it didn't specify what information actually needs to provided for 13(2)(f).

Private cameras pointing to street can be lawful under GDPR, but in that case they are GDPR controller. That then requires them fulfill bunch of obligations which they probably aren't, e.g. giving proper Article 13 notice.

I don't know if it's criminal in any EU country, but it would be something that you could complain to DPA about. Or initiate civil lawsuit against the controller.

Worth noting is that in some cases the camera vendor might also be (joint) controller as they can determine means & purposes of the processing. If they are simply storing the video then it's unlikely, but if they for example use it for AI training that would likely bring them controller territory.

> Is there a way around this shitocracy?

If you are in EU you could try complaining to your local DPA. That certainly sounds like "automated decision which produces legal effects concerning him or her or similarly significantly affects him or her" which is against article 22 of GDPR. Or you could consider suing them directly at least for the refund.

Outside of EU maybe try passing law like GDPR to actually get some rights back.

Secrecy of correspondence doesn't necessarily only apply to physical letters as far as Constitutions go. In Finnish constitution it is defined as "The secrecy of correspondence, telephony and other confidential communications is inviolable" meaning it also applies to any internet message.

Unfortunately large majority of parties in Finnish Parliament do not really care about that provision and have passed multiple laws which create exceptions to it. They do it via the proper protocol (which is essentially the same as modifying the Constitution itself) so it's technically legal.

From my understanding Charter of Fundamental Rights of the European Union is somewhat similar to US Constitution & amendments. Both do still allow government to restrict the freedoms granted by those in some situations though I do think the US Constitution does tend to set higher bar on the interference.

There have been EU laws which get struck down because they violated the Charter (e.g. Data Retention Directive).

> all consumer-grade routers produced in foreign countries

Are there even consumer-grade routers that are produced in the USA...?

> Another more plausible scenario is countries simply start repealing safe harbor laws.

It already happened via GDPR to some degree. CJEU ruled in December that platforms can qualify as controllers for personal data published in user-generated advertisement. The given reasoning was basically that the platform determined the means and the purposes of the processing.

Due to that they can be liable for article 82 damages.

As far as I understand the $100k fee applies only to consulate issued H1Bs. L1 -> H1B path (via AOS) is possible without fee. (Recent) US university graduates can also use similar path from what I understand.

We will see how much the $100k fee affects things during this H1B lottery round in few weeks.

The bill text is at https://github.com/righttoprivacyact/bill/blob/main/bill/rig...

It contains following:

> (i) Finance and high-risk identity proofing.—No person shall extend credit, originate a loan, open a high-risk financial account, or provide another high-risk financial service based solely on a Social Security number, static identity information, or an uploaded image or copy of a government-issued identity document. A person engaging in such activity shall use multi-factor identity verification reasonably designed to verify both record consistency and claimant control, using less intrusive reasonably reliable methods where available.

> (j) Social Security number not sufficient identity credential.—A Social Security number, taxpayer identifier, or similar identifier shall not by itself be treated as proof of identity for purposes of this Act.

So, to me at least, it sounds like they actually mean "Providers must not use SSN for authentication (including fraud)".

That's weird, I can login to my HealthEquity account (which contains HSA) without any issues and I don't have passkey setup. I confirmed it just now just in case.

That article does say "HealthEquity Mobile and web experience" so maybe it's just for customers who use both, I only use web.

> you agree to American terms and conditions, arbitrated by American courts.

"Designated Countries. We use the term “Designated Countries” to refer to countries in the European Union (EU), European Economic Area (EEA), and Switzerland."

"If you reside in the “Designated Countries”, you are entering into this Contract with LinkedIn Ireland Unlimited Company (“LinkedIn Ireland”) and LinkedIn Ireland will be the controller of your personal data provided to, or collected by or for, or processed in connection with our Services."

"If you live in the Designated Countries, the laws of Ireland govern all claims related to LinkedIn's provision of the Services" "With respect to jurisdiction, you and LinkedIn agree to choose the courts of the country to which we direct your Services where you have habitual residence for all disputes arising out of or relating to this User Agreement, or in the alternative, you may choose the responsible court in Ireland."

Source: https://www.linkedin.com/legal/user-agreement

I'm not sure from where you got your information.

According to AP News (https://apnews.com/article/international-court-sanctions-tru...) at least one judge had his bank accounts closed. So it's not just your own government who can debank you in Europe.

Of course in this judge's case there might still be some banks who are willing to work with him even at the risk of getting sanctioned as there weren't language in the news that he was completely debanked which I assume they would highlight if it was the case.

Personally I found Flowdock's thread model the best at least for small'ish teams (company size was <30). You can see it in action at https://web.archive.org/web/20210728031306/http://blog.flowd.... Unfortunately the company itself didn't survive. It was eventually acquired by CA which then killed it later.

(from my older comment) Essentially there is a default view which contains all messages as usual. Each message also has a symbol next to it. If it's grey message bubble, it's a message that is not tied to any thread (it can be replied to to start a new thread. Previously if no other messages have appeared on channel so far, it can be dragged & dropped to another thread). If it's colored message bubble, it's the first message in the thread. A colored arrow means it's part of the thread with that color.

This allows you to mostly just stay in default view with all of the channel's messages. As long as people are putting the messages in the thread itself, you could quickly use the colors to see which thread the message is on (color collisions did happen, but they were fairly rare). You would need to open the thread only if you needed more context or wanted to reply to it, though replying can also be done by writing to channel & dragging the message to thread.

So just to clarify there are two different things here:

The information that fraud detection is being performed is something that needs to be disclosed. That's what would be part of the article 13/14 (13 is when controller collects data directly from subject, 14 is when they receive it from anywhere else (including generating it themselves)) notices. It's very rare that any law would forbid giving any kind of article 13 notice, that's why banks do disclose that they process personal data for AML purposes in their privacy policies.

Article 14 itself however does allow omitting the notice in certain circumstances, but those are quite limited. Fraud detection can fit here, but usually only in the context where controllers transmit the information to other controllers regarding risky clients and such. The actual fraud detection itself is a different purpose and it's objectives are not, generally speaking, in risk just because someone knows that certain company ran the fraud detection on this transaction (since fraud detection is run on every single transaction).

The "how" is part of the second thing. That's generally more on article 15 (and 22) territory where controller could omit the information why exactly the transaction was denied (and possibly things like transaction's fraud score). I don't really like the current interpretations either (as it makes it pretty impossible to fix incorrect information) but unless CJEU gives some ruling in the issue it's unlikely that DPAs & EDPB are going to enforce some changes there.

Sure, but that's in connection with SARs and such (which have legal obligations are around secrecy). What I mean are the "generic" credit card payments where payment processors & banks process the personal data for things like fraud detection. That's perfectly fine legitimate interest, but that doesn't absolve them from article 14 requirements as fraud prevention doesn't have such requirements around secrecy around the fact that it even exists. They can restrict some detailed information e.g. regarding algorithm itself by relying on trade secrets, but that is different from their obligation to inform data subject that they received the information.

It's important to note that 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. They do still try to be consistent with how the directive is applied in the member states though but since it can be varied they have more leeway compared to most other controllers.

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.

On the "German DPA can only forward it to Czech DPA" there is now regulation (2025/2518) around the cross-border enforcement and as far as I understand it actually has hard deadlines. However it will only start being in effect around May 2027 and will only affect cases which were filed after that. It is still very long process and does require that the original DPA actually initiates things.

The spam filter loophole is unlikely to be legal. It it contrary to other DPA rulings (like Norwegian DPA ruling on Mowi ASA), EDPB guidelines don't strictly define it but I would say tilt towards that excuse not being sufficient & my understanding is that there are also some court cases from Germany and Austria that treat messages routed to spam as recieved (https://www.nospamproxy.de/en/emails-in-spam-folders-are-con...). Of course if you want to actually enforce it you would need to appeal the decision in court, I have no clue how easy or hard that is in Germany.

If you mean what they are planning to change (as part of the omnibus) there is report by NOYB https://noyb.eu/sites/default/files/2025-12/noyb%20Digital%2...

If you mean how CCPA/CPRA differs from GDPR there are lots of things. For example you are not entitled to know actual recipients of your data, only the categories. So you cannot really know who actually received your data which then prevents you from exercising your rights against those controllers (or covered entities in CPRA language). GDPR also requires companies to usually notify you if they receive your data as controller (though there are some exceptions), in reality that's not really happening though (e.g. how many payments processors or acquiring banks have notified you about your credit card payments?).

CPRA also allows selling your personal data if you do not opt-out, in GDPR that would generally require consent (except in certain situations where you can use legitimate interest as the basis). GDPR also regulates cross-border transfers a lot more closely as the idea is that the protections & rights travel with the data.

> Finland (where gyrovague is from)

They should probably review existing case around how Finnish courts treat the journalistic exception in the context of citizen's journalism (as he relied on that at least as one of the reasons): https://tuomioistuimet.fi/hovioikeudet/ita-suomenhovioikeus/...

Of course facts are different, but at least two Finnish court seem to require a lot more reasoning from the controller in the context of citizen journalism compared to traditional media when they want to invoke the journalistic exception. No clue which side this would fall into.

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

As far as I understand you cannot use IP address as the outer certificate as per https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.txt

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

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.

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

What is the source for that? Some of the oldest references to sbin I can find are 4.3BSD Net/2 man pages (https://man.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sek...) and Filesystem Standard v1.0 (https://www.ibiblio.org/pub/Linux/docs/fsstnd/old/fsstnd-1.0...). Former doesn't mention anything about static binaries, latter only mentions that static ln (and even mentions sln being static version of ln) and sync can be useful.

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

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.

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.

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.