Shopify Is Illegal in Germany(lsww.de) |
Shopify Is Illegal in Germany(lsww.de) |
The platform did not violate any local laws - it's outside the jurisdiction of the GDPR. They chose - and are within their right to do so - to cooperate with a legislative framework that is data-protection-averse (the US CLOUD act). This makes them incompatible with the EU, which they must be aware of. So why bother them?
The problem is 93689 German shops violating the law. Laws are written to accomplish goals. Execution is sometimes hard/impossible. You have to find ways that work, keep the eyes on the goal.
We have big institutions like government and shopify that should abstract their smaller components. These are not always constructive abstractions but they usually work just fine.
Apparently here a customer filled a complaint about 1 shop with the government. Government should to the best of its ability detect those issues before such complaint comes in. Given how big shopify is in Germany that becomes remarkably easy!
Are they seriously going to wait for a customer for each of the 93689 shops to bother to fill a complaint and then take up the issue with each of those 93689 shop owners?
The tax money would be better spend by giving it to shopify to fix the issue. That might not be legal but it would sure be cheap! They could also communicate to the list of shop owners that they are to stop using the platform. That would be more work but quite doable.
Could send the draft to shopify first and give them some time to resolve the issue if they desire it. Surely losing 93689 clients at once is worth some internal dialog.
He is suppose to be busy selling coffee so that he can bring in more tax revenue.
The idea was to keep the personal data in the EU. To what extend does all the current expensive busy work accomplish that? Not at all?
The politicians, the courts or agencies like the one that send letter to the author of this article.
I would say it is the politicians. By making laws.
Since the GDPR is the same in all EU countries, Shopify is either illegal in all EU countries or in none, right?
In theory, a DPA in your country must make a ruling. That's why Google Analytics is officially "illegal" in certain, but not all EU countries.
That said, it would be weird if subsequent rulings were not in line with previous.
It's on Digitalocean and serves only EU customers. DigitalOcean says they are full GDPR compliant, but given the cloud act this seems impossible.
What alternatives are available in Europe? It will be really frustrating to migrate
This is very limiting
Scaleaway seemed way better than the competition though in terms of price for the bottom line, allowing to grow gradually rather than having to go all in in terms of pricing.
They just did. It's called a fine.
> He is suppose to be busy selling coffee so that he can bring in more tax revenue.
He is to bring in tax revenue AND follow the law. If the government was just interested in tax income, drugs, racketeering and murder-for-hire would be legal as long as they filed taxes on that income.
I just remembered this in-depth discussion about hosting (which raised issues related to those in the discussion here).
> The CLOUD Act primarily amends the Stored Communications Act (SCA) of 1986 to allow federal law enforcement to compel U.S.-based technology companies via warrant or subpoena to provide requested data stored on servers regardless of whether the data are stored in the U.S. or on foreign soil.
So, it's not a Shopify specific issue.
Basically, the EU has put up a legal firewall between the US and the EU. Somehow this hasn't been realized fully or openly talked about, the the implication of their law is very clear.
These laws don't bind individual citizens, but companies offering services.
One might however ask, whether EU ISPs are allowed to route to U.S. as that passes IP addresses to U.S. companies. Maybe if they implement NATing?
As far as I know, it’s only one German court which once considered that an IP address was PII in a specific case. There is nothing in the law that explicitly says that IP addresses are PII.
I think you might be confused about the implications the German ruling has because you are from a common law country. One court ruling something doesn’t make it the law in Europe.
> anyone in the EU is not even allowed to connect to any website owned by a US company
This is blatantly false, of course you are allowed to connect to non-EU websites even if the IP address could be PII in some circumstances. It's the service providers problem to manage the data they collect in legal way.
Ie. logs should be ok if its to combat DDOS and the like (for a limited time, ie 24h), but not for advertising purposes.
The limitations are on the parties capturing the data, not on the person whose data it is.
Well, it's certainly not this:
> anyone in the EU is not even allowed to connect to any website owned by a US company
(Note also that YouTube does not actually use a streaming protocol, but replicates some features of streaming protocols like bitrate adaptation by downloading by chunks over HTTP(S).)
----
Also maybe how VLC is illegal to use as is in countries enforcing the DMCA or MPEG licenses :
https://wiki.videolan.org/Frequently_Asked_Questions/#What_a...
How can an IP address _not_ be PII?
NIST defines [1] PII as: "Information that can be used to distinguish or trace an individual’s identity ... either alone or when combined with other personal or identifying information..."
So it's not some EU caprice.
[1] : https://csrc.nist.gov/glossary/term/personally_identifiable_...
Oh it was. I had this conversation sooo many times. Each time response was: everyone is doing it, we will just wait and see :facepalm:
You don't have to make a direct TCP/IP connection for two people to communicate. We had systems like Usenet and UUCP that replicated data through a series of servers. Even today, when you use email, you talk to your email provider who talks to the recipient's email provider, and they have no need to share your personal IP addresses in the process. Some providers used to include this in Received: headers, but many today do not, rightly seeing it as a privacy concern. And even on HTTP we had (and still have, in some cases) mirrors, where legally-unrelated entities host copies of each others' data. Someone in the EU can visit http://ftp.icm.edu.pl/pub/linux/Documentation/ and never have their connection known to the US-juridiction host of TLDP.
It is both socially sensible for these providers to consent to sharing their own infrastructure IP addresses with other providers (but not share their customers' IP addresses) and legally practical for them to make that consent under the GDPR.
Why should it be the case that when you visit my personal website, which I happen to self-host, I have access to your IP address? I don't want that information. I don't even get that information when using higher-level services like Hacker News or Twitter or GitHub, even though those services operate over HTTP. It's weird that I get it, honestly.
I understand there's a huge planetary investment in HTTP, and so the collision of abstractly-reasonable privacy rights with that reality is an extremely hard engineering and policy problem. But that doesn't make the privacy rights unreasonable.
https://iapp.org/news/a/schrems-ii-impact-on-data-flows-with...
Why should I as a Danish entrepreneur trust a Hungarian hosting provider more than a US hosting provider?
You are not allowed to trust the US provider, since there are US laws that are not GDPR compliant. It is not possible to provide a compliant hosting service under US jurisdiction.
SCC = standard contractual clauses, aka DPA/GDPR clauses that govern when and how data transferred to the US is used.
> The ruling on Schrems II (the court case that struck down Privacy Shield) did not state that SCCs on their own would be sufficient. It said that SCCs + "additional safeguards" would be allowable. There have been several rulings already that SCCs on their own are not sufficient.
> The "additional safeguards" must include a risk analysis of US access to EU residents' data. Every court case I've seen from Schrems II onward identifies the US CLOUD Act as the privacy risk to address. CNIL is basically ruling that you cannot transfer data to a US company subject to the CLOUD Act, and an SCC cannot deal with that. This still leaves open the possibility of using US services that are not subject to the CLOUD Act. This is consistent with all rulings to date.
In summary, Schrems II + this ruling[1] mean that US corporations can't be involved with EU at all besides via licensing software to a completely independent EU corporation (which isn't a given either, though, since the US company could threaten withholding software updates/revoking the software license to pressure the EU corporation to hand over EU citizen data to US Law Enforcement - or otherwise implement a backdoor at the request of US Law Enforcement).
This is one of those EU rules where if it is so universal everyone should have thi right? But rather I'm not sure how widespread it is... is anyone doing it or are they all just waiting out the situation?
Shopify is sending all personal data to CloudFlare, CloudFront (Amazon) and Fastly, so 3 US companies. They could sign so-called "data processing agreements" where they promise to safeguard personal data. But the Shopify FAQ explicitly states that they are unwilling to do so.
As the result, Shopify is legally considered to not be processing data under the instructions of the shop owner, because they didn't sign the processing agreement. Instead, Shopify is legally considered to be the owner of the user data. And that's a problem with EU clients because they are a US company working with US CDNs.
Still, all of this could easily be rectified by Shopify if they would just care enough to sign the correct paperwork.
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?
Or are IPs only a problem in connection with getting user data like name and address? Or is it the IP+cookie combo?
How would it be possible to hide a host that is behind CloudFront from Germans? I don't think is it possible. Even if you run an extra host like www.yourdomain.de for Germans, they could still type www.yourdomain.com into their browser and this alone would cause tcp packets to flow from their machin to CloudFront. There is no way to avoid this.
What can German indiemakers do now? Register a company outside of the EU?
Just like US companies can run computers outside of the US border, so can other companies. A German CDN can setup their own infrastructure within US borders, then German companies can work with that CDN to speed up connections within the US for users coming from there.
> There is no way to avoid this.
There is. GeoDNS ("Regional Records") is one way, where you reply with different IPs to the instances based on where the DNS query comes from. So US visitors to domain.com gets a different IP than German visitors to domain.com.
> What can German indiemakers do now? Register a company outside of the EU?
Use European infrastructure, make sure you follow GDPR. As a fellow European (mostly) "indiemaker", it's really not that hard.
Ok, but what if you just want to run a website and not build a billion doller global CDN.
> GeoDNS
According to the GDPR you have to protect the data of your visitors no matter where they are.
We (still) don't have any court ruling here.
Of course more or less all US based cloud services are illegal in the EU currently. At least in theory. That's no news. (CLOUD Act & Co. was pointed out already by others).
But until we don't have some crystal clear rulings form the highest courts that get actually enforced this makes no difference.
The main point why this illegality does not mater in practice: Our own governments are using AWS and MS products, and all such stuff. They're completely in vendor lock-in there, and they could not change that for (at least) the next one or two decade, even if they would start right now trying to replace this stuff. But of course nobody even thinks about changing anything in this regard…
They put hopes in the next, also clearly illegal, version of the "safe harbor" regulations that's about to surface "soonish". When implemented it will take again 5 to 10 years to go through all legal instances to finally find out that a "safe harbor" agreement, no matter how you call it this time, is still fundamentally incompatible with EU law. But they will win this way another 5 to 10 years!
Than this game will start anew, and they will first ignore the law and the court ruling (like they do currently with the last one), than the EU government will try to implement the next version of "safe harbor", or something like that, to "avoid further legal uncertainty", and than it will take another 5 to 10 years to sue that into oblivion. And so forth. (We're currently already in round three of this shit show!)
The linked post would be much more interesting if this case would actually go to court.
But of course Shopify is not interested in this. They're just waiting for the next "safe harbor"; like everybody else.
Of course they won't stop doing business in the EU. Exactly like MS, AWS, Apple, Meta, and this like, won't. Because there is just nobody to actually enforce the law as more or less all EU governments are also violating it.
I'll miss that the most when manifest v3 rolls out and chrome becomes unusable.
never tried, but seems promising
If you're gonna sell a product or service, then worry about figuring stuff out.
But in practice that's never going to happen.
In both cases, the rest of the world should retaliate by limiting access to advanced technology until laws change.
I would hope that the same is possible in EU (except that, as an EU citizen, EU laws of course seem more moral than either Chinese or US ones...)
That part is ok,but the problem isn't the GDPR but the CloudAct.
The US made it impossible to use any service of an US company by demanding access to all their data no matter where it's stored.
Imagine the US government could enter any house just because the lock is manufacturered by an US company.
And the US has a proven history of using wiretap data for economic benefits. See Echolon and Airbus vs Boing
Many cloud offerings are not required if your product is physical and/or not directed at consumers. For others there are home grown alternative.
But it'll suck for a few businesses until GDPR compliment products are available.
The big one is Office 365 but, I think Microsoft is setting up licensing agreements where a European company (which is not a subsidiary of MS) is running the stack and Microsoft has no direct access.
Other large US companies are probably planing sth similar
As far as this, it's probably related to this story from one month ago (Oct 7 2022):
https://www.reuters.com/business/retail-consumer/eu-says-sho...
> "Shopify committed to change the design of its templates to include fields for company information and contact details, to provide clear guidance to traders on relevant EU consumer law and to provide company details about any EU trader when requested by any national consumer authority. The company also agreed to take down web shops in breach of EU consumer law, as well as to provide the relevant company details."
Personally I think though the onus should be on Shopify. Although only 20% of their revenue appears to be in the EU region I think that warrants managing user s private data locally.
Unless it completely upends both FISA and the CLOUD act, it won't be valid at all. And there's really no way that the US government will ever accept real, significant limitations on its data gathering reach and authority.
But it will buy companies more time and rope, because it will have to be litigated again. And then we'll go through this whole song and dance again after Schrems III.
Cloud: OVH. CDN: OVH. Email/support: HKN. ... and few other smaller ones.
You do not need AWS/GCP to be successful.
Just shop around. Solutions we picked, ended up being cheaper and friendlier (human support) than US counter parts.
More of the same will continue and the GDPR will only be used coercively as an attack against competition or companies others don't like.
It's really a major blow for small businesses that want to work in the EU. EU desperately needs more small tech business so it's quite sad.
I would love a law that said what people think GDPR says. That you have to tell people if you were selling their data to third parties and to please not do that. This is simply not what GDPR is in practice.
The road to hell is paved with good intention.
In the same way, just because normal behaviour in some countries is to misuse customer data, it doesn't mean it should be legal for an EU company to operate in that way.
Laws need to understand the environment that they are made in or will never be effective and oftentimes counter productive. As is the case here.
GDPR goes even further than would be reasonable for any small business that handles email addresses. Requiring a salaried data protection officer is not feasible. Unless you want to make small businesses illegal to operate online, you either are for selective enforcement or you do not want the GDPR.
This is bad, since most of the software does not offer to locally host the required scripts.
However can some Americans tell when your law makers will consider this to be protectionism and throw retaliatory measures against EU companies? Because I don't think they're going to repel the CLOUD Act anytime soon.
It's kind of ingenious. If you make practically every online service illegal then instead of taxing your citizens you can just fine foreign companies for doing business with you.
If they were really concerned about my privacy, they would ban creating cross-product profiles for advertizing purposes. I don't care at all that some CDN gets my IP, or that some website uses cookies to count users.
Also I don't care if somebody stores my data on Google Docs or Office365. If Google or MS go rouge and employees there so shenenigans with my data, we have bigger problems. They control the OS anyway. It makes more sense to regulate the "happy path" assuming they are law abiding, and just say you can't do targeted ads for European users.
[0]: https://www.datatilsynet.dk/english/google-analytics/use-of-...
My point is that Google Analytics (or Matomo or whatever visitor statistics you are using) is outlawed, while it is apparently completely legal for Google Ads to include dozens of "fourth-party" javascript files and everybody keeps records of what pages you visit.
It's totally backwards. Embedding content (using a basic HTML feature, sending basically only the IP address) can get you in legal trouble. But if I visit a website about say, lawnmowers, then ads for lawnmowers follow me around for weeks, because the site owners sold every mouse movement on that site for a fraction of a cent to advertizers.
The US should ban all EU produced cars from the US until the EU figures out a solution.
As for cars, the US has already forced many EU based car manufacturers to produce in the US. So, when it comes to protectionism, the US is way ahead of you.
You do realize that there is a fair share of protectionism alive and well in the US as well, right?
Probably not the most productive way to argue to start a tit for tat comparison, let's just be honest withourselves that everyone kinda does it in areas where they lag behind (digital in EU, some engineering, cars in the US).
Assuming you have some kind of PII to store, the US CLOUD Act essentially means AWS (or whatever US company) can't possibly (no matter which region you use or anything like that) GDPR-compliantly act as a third-party data processor or whatever the terminology is?
In which case... someone (as in country, legislation) is clearly going to back down? UK government sites take plenty of PII and run on AWS...
The differences in laws and requirements by country is one of the biggest factors to consider when providing international services of any sort.
The issue is with European regulations. The lawsuit was in Germany because that’s how legal systems work around here, but the sticking points are very likely to be present in national laws across the EU. So, ultimately it won’t be about the German market, but about the EU.
But of course, Shopify can just push this responsibility onto their customers, meaning the shop owners. That's what they currently do.
> The data protection authority justified this with the fact that US authorities could access personal data (probably primarily the IP address) for criminal purposes on the basis of the CLOUD Act, among other things. This occurs regardless of whether data is stored on servers in the USA or Europe.
I have to imagine the particular bureaucrats the author was dealing with are somehow wrong here? Otherwise this implies that a European business cannot use basically any American software (directly or even indirectly, like this case), even if that software fully conforms with processing and storing all data in Europe. The fact that American authorities could coerce any American company into turning data over, even if it’s stored in Europe, is enough?
This doesn't matter, EU sites have been getting fined for some time now for using CDNs like this, most popularly Google Fonts.
From what I can tell, Shopify itself uses Cloudflare, so your domain that is connected to Shopify is passing all the traffic through Cloudflare, e.g. one of the other examples in the screenshot: https://www.distortedpeople.com/
The site is on CF (and it sets like 10 cookies, including tracking cookies, pre consent, so any dreams of compliance are gone either way), and, as far as I can tell, that's the case with all Shopify shops (but I've only ever looked into that from an outsider's perspective, maybe that's optional).
Before the Schrems II judgement[0] by the European Court of Justice, companies in the US could use the EU-US Privacy Shield[1] to ensure adequate protection of EU personal data. The Privacy Shield agreement replaced and improved upon it's predecessor, the Safe Harbor agreement, which was invalidated by the Schrems 1 case.
Transfers between the EU and US can still be legal, as long as standard contractual clauses (SCC), although this requires more effort after the Schrems II case than before. Companies are now required to verify the privacy protection in the recipient country in order to use the SCCs.
The first source provided gives insight into what is required by US companies to comply with GDPR when tranferring personal data to third countries. As an anecdote, a guest lecturer for a masters course I took this semester mentioned in passing that transfers to the US are almost as bad as transferring personal data into China.
[0]: https://www.gdprsummary.com/schrems-ii/
[1]: https://www.gdprsummary.com/gdpr-definitions/privacy-shield/
As I see it, Shopify's role in this situation is more likely to be considered a data fence: because of the lack of processing agreement, they're not allowed to process any data (more accurately, the shop owner is not allowed to give them access to any data). The data that they do have through services they provide is illegally obtained; that doesn't mean they suddenly own that data.
> There are zero plans to collect anything that is not needed
Unfortunately, it's not up for you to decide. The US has laws that makes it legal for your government to harvest data, and it has used these laws against EU citizen in the past. The US has also asked US services to collect data they were not previously collecting, with a gag order to prevent customers from learning it.
Yeah, I was afraid of this.
> The US has also asked US services to collect data they were not previously collecting, with a gag order to prevent customers from learning it.
I'm so bullish on privacy that I would actually shut down my company if this happens. US courts cannot force me to remain in business.
Of course, a data protection authority will look at the circumstances, and the GDPR is 80% common sense, 15% communicating better what you do with people's data, and 5% required boilerplate that makes every privacy policy so redundant and dull and long that nobody reads it - but the point it, it does apply, as do most laws. Only when it's about monopoly positions that might disrupt the market, then exceptions are generally in place to protect newcomers that promote competition (or perhaps if you run a communications network only for friends noncommercially you might not be required to make it tap-able).
As it stands right now, it is not possible for a US owned busniess to provide a service to EU citizens legally, if the business handles PII.
The reason is partly due to the basic rights of the registrant granted by GDPR must be ensured by the data processor (the company), and due to the Schrems II ruling [1] that determines that GDPR is incompatible with US law.
The non-legalese version is that US law that gives Intelligence agencies (etc) the power demand a US owned (not just based) company to hand over any data including PII, means that the basic rights of the GDPR cannot be fullfilled. [1]: https://www.gdprsummary.com/schrems-ii/
Perhaps my best solution is to block any user creation from the EU, any login from the EU, and any signed-in user request from the EU.
Maybe I can allow non-signed-in users from the EU to browse?
The more pragmatic answer is: You can just ignore human rights. The other US companies operating in the EU also don't have issues with that.
The EU isn't going to enforce its own laws in this regard anyway as more or less all EU governments are violating this laws themself. They currently all just waiting for the next round of the "safe harbor" smoke grenade.
On the other side, the EU companies that use US cloud services (so more or less all EU companies) do by the way exactly the same. Nobody cares.
Do not store any kind of PII as defined by the GDPR, ever, anywhere.
If you do, the PII data you store about your companies must be in respect of the GDPR and in particular access to it by law enforcement has to go through EU court.
Because the US has decided with the CLOUD Act that US access to all data from US companies, or any company owned by a US company, only had to go through US court, it is not possible to comply at the moment.
(before the CLOUD Act, storing the PII data within the EU and owned by a EU subsidiary was the best solution)
One could retain a US subsidiary, which might handle US or even all non-EU data.
Unfortunately it is not clear if an American individual could own or control the EU parent company. It depends on if the owner could be considered "A provider of electronic communication service or remote computing service", because if so, they could subpena you personally, on basis that you control the EU company and thus the information is within your control.
The relevant part of the law is:
> A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.
Like making it clear in the DPA/PP?
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”.
If the business is based in the US, things get a bit more complicated due to the CLOUD Act[2].
[0]: https://ec.europa.eu/info/law/law-topic/data-protection/refo...
[1]: https://ec.europa.eu/info/law/law-topic/data-protection/refo...
[2]: https://complior.se/cloud-act-and-how-the-new-american-law-c...
https://gdpr.eu/recital-18-not-applicable-to-personal-or-hou...
In theory, IP address is considered personal data only under certain conditions. In practice, those "certain conditions" almost universally apply and you should treat IP addresses as always being personal data.
IPs are sometimes PII. It seems that if you're the ISP, the IP is PII, but if you're a website, the IP alone may NOT be PII.
The case specifically was that in the local jurisdiction, there's a law that if a company gets DDOSed they can request the local regulator to ask the ISP to identify a user. This law only gets triggered in very exceptional circumstances, but its existence means that IP addresses are always personal data in that jurisdiction. While that law only covers one part of Germany, the analysis applies to any similar law, of which it is safe to assume there are many.
GDPR just has incredibly sparse, scattershot enforcement because of how disruptive complying with it would be to EU Internet users.
re: language
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
re: from today
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
GDPR is ugly. The only thing it allows you to do before you get confirmation to process PII is to show static page requesting for permissions. That's basically it. You can't do any "cloudy" stuff prior.
Keeping those IP logs for security reasons is also legal (assuming you keep them safe for an applicable amount of time)
Using that data for analysis is not legal.
If you build a mobile app, you are also supposed to only ask for permissions once you actually need them.
Replace interactive embeds with a dumb replacement of the actual content and e.g., "we want to show you an embedded tweet here, [allow once] [allow always]".
Don't use CDNs for delivering assets, they've long stopped being useful anyway.
Don't use Google Analytics.
In general, build websites like we used to in the early 2000s.
And yes, you can even do cloud-y stuff like that. You can run k8s on your hetzner dedicated servers, you can run MinIO as your s3 store, none of that is stopped at all by these rules.
You can even run an interactive website like HN without any GDPR violation or cookie prompts at all.
China also does this to ensure home grown tech eco system while at least being more truthful about.
No, GDPR is not ugly. Yes, you can do "cloudy stuff".
The bullshit narratives around GDPR need to stop, however people driving the narrative are extremely incentivized to siphon and sell all the data they can get your data, so the narrative is always bullshit.
CJEU ruled back in 2016 that IP address is personal data if provider has legal means to identify the person. This includes, as example that was given in the case, laws that give means for service provider to identify the users in the case of cyber attack by requesting help from other authorities.
This ruling is from before GDPR and relates to the older Data Protection Directive, but the relevant chapters are largely same (GDPR mostly increased the explicit scope).
Ruling: https://curia.europa.eu/juris/document/document.jsf?docid=18...
The "tl;dr" parts are 30 (the question) & 47-49.
The old directive: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
https://isgoogleanalyticsillegal.com/
https://plausible.io/blog/google-analytics-illegal
Law is a code that needs to be interpreted by society. This interpretation is done by judge rulings. There is a growing number of rulings that Google Analytics, and in fact any sending of customer PII to US-owned legal entities, is illegal.
Naturally, smaller companies won't be sued, right now. But the more time passes, the clearer it becomes that given the current GDPR and US laws, it's illegal.
The problem is that enforcement is rare and small scale compared to the overall scope of the problem. In both of these cases it's a day late and orders of magnitude short.
The Schrems II stuff is a situation where many of the politicians and the businesses really don't want to have to do anything and so they just kinda ignore the law until privacy advocates force their hand. So enforcement is effectively non-existent; the hope being that they can just run out the clock until some sort of legislation magically fixes the issue.
I don't know how that affects lawsuits though. I'm guessing if you have any customers in Germany, then someone could take you to court in Germany, but I'm not sure...
Right. EU companies whose websites are accessed by individual citizens and usually have assets stored by US companies, such as CDNs.
In addition, the physical location of the servers do not change anything when the company operating those servers is American. They still need to comply with the CLOUD Act, even to the point of pulling data and encryption keys from servers based in the EU.
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...
I believe that's what Lavabit did when they were served that kind of order. Not sure that helps with EU legality, though.
I guess if you fear Quantum inserts it might have some privacy/security gains.
Can't any more edit the original message, so here is the right link: https://addons.mozilla.org/fr/firefox/addon/firefox-translat...
All that's needed is that the USA start to recognize the rights of non US people. That's all.
Nobody likes the current situation. Really.
But it's not OK that governments collect data without proper court warrants, warrants which could be legally challenged. (And no, it's not only the US. We have here in the EU the exact same battle against our local authorities. Now that we've got some additional rights in form of the GDPR this rights need to get enforced finally. In all kinds of directions).
I have done that. Through all levels of government. But the establishment is going to do what it's going to do, regardless of party.
The obligation laid down in paragraph 1 of this Article shall not apply to:
* processing which is occasional, does not include, on a large scale, processing of special categories of data as referred to in Article 9(1) or processing of personal data relating to criminal convictions and offences referred to in Article 10, and is unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope and purposes of the processing; or
* a public authority or body.
You need to protect it under EU court / jurisdiction, and the US broke that and said they have jurisdiction over any piece of data your company ever touches.
That's why the US now wants some sort of privacy shield 2.
As an actual solution you can use: find another company, an EU company, one that you don't own, to handle your PII data for you, so you never store that data yourself.
Also, be sure to read in the GDPR exactly what is and isn't PII under it, a lot of companies can work just fine without much or any PII, and a lot of people think "any" data is PII.
So we basically need to migrate to a EU based could provider ASAP?
Would this privacy shield 2 fix this problem? I suppose we can’t just wait for that.
Sadly no because you still own the data, which is the criteria the US has decided on.
> Would this privacy shield 2 fix this problem?
No idea since at this point it's merely a name for a vague demand being asked by the US.
I'm sorry for the trouble this whole situation causes to your company, though to be honest as you can imagine I am very glad that my representative in the EU didn't back down and protect my rights.
(this is also the argument around cookie consent: yes, the browser chooses to accept the cookie. users don't really get an opportunity to refuse them, though. So "the browser accepted the cookies" is not sufficient consent, as far as the EU is concerned)
For users with accounts the standard ToS can handle it.
It makes sense to not store if you're running some kind of privacy service.
Or, you can just do it anyways. Its not like GDPR and Schrems II have stopped Microsoft, Amazon, Google, etc etc.
Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems)
So when you misbehave, I have the means to block you in particular.
It might be meaningful under the model of direct HTTP, where you could be DoSing me or trying to exploit my web server. But if you don't contact me over HTTP, then that problem doesn't arise. There's no meaningful concept of blocking people from a Usenet post I write. Even for indirect HTTP, I don't need to block people from my GitHub Pages or from my HN comments. They're public.
If I add dynamic feature like a comment system or discussion forum to my website, then it becomes meaningful, but also at that point I can implement a way for you to consent to sharing your IP address with me as part of signing up.
What’s what with the internet is that it allows both types of models, and both are widespread and actively used today. It wouldn’t be hard for e.g. GH to run EU servers and manage mirroring all content and static sites so that traffic is roughly region local. I wouldn't be surprised if they did this to some extent just for efficiency concerns irrespective of any legal ones.
You also seem to be conflating TCP and HTTP.
It is illegal to have source ip address in EU based smtp relay?
The history of the situation is like this:
- Privacy shield exists
- EU users data are stored and owned by Microsoft Ireland
- US goes against Microsoft with a warrant to acquire data stored by Microsoft Ireland
- Microsoft US refuses, stating it's not Microsoft US data nor US citizens data but data from an entirely different company that's in Ireland, even though Microsoft US owns it, so US needs to go against Microsoft Ireland
- Case goes all the way to the supreme court ( United States v. Microsoft Corp., 584 U.S. ___, 138 S. Ct. 1186 (2018) [1] )
- The US government really wants the access, but a lot of noise is being made from EU customers and government about it being in violation of the privacy shield, and that Microsoft losing this case would mean no more privacy shield since it would mean said shield isn't working, so US business are making noises too
- After the hearing, but before the Supreme Court gives its answer, the CLOUD Act is passed almost hidden as part of budget bill, which says US can go against a US company to request data from foreign companies they own and they have to comply as if it was their data
- The Supreme Court dismiss the case, the US government dismiss the original warrant, press releases are made saying they're not asking the data anymore and the SC dismissed the case so the privacy shield is working, and then the US government issue the exact same warrant but now under the CLOUD Act, which this time Microsoft US doesn't contest since the CLOUD Act says they have to provide the data from Microsoft Ireland
- Microsoft Ireland data is provided to Microsoft US, which provide it to the US government, bypassing EU courts
- EU is not fooled at all and ends the privacy shield -- EDIT see comments: after a court case forced them to admit it
- The CLOUD Act allows provisions to negotiate on a country to country basis, probably so they can negotiate with each country behind doors until they each get their own "ok I cave" moment to avoid being excluded from US tech service.
- GDPR enters the scene, making those privacy provision front and center and pushing them all the way to the EU. The whole negotiate with each country on its own goes away, you need a deal with the entire EU where each country doesn't risk being isolated if they say no, a EU country cannot say yes on its own as that would violate EU law.
- Side note: the UK after leaving the EU has now already made such an agreement, meaning UK data handled by US companies are no longer protected by UK courts no matter where they're stored (sovereignty much ?)
- US wants a privacy shield 2 with the EU, which I don't see how it can happen as long as the CLOUD Act exists unless EU companies are excluded from it, but the whole reason for the CLOUD Act to exists are EU companies, they could literally have named it "Bypass EU Law Act", because other jurisdiction don't care that much about their users data for some reason
The issue the US has is that all the US tech companies providing tech services could become persona non grata from the EU market court case after court case like this one, since the US has decided neither storing the data in the EU nor setting up as a completely separate sub company puts the data out of its reach.
Please note that the US never even tried to request Microsoft Ireland the data under the EU courts, like eg France did when asking Swiss court for swiss data from Proton Mail, their issue is really about them having all access on their own without having to ask anyone else, which is precisely what the EU refuses. The EU is fine with the US asking EU court for EU companies / users data and the court deciding on a case by case.
[1] https://en.wikipedia.org/wiki/Microsoft_Corp._v._United_Stat...
This is not entirely correct, the EU kept on pretending for a while that the problem didn't exist, until Max Schrems (from noyb.eu) forced a court ruling on the inadequacies of the Privacy Shield agreement. As shown on their homepage, NOYB does a lot more than just investigate EU-US data transfers.
To store email, Microsoft US made use of the services of several network storage providers around the world so that they could store email for a given user someplace that had low latency for that user.
Microsoft Ireland was one of those storage providers. Microsoft Ireland was not directly involved with the email user or even aware that they had any data on that user.
To Microsoft Ireland, Microsoft US was just another customer using Microsoft Ireland's storage service.
In particular, Microsoft US had full access to the data anytime they wanted, using the normal APIs that storage customers used.
Both in your national election which then decided the government which chose your country EU representative for the council and commission, which then created the law and decided to put it to a vote and where your government had a direct veto right, and in the European election where you elected the parliament that voted on the GDPR.
I recommend you inform yourself on the institution that govern you and how you can influence them, you seem to be deeply uneducated about them.
No candidate had on her proposal list "hunt and close cookie consent dialogs on the web forever".
I recommend you go out on the street and find out how real governing in the EU works, you seem to be deeply idealistic about it. It’s important, it could be why the next brexit happens.
without data, it’s hard to make this argument. what we know for sure is that bureaucrats fully support the privacy angle. but from my anecdotal real life experience almost no one cares (another argument that without data cannot be generalised).
There is a huge EU project which in theory is trying to build those competitors - Gaia-X - but as is typical with such projects the results have been poor. Looks to me like a lot of the money was wasted on "blockchain" scam projects.
The thing is - there is real significant potential in the EU for some of the existing large colocation/VPS provides to become just that only the EU's own implementation has failed.
For instance the baby sitter you hire now and then probably keeps track of the contacts of their potential clients, and you could request deletion of your data if you don’t intend to work with them for a few years.
> 2. This Regulation does not apply to the processing of personal data:
> (c) by a natural person in the course of a purely personal or household activity
My sense (I am neither a lawyer nor European so this is certainly not European legal advice) is that you cannot use GDPR to compel someone to delete your contact info if they're solely a social acquaintance, but you can use it to compel them to delete it if they're a one-person business of some sort (contractor, Etsy seller, lawyer, etc.).
The person you traded phone at the bar last week, your neighbor or your coworker from last job are not.
Hard on Android, where "did my wifi go away" means asking "can I have access to your phone's internal state including call logs and if you're in a call right now?"
> replace interactive embeds with a dumb replacement
Sucks when you depend on that content or the content has to be interactive under the TOS of the service you're using.
> [CDNs have] stopped being useful
Not at all. In many a corporate network as well as situations where you're paying for transit (e.g. AWS) they still make sense.
> build websites like we used to in the early 2000s
Ah yes with Flash for our interactivity, __Just throw an executable format that has a hard to render, proprietary ISA running unsupervised__, that worked for us then it should work fine today?
I'd say "Let's build more websites like we did in 2010". That's right around when Javascript peaked.
> Minio
due to their licensing change, a lot of legal departments have banned minio.
Google is clearly a company that is in dire straits in the EU, both from its business model that relies so much on tracking people across the Internet, and from its ties to the US intelligence agencies.
As for the apps available on Google Play...
https://9to5google.com/2018/12/31/android-apps-facebook/
https://www.cnet.com/tech/mobile/some-popular-android-apps-a...
How do you handle large DDOS? Your provider won't, they'll nullroute your IP because they don't want to waste their bandwidth on your issues and impact all their other customers.
Also, using a global CDN with edge caching speeds up loading your site significantly if the user isn't close to the DC.
Regarding Hetzner: what's the verdict on them having to comply with the CLOUD Act via their US subsidiary?
Regarding edge caching speed: we're in an age where your phone executing the shitty bloated JS is the bottleneck, not actual latency.
That also avoids pretty much all of the popups.
Sure, no CDNs and no analytics, but that's what I'd call an absolute win. Nothing of value was lost.
There are lawyers that threaten to sue you in court, treating this as a business model bordering on extortion, but that’s not the case here.
So no, don't expect your personal website from being exempt.
https://www.cnil.fr/sites/default/files/atoms/files/decision...
The law doesn't care what format that this information is stored in.
In fact I think we do use the term "self-host" in exactly that way when talking about "self-hosted newsletters." I can (and do!) run a newsletter where I generate the HTML and the MIME document locally, find an SMTP provider of my choice, and instruct it to directly mail recipients. I maintain the mailing list (in a text file in a Git repo) and pass it to my SMTP provider every time I do a mailing, and people contact me directly to sign up. I could also use Substack/Tinyletter/Buttondown/etc., which would have various advantages and disadvantages; the hosting provider would handle most of this for me, including maintaining the list of subscribers. You can also talk about "self-hosted Mailman," etc. In these cases, the self-hoster sees the email addresses of subscribers but not (necessarily) their IP addresses.
I don't think I'm conflating TCP and HTTP. NNTP, UUCP, and SMTP all use TCP, but they're designed in a way that doesn't have this property. In fact it's not even HTTP per se that's a problem. It's mostly about what I called "direct HTTP" - though you posted your comment to me over HTTP, there's no HTTP (nor TCP) connection to me.
(Also other comments claim that the CLOUD Act means that if GH the US entity runs EU servers, that doesn't actually solve the problem - it'd have to be a non-US entity not subject to US jurisdiction. That's why I think the old-school-web model of mirrors is a better example; they're generally run by universities or other entities with no legal relation to the site they're mirroring.)
But that doesn't matter to you. As long as you're too small to have a server and a (part-time) "controller" inside the EU, you seem to be out of luck (note: IANAL; there might be another way; cooperation with another small company, perhaps?).
Requiring a salaried health and safety officer is not feasible. Except it is. It doesn't need to be a dedicated officer, it needs to be someone (Company Secretary, the owner, whatever) who is accountable for it.
Child labor. Drugs and radioactive substances in medicine. Water pollution. The list of practices that used to be common is extremely long.
And yet here we are.
> GDPR goes even further that would be reasonable for any small business that handles email addresses.
Of course it doesn't go "even further". Don't sell user data left and right, and boom! Your poor small business is in the clear.
> Requiring a salaried data protection officer is not feasible.
The law doesn't require a separate salaried DPO.
> Unless you want to make small businesses illegal to operate online, you either are for selective enforcement or you do not want the GDPR.
The one thing I want is for people to stop saying fantastical bullshit about GDPR that has no basis in reality.
It’s possible that I just misunderstand the landscape, I suppose. For my particular case though I work at a small business in the US that uses AWS cloud services for deployment of our application. One of the dependencies of our tech stack is an industry standard application (it’s ubiquitous in our space and has no accepted alternative in our industry) whose per-instance licenses cost are nearly half my yearly salary. After factoring in a second instance for HA, it’s a full engineer‘s pay. In order to make sure that we have a cloud offering that can be used without any data leaving the EU or talking to a US company, our overhead increases to the point that we’re running with one less engineer than if we could all use the same stack.
We do not collect any PII for longer than is needed to fulfill requests and we have no other revenue stream (no ads or connection to ads) other than customer subscriptions.
So, for my team, the impact of compliance has been painful.
If it turns out that I misunderstand some aspect of compliance here, I’m happy as that is good news for me.
There is a vested interest amongst people that profit from users data to attack the GDPR and similar laws and spread FUD whenever possible.
It could be helpful to switch "user data" with "child labour" and see if your perspective changes.
The problem you likely have is while you don't exploit child labour, you are responsible for ensuring your supply chain doesn't either, and your supply chain may use the profits from that child labour to subsidise their product to you. A competitor which doesn't use child labour charges more, so you think "the cost of compliance is high", rather than "my profits are being subsidised by child labour"
And the article shows that this is not true.
The article shows the use of third-party solutions none of which are GDPR compliant: not the cookie banners, not the data storage, not CDNs. And every step of the way the authorities explained all the issues and waited for solutions (quote, google translate, "There was neither a court judgment nor a fine actually imposed.")
As a business you are responsible for user data. You can't use some third-party business, point at them and say "it's them who are responsible, not me". The responsibility of properly handling user data is yours.
GDPR was adopted in 2016, 6 years ago. You'd think this was enough time to learn it by heart by now, or at least not make mistakes about the simple core things of the law. It's not as big, or as hard, or as ambiguous as people who have never even read it make it out to be.
Ah, from the perspective of website owners, not the CDN owner... Well, use a European CDN, they tend to follow European regulation, just like US companies follow US regulation. The two companies that comes first to mind is BunnyCDN and KeyCDN, but I'm sure there are many others. Both of them have global networks.
> According to the GDPR you have to protect the data of your visitors no matter where they are.
Yes, of course, that's the ground truth we're assuming here. Is that some sort of gotcha? I'm not sure I'm understanding if you're arguing against what I said or just adding information on top without disagreeing.
The recent rulings say that no packets are allowed to travel to the US because that would enable the US government to access them if it wants to. I don't see how this can be avoided. As soon as a tcp packet enters the US, it is on infrastructure the US government can access if it wants to.
Edit: in order to make this discussion a bit more fact based, as some misinformation is starting to leak into it: I'm referring to Article 3 from GDPR, "Territorial scope". It states:
> This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union
Merry Christmas to those two.
> Even if you run an extra host like www.yourdomain.de for Germans, they could still type www.yourdomain.com into their browser and this alone would cause tcp packets to flow from their machin to CloudFront. There is no way to avoid this.
If you're adamant on running US infrastructure for US users and EU infrastructure for EU users, you can do that by using GeoDNS/Regional Records.
But personally I find it easier to treat everyone as a EU user, and I store no personally identifiable information what so ever except information given by users themselves (like emails for registration), so maximum privacy for my users.
Same goes for credit card numbers, as an aside, I saw a credit card number being hashed in an app I was consulting on once... don't do that. Rainbow tables are stupid simple on inputs that small.
Everyone who's mindful of site visitor's privacy.
> How are you supposed to handle abuse or performance issues a visitor might have?
How does a static website handle those issues?
... you've developed a warped default of what a website is.
> Or perform analytics?
You can base your analytics on voluntarily provided information from users. Or just, like, _not_ do them.
There is such a thing as "legitimate interests" in the GDPR. Storing certain IPs specifically as a measure against spammers and botnets should be fine, as long as that's really all you do with the data.
> Or perform analytics?
This is the heart of why the GDPR exists. You are not allowed to collect and analyse personal data about your users without a legitimate reason or their consent (a legitimate reason is not "it pays our bills"). Either ask the user for permission or only store aggregated data.
Most companies just store a ton of data about users without having any clue what to with it, "just in case". If you collect data for specific purposes, you don't need it to necessarily include any personal info ("how many users clicked the red button instead of the blue one" doesn't require any PII, for example).
But regardless: one has to admit that it is not different from how the current embargos affect Russian people. Punish the citizens so they (try to) put pressure on the government to act better.
https://news.ycombinator.com/item?id=10458318
So, what is a reasonable way to deal with this if you're running a government agency or a company that has something worth spying on / getting remote control of for the USA ?
The "undesirable side-effects" are being sold as undesirable first and foremost by US companies (and US government!) who assume that everything and everyone belongs to them.
Does it suck to be stuck between a rock (GDPR) and a hard place (the US' continuing desire to not care about user privacy)? Yes. What amazes me though is that the only side that gets blamed is GDPR.
1) if your data is processed for contractual purposes, the data processor has a right not to delete it on request
2) if your data is processed for law enforcement purposes, the data processor has a duty not to delete it on request
There are several legal grounds for processing personal data under GDPR, and consent is only one of them. I think most of the others outweigh any request for deletion by the data subject.
E.g. if some law requires a company to retain certain data for longer periods than stated in GDPR, that law still applies.
(we would NOT be in this situation if Patriot Act => Snowden scandal had not happened)
https://www.lawfareblog.com/how-europes-intelligence-service...
Still, I think you can see how a lot of people might feel more comfortable being spied upon by "their own" intelligence agencies, than foreign ones ? (Since, in democratic countries, these agencies are at least theoretically under the control of governments, which are in theory representative of citizens.)
And while the USA (unlike, say, Russia or China), is treated as an EU ally, their unrivaled power combined with their "world police" actions end up chafing even in the EU...
With the CLOUD Act, I'm wondering if it is illegal.
> Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems)
It's a code forge.
For users with accounts, I have to store at least email addresses, which I believe are PII. I also need to store public keys (for commit signing), which could be considered "identification numbers" covered by the GDPR.
Even if I got away with not using email addresses, I can't get away with not storing public keys, unfortunately.
I believe that once I store any PII, it's game over, right?
By the way, I'm all for strong consumer privacy protection too. I would want the US to implement something like the GDPR as well. So I'm a supporter on some level. I'm just mad at the US government for the CLOUD Act.
Yes emails are PII. In general anything that can identify a person. Its a broad interpretation of "identify a person", and actually hasn't got anything to do with the sensitivity of the information. There are classes of PII for sensitive data, and extra rules for processing that, but when figuring out _if_ data is PII, sensitivity doesn't really come into it.
And you are correct, _any_ PII is "game over" in this case. But this case (US <-> EU) is also a bit of an edge case to GDPR I think. I mean most of GDPR is concerned with how a company should handle PII. Then there are some rules about transferring data to "unsafe" countries. Unsafe in this case means countries where there is high risk that the company is not handling PII correctly and/or nothing the EU (citizen) can do about it. And this is where your CLOUD Act + Schrems II comes in. It makes US an "unsafe" country to transfer data to because it brings a high risk for the EU citizen that their GDPR rights cannot/will not be enforced (and the Privacy Shield agreenment that used to make it okay away is no longer valid).
Its unfortunate, I think, because it puts GDPR in a special negative light for US engineers, and that takes away from the many good things in GDPR. I actually think most of the stuff in there is pretty good. And just for reference - I run my own company, so I'm "enjoying" GDPR compliance fully, and sure, its more work, but I haven't yet encountered a part of GDPR where I havn't though "isn't this actually how I wanted my data to be handled by other companies?"
Okay, now for the fun part - thinking up designs/architectures where your product would be GDPR compliant. Im just doing this for my own fun btw, and perhaps a nice discussion. Not trying to tell you what to do :)
Since we have the hole "unsafe" third country situation, no transfer of PII is okay. This is a bit more restricted that what we would normally deal with under GDPR.
The basic tenants for being compliant here is two things: 1) If you/your employees hasn't got access to the data, e.g. because you don't have it, you are not handling PII. 2) If data is not being sent from the client (located in EU) to your US servers, you don't have the "unsafe" country data transfer situation. And the your are compliant.
Emails (and other data attributes, like username, name, CC details, shoe size etc). I think the way to go about this is thinking in terms of that you actually need server side to make core functionality work, and what could actually be kept client side and never sent to your servers. See, in this case the problem is transferring the PII to the US. If you can somehow have a "fat" application client side, like a SPA, could you avoid sending the email to the server? What you must have is a unique identifier for users, sure, and email is normally that. But you could hash the email addr and use that as a unique key for the user. You just need it to be guaranteed unique, and dont care (most likely) what the actual mail address is. Note: Stil have to be careful with the hashed email as unique key because that could still identify a user, since its unique, and therefore PII. However if you hash client side and only send the hash, you will only have the hash server side. And if the only datapoint you have is a hash then it cannot identify a person on its own (given the properties of a one-way hash function). You'd need to put that hash in context with other info to be able to identify a person from it. And then its not PII, and you can send it to your server no problem.
The same concept should be usable for most basic data attributes, i.e. shift everything PII to the client, and if data needs to be sent then do you actually the actual value of the data or do you just need the data to have a certain property, e.g. be unique or be not-null or whatever.
Then there is the matter of storing all this data we've now shifted to the client. This is were the textbook would say "left as exercise for the reader" LOL. Storage for web apps especially is gonna be annoying to deal with. If you have an actual (not web app) client, its much easier. If your users are developers, you can get away with less user-friendly ways of managing that data client side in a web app. It seems solvable without too much fuss, with some form of local storage.
Public keys. This one is though. A public key is PII. You need the public key server side because (I'm guessing) when a user submits code (s)he attaches a signature, that you need to verify. You having that public key is part of the hole PKI idea. The first idea that comes to mind is based on the same "do you need the value of the data or do you need to know a property about the data"-thinking. You need to know the signature is valid for the submitted code. If you had a magic black box that could give you a yes/no (that you could trust) on that, you wouldn't actually need the public key, you could just give the code and the signature to your black box and it would say yay or nay.
If there was a service (i.e. API) on a server in europe that played the part of the black box, and you trusted it, you could "just" call the service with the signature (again hashed/encrypted and if you don't have the key, you can't relate the signature to a person, so its not PII) and code as input, and the service would return true/false, when you would have what you need. And no PII i.e. the public key would need to be transferred to your server / you wound't need to handle (store) it. Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup?
I feel like there must be more solutions to the public key one, but they don't come to mind right now. Was a fun exercise anyway :) I'm sure I've made so many assumptions about how your product works, that the above suggestions would never work in practise, but my point was more to illustrate that GDPR compliance can be dealt with by rethinking many of our go-to design patterns (i.e. have a central database with user info).
Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced.
I think your ideas are wonderful, and I might try to implement as many of them as possible, just for privacy reasons, even if it is impossible for me to target the EU market.
In fact, because it's a code forge, there will be a client, just like Git is a "client" for GitHub. (It will be a self-contained VCS like Fossil.) So most of what you said will work.
In fact, you are exactly correct that I need the public key for signatures on code.
But there is one hang-up. While I could let the client handle checking for code signing, I still need to store the public key.
The reason for this is because the public key will also be for account recovery. Recovery via email will also be possible, unless I can't store the email address at all. But either email or public key will be required to recover accounts.
So unless I could make it so random clients could recover accounts for other users, I need to store the public key.
If you have ideas about how to get around that, please contact me. [1] Even if not, I would love to continue talking with you about this; I want to set the standard for protecting user privacy with my code forge.
> Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup?
Yeah, I thought so. The biggest problem with that is that I have absolutely NO contacts in Europe that I can use. I may not even be able to travel to Europe to set something like that up. So because I only care about money enough to make what I need to in order to support my wife and me, offering my product to the EU is not worth it for the hassle and cost.
> Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced.
This is encouraging, though sad since I won't be able to make it work.
To be honest, I was hoping I could make an end-to-end encrypted code forge, but I also want to support FOSS projects, which have to do their stuff in public. End-to-end encryption would only work in that case if everyone had the client on their machine, which would not be likely for a VCS; there will be people that just want to download the code from the browser without needing an extra program to do so.
Again, I'd love to chat even more. Please contact me if you feel like doing so.
Part of the GDPR does good things against bad actors like ad/tracking companies. But most of these companies are so big that it just works as a moat to keep out small competitors in that space.
The more widely-affecting thing that the GDPR is doing is to make it impossible to legitimately run a business like the one that the article is talking about. An online shop that uses shopify which uses a CDN. A small online shop using a CDN is who is actually hurt with GDPR.
I'm the asker of the question that started this discussion. I'm a US citizen.
I'm actually on the side of the EU here. There needs to be privacy protections for consumers. Even though the requirement for a rep in the EU is impossible for me to fulfill, I admire the fact that they prioritized native EU companies over foreign ones because that is what's best for the EU inside the EU.
I'm mad at the US government for the CLOUD Act, which is egregarious and doesn't serve the interests of the US; it only serves the interests of the US government.
Do you know if that that makes any difference?
As a EU resident myself I completely understand, it just is a bit tough to make the changes as a small company, but if it’s legally required we’ll make them ASAP.
To ensure you don't have problem down the line, make sure they themselves store their data in the EU (for exemple, french OVH allows you to chose where you data is stored, their french datacenters are fine, but I would not go with their canadian datacenters).
Allow me to remind you that it's not just the hosting but anything that touches that data, eg analytics and error reporting services are concerned too
I was just thinking about the other services, for example would Cloudflare be ok? We proxy all our traffic through them, and they are key for DDOS prevention, I suppose data goes encrypted to them.
Anyway sadly no Cloudflare isn't ok, it's specifically one of the three provider that got Shopify convicted in the parent article (other two being Cloudfront and Fastly).
Google is among the biggest and Google Analytics is getting absolutely shredded in the EU. How's that moat coming along?
I was expecting you to show where I'm incorrect.
And yet, it's the same emotionally-charged "omg moat, large companies, impossible to run a business".
Which doesn't disprove what I say, but further supports my case: the bullshit narrative around GDPR persists even if it has literally no basis in reality.
> A small online shop using a CDN is who is actually hurt with GDPR.
Most CDNs have GDPR-compliant services in the EU. Those listed in the article literally have separate pages specifically addressing compliance with GDPR.
There are banks in the EU handling sensitive customer data which use the very same CDNs and services under significantly stricter laws than GDPR.
But sure. Tell me how it's impossible to legitimately run a small business that operates under significantly fewer obligations, and retains significantly less customer data.
I won't continue this as it seems like it's more a flame war where no side can convince the other.
I'll say this, though: please imagine who I am who feels so passionately about this. Likely, I am a small business that has been affected personally by the GDPR though I am not in advertising or tracking. Maybe I'm just a small business owner trying to navigate the uncertain waters created by these rules. That's what brings out the passion.
I imagine you are someone who is passionate about privacy and against adtech. As am I. We're probably ideologically similar. So please try to square why someone who is ideologically similar has such a strange idea. It might be that I am misinformed but it might be that you don't have the same experience as me.
You make a strawman here, as that was not what was claimed is impossible. Tell us how it is possible to use Shopify to run a small shop in Germany.
How can a US company have a GDPR compliant service in the EU? The US government can force them to give up any data they own, which isn't compliant.
As laws go, it's fine.
See this comment on who is responsible for user data and how it's relevant when chosing third parties for your business https://news.ycombinator.com/item?id=33566437
They are not, where are you getting this from?
Again, Article 3 from GDPR, "Territorial scope";
> This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union
data subjects who are in the Union
Hey, I was a small business owner and the GDPR was a complete non-issue. The website was hosted by a small service provider in my country. No CDN required (static files, not that much traffic).
If you're a small business owner you're either not affected by GDPR, or you're doing something shady.
Shops with actual traffic might need a CDN.
> If you're a small business owner you're either not affected by GDPR, or you're doing something shady.
Well, apparently I can't use Shopify despite having no interest in tracking, ads or any kind of analytics.
It's possible. Because every GDPR discussion is this: emotionally charged "gdpr is the devil" sold to gullible devs by advertisement industry vs. attempt to disprove at least the obvious lies.
> please imagine who I am who feels so passionately about this.
The less we imagine and the more we deal with facts, the better we, and the world we build, will be.
So let's reiterate facts vs imagination in my original reply:
- "GDPR is ugly."
It's an emotionally charged subjective statement. However, GDPR is no uglyt. As far as laws surrounding complex topics go, it's absolutely definitely emphatically not ugly.
- "The only thing it allows you to do before you get confirmation to process PII is to show static page requesting for permissions. That's basically it. You can't do any "cloudy" stuff prior."
This is 100% unadulterated lie.
The problem though, people keep mixing emotionally charged statements with lies and half-truths, and you get "GDPR is the devil" in the majority of HN comments.
"Human activity is a complex thing and no law can describe it with 100% accuracy, news at 11".
I doubt anyone arguing against GDPR read it. Or read recitals. Or read even high-level descriptions of the law, say, at gdpr.eu. Or read any laws in general, to compare.
Thought experiment: why didn’t any major ad tech company announce any harmful affects of the 99 section GDPR. But they did announce billions in revenues shortfall (ie Meta) when Apple made tracking opt in by one three line dialog box?
This bullshit again. It wasn't the GDPT that made the web worse. This is is entirely on the companies who took a look at GDPR and said: no, we're going to ignore it, continue siphoning user data, and trick users into "consent" through dark patterns (actually illegal under GDPR).
> Thought experiment: why didn’t any major ad tech company announce any harmful affects of the 99 section GDPR. But they did announce billions in revenues shortfall (ie Meta) when Apple made tracking opt in by one three line dialog box?
Funny how you don't conduct a thought experiment on why cookie pop-ups exist and what GDPR has to say about this.
The fact is that the cookie pop ups would never be necessary if the GDPR hadn’t been passed.
Because that's the truth
> The fact is that the cookie pop ups would never be necessary if the GDPR hadn’t been passed.
Show me exactly where GDPR mandates the use of cookie pop ups.
(Hint: GDPR mandates: "ask the user for consent if you collect more data than is strictly necessary, and the opt-out must be as simple as opt-in". Guess who decided they should continue siphoning all possible user data and trick users into giving this data with dark patterns)
(Another hint: AppStore rule on tracking was more effective precisely because Apple has the possibility to enforce it immediately. And still the greedy leeches like Facebook complained about the rule, not about their own practices)
So the EU isn’t inept because they made a bad law. They are inept because they have no clue how to enforce it?
> GDPR mandates: "ask the user for consent if you collect more data than is strictly necessary, and the opt-out must be as simple as opt-in".
So the websites are asking the user - as the law dictates even if the buttons are the same size.
> AppStore rule on tracking was more effective precisely because Apple has the possibility to enforce it immediately.
So you’re cheering the government making a law that made the user experience worse that the government couldn’t enforce?
The law isn't bad. The EU knows how to enforce it.
> So the websites are asking the user - as the law dictates even if the buttons are the same size.
No.
1. The sites are willingly breaking the law in the absiolute vast majority of the cases
2. The sites don't even have to ask any of this if they simply stopped siphoning user data
> So you’re cheering the government making a law that made the user experience worse that the government couldn’t enforce?
It wasn't the law that made the experience worse. Does the law require the sites to siphon and sell your data to the highest bidder? No. The law says: if you do that, you have to tell the users about that, and obtain their consent before doing that. It's the industry of greedy leeches which made the experience worse. And you've bought into this industry's reasoning that it's the law that makes them do this.