Readit News logoReadit News
latk commented on Net-Negative Cursor   lukasatkinson.de/2025/net... · Posted by u/todsacerdoti
joshstrange · 7 months ago
> And this is not a cherry-picked example by me. This is the first thing Cursor shows potential customers to demonstrate how good this AI-powered tooling allegedly is

I think this perfectly encompasses "vibe coding" [0], "Hey, it looks cool. Ship it. Don't worry about what's under the hood!".

[0] I'm using this term to specifically mean people using LLMs to write code with with doing very little or no checking of the code it writes, just what the website/app looks like.

latk · 7 months ago
Author here. Yep, that's close to my thinking. I don't actually believe that Cursor (or similar tools) are completely shit.

But I worry that the Cursor team perhaps doesn't care whether their product actually delivers value. That they just want to sell the appearance of productivity.

This, to me, is a much bigger concern than everyday performance of their tool. Tools can be improved, organizational culture usually not.

But this is wild speculation. I didn't want to write this as the conclusion of the actual article, which tried to be more factual and to take their marketing at face value.

latk commented on Shopify Is Illegal in Germany   lsww.de/shopify-illegal/... · Posted by u/wusel
ghoward · 3 years ago
Mini Ask HN: How would a small company, say a code forge, that is based in the US ensure that it is operating such that it is legal to have EU customers?

All operations will be in the US (interaction only through a website). The forge will be designed to allow all of a user's data to be downloaded by that user (easy access to all data). It will also allow wiping away any reference to a user in commits (right to be forgotten).

But PII does need to be collected, such as username, password, IP address, public keys, etc. There are zero plans to collect anything that is not needed; only the minimum data needed will be collected.

Edit: Oh, and the forge would not send data to third parties at all, unless such third parties are cloning code, but then they would be users, right?

Would it be legal to accept EU customers? If not, would there be anything to do to make it legal?

latk · 3 years ago
Offering a service to European consumers?

Probably not a big issue. GDPR compliance can be challenging without a suitable mindset, but it's not impossible.

* Consider that the GDPR has an extremely broad concept of “personal data” – it's not just identifying info but anything that can be reasonably linked to a person!

* Data minimization – only collecting what is needed, and only using it as actually needed – is already a great step.

* Writing a GDPR-compliant privacy notice can be a good exercise to understand what data you're processing for which purposes. Art 12–15 GDPR are the closest it gets to a checklist.

* And you'll have to implement “appropriate” security measures, but what is appropriate is largely up to you.

The more challenging part is ensuring that you're only using data processors/vendors that are contractually bound to use the data as you instruct, and that you protect “international transfers” where the recipient (e.g. vendor) is outside Europe. If you're looking for server locations in North America, I recommend looking at Canada since they have an “adequacy decision” from Europe.

You will have to be GDPR-compliant if you “offer” your service to people who are in Europe, i.e. actively market to such people, or have testimonials from EU customers, offer French localization, accept payment in EUR, and so on. Mere availability of your service is not an offer.

Offering a B2B SaaS service to companies that need to be GDPR-compliant?

You're fucked. There is no legally safe way for a company to use an US-based data processor, i.e. to engage you as a vendor. However, and this is your “get out of jail” card, many customers don't care, and will be happy as long as they can sign “SCCs”.

latk commented on GDPR penalty for passing on of IP address to Google by using Google Fonts   rewis.io/urteile/urteil/l... · Posted by u/sitting_duck
codethief · 4 years ago
You're missing the point (and mischaracterizing the court decisions): An IP address by itself (without any additional information, e.g. the URL of the website requested by that IP address) cannot possibly be personal data, as was illustrated by my "for loop" example.

The present court case and also the one you're referring to (Breuer v. Bundesrepublik Deutschland[0]) do not say anything to the contrary. They were concerned with situations where there is additional data that could be used e.g. to build a user profile. For instance, the Bundlesgerichtshof judgment addressed the question of "whether dynamic IP addresses of website visitors constitute personal data for website operators" [0] (which clearly know which website the visitor visited and therefore possess additional data about the visitor).

[0]: https://medium.com/golden-data/breyer-are-dynamic-ip-address...

latk · 4 years ago
I can't agree, but maybe this is semantics :)

For something to be personal data, it must be information that relates to an identifiable natural person. There are two criteria here: (1) it must relate to a natural person, and (2) that person must be identifiable.

Your “loop over IP all addresses”example does not involve personal data because the information doesn't relate to anyone – it is just a list of numbers. Even if it were to relate to individuals, no court would order an ISP to disclose information about corresponding subscribers for such generated IP addresses. Then, the identifiability argument in Breyer cannot work.

In contrast, an IP address that is part of an IP packet received by a server clearly relates to the person sending the packet, if there is such a person. And, with the help of third parties, the person on the other end of the connection is reasonably likely to be identifiable. This does not depend on the website operator having any additional information such as cookie identifiers, other than the date. To avoid confusion, let me quote the relevant part from Breyer:

> 49. Having regard to all the foregoing considerations, the answer to the first question is that [Art 4(1) of the GDPR] must be interpreted as meaning that a dynamic IP address registered […] when a person accesses a website […] constitutes personal data within the meaning of that provision, in relation to that [website] provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person.

The only additional data involved here is that held by the ISP, not by the website. That the judgement scopes its conclusion to website providers must be understood not as a limiting factor (as in: IPs can be personal data only for website providers), but as a contrast to the uncontested observation that IPs clearly are personal data for ISPs.

An IP address that relates to an identifiable person is personal data by itself. Thus, its mere disclosure to a third party without a legal basis is a breach of the GDPR. The article you linked highlights the “absolute vs relative” identifiability discussion, but this reasoning holds even under the “relative” standpoint because Google too is a website operator who has the same reasonably likely means for identification as the original website operator, if not substantially better means due to its trove of other data it can correlate with the IP address.

In this LG München case, the court determined that sharing this data with Google was illegal, regardless of whether there is any additional data. It is, in a sense, a very formal argument, that doesn't consider it necessary to dive into specific fact patterns (that's the abstract vs concrete means part quoted in my previous comment). The court did consider the impact of Google's tracking abilities in calculating damages, though.

To summarize my disagreement with your comment: (1) I assert that an IP address by itself can be personal data for a website operator (such as the defendant or Google), per the Breyer argument. (2) The LG München judgement in this Google Fonts case is not concerned about additional data when considering the legality of processing. (3) Additional knowledge held by the website operator is irrelevant for both this case and the Breyer judgement. Since a negative is difficult to prove but a positive can be shown by a single example, could you please point out the paragraphs in the Google Fonts case[1] or the ECJ's Breyer judgement[2] where I'm mistaken for disagreements 2 or 3?

[1] https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/

[2] https://curia.europa.eu/juris/document/document.jsf?docid=18...

latk commented on GDPR penalty for passing on of IP address to Google by using Google Fonts   rewis.io/urteile/urteil/l... · Posted by u/sitting_duck
ratww · 4 years ago
> I can imagine a feasable future where it could be replaced with an anonymised IP from a larger pool generated by your ISP, with TLS for the payload.

This is already a thing with NAT and Carrier-Grade NAT.

However if the IP + port + time trio, coupled with other information (such as browser, stack, timezone, behavior) can be used to de-anonymise the user, this also instantly becomes PII.

> This could be solved at the internet infrastructure layer, and not required by to be solved by website developers.

It could, but until we get there, website developers will have to deal with it.

latk · 4 years ago
Identifiability for IP addresses uses an even lower standard. The GDPR says that for something to be truly anonymous, there must not be any “reasonably likely” means for identification, even with the help of third parties, even when relying on additional information. There has of course been litigation about this, in the form of the Breyer v Bundesrepublik Deutschland case. It was based on the GDPR's predecessor law, but it used virtually identical phrasing so the conclusion still holds.

The European Court of Justice constructed a hypothetical scenario to show that identification can reasonably be likely. Let's say the website was attacked by a hacker. In a logfile, you find the attacker's IP address and want to prosecute them. So you report the incident to whatever authority is responsible for such incidents, which then gets a court order so that the attacker's ISP discloses information about the IP address. As long as the ISP knows to whom that IP was allocated at the time, there is now a reasonably likely chain of events that leads to identification of the person behind the IP address.

In this case about Google Fonts, the court says that it's sufficient if the website operator or Google have the “abstract means” for identification, not whether they actually did this for this plaintiff's specific IP address.

A solution would be if the EU forbids ISPs from keeping such logs, but given repeated attempts at mass data retention laws for national security purposes and pressure from the IP industry^W^W film and music industry for copyright infringement prosecution purposes, that doesn't seem likely.

latk commented on GDPR penalty for passing on of IP address to Google by using Google Fonts   rewis.io/urteile/urteil/l... · Posted by u/sitting_duck
Spoom · 4 years ago
> self-host the fonts

Do you, as the website operator, have the right to copy and serve these fonts to your visitors? (Actual question; my guess is that you don't according to Google Fonts, but could be wrong.)

> proxy the request through your own servers

Isn't this worse? Assume that your visitor does not want Google contacted at all as part of their visit; isn't, then, the potential leak of an IP address simply a side effect? The website is still leaking timing of when a visitor accessed the site, potentially their usage patterns...

Personally, I think this is a bit of an absurd argument... I think, at most, consent should be enough for third party requests. I was mostly responding to GP's claim that the user can't reasonably consent to such use.

latk · 4 years ago
> Do you, as the website operator, have the right to copy and serve these fonts to your visitors?

All the fonts on Google Fonts are open source. When GDPR came into force in 2018 I downloaded all the fonts I needed, checked their licenses, and uploaded them on my servers along with necessary notices as required by the licenses.

The matter could also be sidestepped if the CDN were to offer a GDPR data processing agreement (DPA) and would make guarantees about the locations of servers. The free public CDNs understandably don't do this, and it seems Google Fonts is not covered by the Google Cloud DPA.

latk commented on GDPR penalty for passing on of IP address to Google by using Google Fonts   rewis.io/urteile/urteil/l... · Posted by u/sitting_duck
codethief · 4 years ago
But GP has a point: An IP address (together with a timestamp) may be used to identify you a person but if it's not connected to actual personal data (e.g. what website you visited), "leaking" it to Google doesn't provide Google with any data about you.

I mean, IP address ranges are publicly known. If I now run a `for` loop over all IPv4 addresses and write them to my HDD, am I suddenly illegally storing personal data of all the people behind those IP addresses? Obviously no. An identifier by itself is not worth anything, unless it's connected to actual personal data.

EDIT: Never mind. GP's assumption that "there’s no Referer header - which there won’t be, assuming Referer-Policy is set sanely (which by default it is in all browsers)?" does not seem to hold in my browser. So Google does not only receive the IP address but also the HTTP REFERER.

latk · 4 years ago
The court judgement addresses this exact point. There are previous judgements (Breyer v Bundesrepublik Deutschland) that establish that dynamic IP addresses are personal data. There are reasonable means to identify the data subject with the help of third parties, such as the ISP. “For this it is sufficient that the defendant has the abstract means for identification of the person behind the IP address. Whether the defendant or Google have the concrete means for linking the IP address with the plaintiff is irrelevant.”

That there is correlating information like timestamps, useragent strings, or referer headers increases the likelihood of actual identification, but the mere reasonable possibility of identification is sufficient for IP addresses to be personal data.

latk commented on GDPR penalty for passing on of IP address to Google by using Google Fonts   rewis.io/urteile/urteil/l... · Posted by u/sitting_duck
maratc · 4 years ago
> I don't think you get the agency argument.

I do get that argument; I just don't think it holds any water.

If one hires a hitman to kill someone, that one may still be held accountable to manslaughter, even if that specific person didn't kill anyone themselves. It may also not matter how many degrees of separation are there between that person and the hitman: as much as putting a (Bitcoin) bounty on someone's head (with a "smart contract" or whatever) may be considered manslaughter, even if nobody knows who the actual hitman is.

"Agency" is not a magic get-out-of-jail card.

Also, one may try convincing a judge "Your honor, it's true that I wrote the code that encrypted the plaintiff's network and wrecked a havoc, but I did NOT execute it; the plaintiff could have instructed his CPUs to not execute my code"; I don't know if this argument would hold.

Finally, there might be a "reasonable burden" argument in this case. It's reasonable to expect that website builders would know how browsers/internet work. It's not reasonable to expect that website visitors (general populace) would know that. Hence, the burden of GPDR compliance is better put on the builders' shoulders, which is exactly what happened in this particular case.

latk · 4 years ago
I discussed that argument over here: https://news.ycombinator.com/item?id=30139489

Summary: A company did try the “it was the browser, not us” argument in the “Fashion ID” case. The court did not fall for it. Data controller and thus responsible for compliance is whoever determines the purposes and means of processing. Being able to control what the website does seems to be good evidence for being a data controller.

In this Google Fonts case, the website operator didn't even try this discredited argument.

latk commented on GDPR penalty for passing on of IP address to Google by using Google Fonts   rewis.io/urteile/urteil/l... · Posted by u/sitting_duck
xtracto · 4 years ago
This is a pretty sad state of affairs IMO. The fact is that CDNs and similar third party services play an important role. Websites wont stop us6them, it's not feasible (btw if I "host" my fonts in S3 do I have to get consent for sharing IP with Amazon? With DNS? with every router that goes through tracert?) .

In reality, websites will add more crap "opt in" CYA forms at first loading, making the interaction fugly and unusable. We can discuss here in HN how that is unnecessary and whatnot, but that's what's going to happen...

I just wish that websites wouldn't force us outside of the EU to the asinine UX required by the EU (I hate having to press ACCEPT ALL on each page I visit.... whatever I dont want is already blocked by an extension anyways).

latk · 4 years ago
> The fact is that CDNs and similar third party services play an important role.

They no longer do, since browsers implemented cache isolation.

> if I "host" my fonts in S3 do I have to get consent for sharing IP with Amazon?

No, you're supposed to contractually bind your vendors/service providers as data processors with a contract (“data processing agreement”) per Art 28 GDPR. There's some debate around whether US-based companies are legally able of entering into such an agreement (say hello to the Cloud Act from me), but the general consensus still is that non-US cloud regions might be OK, and that CDNs that let you sign a DPA (like Akamai, Cloudflare, Fastly, …) are also OK. In contrast, Google Fonts does not seem to be covered by the Google Cloud DPA.

> with every router that goes through tracert?

No, such mere transmission doesn't count as processing, and/or the intermediaries are responsible for their own compliance. In any case the connection should be protected by TLS so that only the client IP address + your domain name is visible to intermediate routers.

> websites will add more crap "opt in" CYA forms

Unfortunately, I agree, though the point of this judgement is that self-hosting some assets is a perfectly cromulent alternative. I think relying on “consent” would be difficult in a case like this, since it is not generally possible to make access to a service conditional on consent to unnecessary processing activities. Using a CDN for assets like files is unnecessary.

> I just wish that websites wouldn't force us outside of the EU to the asinine UX required by the EU

For EU-based websites there is no choice, as the law doesn't care about where the users are.

There's also a bit of irony in here that there has been a lot of work in replacing the cursed cookie consent requirements that gave us most of these annoying consent banners – but the past few months revealed that the US tech giants have been successfully lobbying against the proposed ePrivacy Regulation. So please redirect your ire against Google. Without them this might have been fixed in 2018.

latk commented on GDPR penalty for passing on of IP address to Google by using Google Fonts   rewis.io/urteile/urteil/l... · Posted by u/sitting_duck
phkahler · 4 years ago
>> This is exactly what happened...

Not quite? Wouldn't the users browser have sent its own IP address to Google? That's different that "forwarding" it, and it may not even be enough for Google to connect the user to that site.

latk · 4 years ago
This argument was tried in the Fashion ID case. A company had inserted Facebook Like buttons on the web page, and argued that it was not responsible for the ensuing disclosure of personal data (such as IP addresses or possible tracking cookies) to Facebook. See, it was the browser and not the website operator that disclosed the data, and the website operator never had access to the data in the browser in the first place!

The European Court of Justice did not buy this argument. By coding the website in a particular way, the website operator was responsible for causing the user's browser to act in a particular way, so it was the “data controller” for the collection an transmission of personal data by the Facebook Like button, though Facebook is of course jointly responsible for what their code does.

The underlying argument is that someone is a data controller and thus responsible for GDPR compliance when they determine the “purposes and means” of processing, alone or jointly with others. Embedding the code for the button was an exercise of this power to determine purposes and means. In contrast, the website operator is not a data controller for whatever Facebook does with the collected data on its servers, because it cannot control what FB does.

The given case from Munich is a very straightforward extension from the Fashion ID judgement, though the website operator didn't even claim that they weren't responsible. Instead, they argued that they had a “legitimate interest”in loading fonts from Google servers, which the court rejected. While I consider it probable that Google does not use data from Fonts servers for tracking, the judgement correctly points out that Google is well-known for tracking – but this doesn't matter anyway, since already the disclosure of personal data without a legal basis is a problem.

latk commented on GDPR penalty for passing on of IP address to Google by using Google Fonts   rewis.io/urteile/urteil/l... · Posted by u/sitting_duck
onli · 4 years ago
> In fact, since in parallel to the question of your legal basis under GDPR, you also have to comply with the cookie provision from the e-Privacy Directive, where there is no "legitimate interest" exception to the requirement to ask for consent, you will have to ask for consent anyway (as Instagram embeds place cookies).

I don't think that's true. The cookie provision is misunderstood when you think you have to ask for consent for functional cookies. Follows from the GDPR, and there is no specific cookie law actually implemented in european countries. See also https://gdpr.eu/cookies/. Ah, but maybe I misunderstood and you are only talking about the cookie set by the embed?

latk · 4 years ago
Careful. That is an 100% unofficial site. It is not chartered or funded by the EU. The linked article is from “Richie Koch”an editor working on human rights stories who wrote the article on behalf of Proton VPN, which runs the GDPR.eu site as a content marketing scheme. The linked article is not the law and not official guidance, though it provides a reasonably good summary.

Everything sqrt2 says in the comments is entirely correct, as far as I can tell.

u/latk

KarmaCake day285February 18, 2013View Original