The second a better product comes along I'm moving away from Jetbrains. Unfortunately I think we're about to get into an IDE winter since everything thinks all problems should just be solved by AI rather than doing the hard work like "good refactoring tools" and "acceptable user experience".
Even without AI winter, I don't know how you can catch up to intellij. Vscode is a hodge podge of dubious quality plugins by randos. I'm sure you can build yourself a nice IDE by being very selective, but part of what I'm paying for is the curation and cohesiveness, and I think you need a big player that is invested in building something for a large variety of use cases. I think Microsoft has their own set of tooling that works for them at their company and so does Apple and I'm not sure Google really wants to make a public IDE. Any small scale startup will take many years to catch up.
Microsoft uses a mixture of Visual Studio (classic) and VSCode internally. The AI assistant is Copilot. The exact same stuff that the users use, albeit slightly buggier. To get the True Microsoft Experience, take VSCode, install the Git, GitHub, Azure, Typescript, and Copilot plugins, and disable third-party repos. A cohesive IDE!
> what I'm paying for is the curation and cohesiveness
Seriously. This is where Jetbrains went astray. Their original programmers I think were pretty high quality, but their product people are clearly so pants-on-head clueless that they wouldn't know a golden goose if it crushed them under metric tons of golden eggs. Good things don't power-law scale and "let's make 1000 forked IDEs and 50 really weird infrastructure servers" isn't a winning strategy. It's how you bury yourself in tech debt.
> I'm not sure Google really wants to make a public IDE.
I mean, that's what launched Jetbrains in the first place. Google needed proper development tools for Android and a language more modern than Java at the time to support it. So we got Android Studio and Kotlin. They dumped a bunch of money into them and this is what we got once they started to get more independent.
I was using IntelliJ before Android came along, and Android Studio was Eclipse-based until Android 4.x (and Java-based well after that!). Kotlin was an alternative to Java 1.6, already fairly late, and wasn’t well supported on android until much later. Before ART, Android didn’t even run Kotlin outside of trivial programs because of the dex classfile limit!
Yes! And once you have it the way you like it can stay there forever hermetically sealed with all your plugins and integrations on pinned versions until you decide to upgrade them. The feature of "will work exactly the same forever until I have time to spend to deal with updates" is underrated.
> The spokesperson added that the company could have done better
They seem to have to say that a lot about this product, yet they don't really seem to learn any lessons. When the original flood of bad reviews came it it was because they made that plugin bundled with the IDE and then had a "bug" where it couldn't be effectively removed. There was no precedent for bundled a paid plugin nor need for it to be bundled with the IDE. Just their desperation to cash in. They then walked that back with the same "we could have done better".
This is more of the same. The "AI Assistant" still lives on the default side bar regardless if you have that plugin installed or not.
At this point, they know they could do better yet are choosing not to.
Not only are they quite open it is a means to cash in more InteliJ licenses, the community has generally an anti-Java sentiment, especially on Android, as if it doesn't depend on the ecosystem for its own existence.
The language might have a great design, however for me that is off-putting and makes me rather play with other JVM languages, like Clojure.
"The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin."
Ah, the forever cry of the crackpots. That's particularly rich complaint given it's a publicly editable resource. The only reason it could be in poor shape and "out of date" is because you yourself left it that way.
If that was a truly workable theory it would have verifiable predictions and compatibility with all prior observation and it would be eagerly explored. Scientists as a whole like to find anomalies and discrepancies; it is what keeps them in business. There is no "conspiracy".
Edits are removed unless they are published in well known journals which is fair enough for scientific results, but you cannot even update the page to state Mills latest engineering improvements or update factual information about the company.
If they have actual engineering improvements this sentence in the Wikipedia article could be easily disproved.
> BLP has announced several times that it was about to deliver commercial products based on Mill's theories but has never delivered any working product.
The main problem is there is so much power the device melts. They have now started using molten gallium electrodes (as of 2016), and now a quartz crystal housing that lets the UV light out and doesn't melt. They are offering hydrinos in a bottle to qualified labs. Stuff goes through a gas chromatograph faster than hydrogen.
It's always possible most of them already have done so :0
Seems to me the positive & negative charges would neutralize, and it would no longer be "matter" as we know it.
Not anti-matter, just not actual matter by any stretch of the imagination.
Which is what most of the universe actually consists of, not actual matter.
Matter itself is extremely rare, few, and far between.
Could be all there is left and can be perceived by those composed of it, are the things that can have a physical nature simply because their electrons haven't collapsed into the nucleii.
> Other general purpose languages are more popular and ultimately can do everything that Lisp can (if Church and Turing are correct).
I find these types of comments extremely odd and I very much support lisp and lisp-likes (I'm a particular fan of clojure). I can only see adding the parenthetical qualifier as a strange bias of throwing some kind of doubt into other languages which is unwarranted considering lisp at its base is usually implemented in those "other general purpose languages".
If you can implement lisp in a particular language then that particular language can de facto do (at least!) everything lisp can do.
One doesn't have to invoke Turing or Church to show all languages can do the same things.
Any code that runs on a computer (using the von Neumann architecture) boils down to just a few basic operations: Read/write data, arithmetic (add/subtract/etc.), logic (and/or/not/etc.), bit-shifting, branches and jumps. The rest is basically syntactic sugar or macros.
If your preferred programming language is a pre-compiled type-safe object oriented monster with polymorphic message passing via multi-process co-routines, or high-level interpreted purely functional archetype of computing perfection with just two reserved keywords, or even just COBOL, it's all going to break down eventually to the ops above.
Sometimes, when people say one language can't do what another does, they aren't talking about outputs. Nobody is arguing that lisp programs can do arithmetic and others can't, they're arguing that there are ergonomics to lisp you can't approach in other languages.
But even so
> it's all going to break down eventually to the ops above.
That's not true either. Different runtimes will break down into a completely different version of the above. C is going to boil down to a different set of instructions than Ruby. That would make Ruby incapable of doing some tasks, even with a JIT. And writing performance sensitive parts in C only proves the point.
"Any language can do anything" is something we tell juniors who have decision paralysis on what to learn. That's good for them, but it's not true. I'm not going to tell a client we're going to target a microcontroller with PHP, even if someone has technically done it.
I'm sure you are aware there is ultimately a chicken and egg problem here. Even given the case you presented, it doesn't invalidate the point that if it can implement lisp it must be able to do everything lisp can do. In fact given lisp's simplicity, I'd be hard pressed to call a language that couldn't implement lisp "general purpose".
"You're a very clever man, Mr. James, and that's a very good question," replied the little old lady, "but I have an answer to it. And it's this: The first turtle stands on the back of a second, far larger, turtle, who stands directly under him."
"But what does this second turtle stand on?" persisted James patiently.
To this, the little old lady crowed triumphantly,
"It's no use, Mr. James—it's turtles all the way down."
This is conflating slightly different things, though? One is that you can build a program that does the same thing. The other is that you can do the same things with the language.
There are special forms in LISP, but that is a far cry from the amount of magic that can only be done in the compiler or at runtime for many languages out there.
Yes, but sometimes doing the things Lisp can do in another language as easily and flexibly as they are done in Lisp has, as a first step, implementing Lisp in the target language.
This story just makes me sad for the developers. I think especially for games you need a level of creativity that AI won't give you, especially once you get past the "basic engine boilerplate". That's not to say it can't help you, but this "all in" method just looks forced and painful. Some of the best games I've played were far more "this is the game I wanted to play" with a lot of vision, execution, polish, and careful craftspersonship.
I can only hope endeavors (experiments?) like this extreme fail fast and we learn from it.
Asset flips (half arsed rubbish made with store bought assets) were a big problem in the games industry not so long ago. They're less prevalent now because gamers instinctively avoid such titles. I'm sure they'll wise up to generative slop too, I've personally seen enough examples to get a general feel for it. Not fun, derivative, soulless, buggy as hell.
If someone bothered to make deep, innovative games with cell-shaded anime waifus without gambling, they'd likely switch. This is more likely a market problem of US game companies not supplying sufficient CSAWs (acronym feels unfortunate but somehow appropriate).
Your dismissive characterization is not really accurate. Even in the cell-shaded anime waifu genre, there is a spectrum of gameplay quality and gamers do gravitate toward and reward the better games. The big reason MiHoYo games (Genshin Impact, Star Rail) have such a big presence and staying power is that even though they are waifu games at the core, the gameplay is surprisingly good (they're a night-and-day difference compared to slop like Blue Archive), and they're still fun even if you resolve to never pay any microtransactions.
it's accurate. I'm willing to bet those games wouldn't have 10% of it's players without the waifu and sex bait and the gambling mechanics. And there are gambling mechanics present even if you are f2p in those games, i bet. You just gamble your daily currencies or whatever. And it's always just one click away to actually spend money.
Not to say I'm a hater or something like that. I played a lot of those back in the day. But it's more honest to admit the art and the casino mechanic make the brain excited... the mechanics are 'okay'.
Edit: I just had a random thought. One of the strongest desire of a person is that of aesthetic desire. To feel that our life is 'picturesque' or aesthetic or beautiful. Overloading the game with aesthetic beauty is actually genius since it's an easy and strong form of aesthetic (beautiful girls. not just sexy but 'beautiful'. As in their whole face and outfit. Also other aesthetic quality like purity, innocence, cheerfulness, cuteness etc. Waifu stuffs.). And it's often so saturated with beauty that all ugly things in the players' real lifes fade away. It numbs our 'life aesthetic check' since it's flooded with so much 'beauty'. That's why people who play these games say 'i dont even think about the waifus anymore, so the mechanic must be good,' cause that numbed state is the intended state. Wheny our aesthetic center is kinda 'numbed'. And that's probably why it feels so good to play these games. When you play other games your sense of beauty is not similarly flooded and numbed, so you're all too aware that this action of playing games is not 'beautiful' in some real sense.
At the minimum I'd hope they a) do away with the worthless cookie banners requirement b) cut some generous but reasonable slack to small organizations.
Interesting timing with the digital sovereignty movement.
The cookie banners aren't worthless. The websites presenting cookie banners either don't know the law, or are engaged in spyware shit. You don't need a cookie banner if you need it to provide a service that the user expects (e.g., saving settings, login).
As an EU citizen, I'm not concerned about your need to observe my behaviour or to prevent ad-click fraud. What I care about is websites sharing my navigation history with Google or the rest of the advertising industry, so yes, I'd like to be informed of it.
Personally, instead of having banners, I'd just ban the practices altogether (e.g., targeted advertising, 3rd party analytics), which would certainly simplify business.
> The websites presenting cookie banners either don't know the law, or are engaged in spyware shit. You don't need a cookie banner if you need it to provide a service that the user expects (e.g., saving settings, login).
There's quite a lot between "engaged in spyware shit" and "service that the user expects".
For example if I want to add first party analytics to my site, the data from which I will use solely internally to try to figure out what pages people like and which they do not like, it is not "spyware shit" if I explain what I'll be using the data for and get permission from the user--and getting that permission needs a cookie banner.
Yes. For example, if you want to track unique users (for the most rudimentary analytics), you'll need to put a uuid in a cookie on their browser, and you'll need to damage your UX with a stupid cookie consent popup, thanks to EU Directives.
This is not nefarious data collection, and it shouldn't need user consent - but it does, because EU lawmakers were overzealous and careless when designing their regulation.
No, you dont! Only if you use third party services to do that or collect data thats not essential to your business. Its just coloquially called a "Cookie Banner", but the laws DONT require you to put up one as soon as you set one cookie!
It does if the cookie contains any uuid that might be linkable to a user's identity (which is obviously necessary if you want to perform rudimentary self-hosted analytics on unique user visits)
In the UK (and broadly under the UK GDPR and PECR – the Privacy and Electronic Communications Regulations), yes, you generally do need to get consent before setting non-essential cookies, even if it's just for rudimentary analytics like a unique visitor count.
Here's the key distinction:
Strictly necessary cookies: No consent needed. These are required for the site to function properly (e.g., shopping cart cookies, login sessions).
Analytics cookies (including the case with a unique ID for tracking visitors): Not strictly necessary, so consent is required.
Even if the data is anonymous or pseudonymous (like a randomly generated unique ID), if the purpose is analytics and it involves storing or accessing data on the user’s device (like setting a cookie), you must ask for consent.
> if I want to add first party analytics to my site, the data from which I will use solely internally to try to figure out what pages people like and which they do not like,
This is doable entirely on the server side, provided there is no caching or CDNs that get in the way.
What you lose with that method, however, is all the spyware-like shit that analytics tends to gravitate towards.
Cookies aren't spyware. If you want to disable them, disable them in your browser. It is something you send to the server. Not something they do on their end.
The issue is when you want to be able to stay logged in to a site, but do not want Google track you across the internet. Cookies do not differentiate between what they are used for, so sites have to make it clear only if they are going to track you. You do NOT need a cookie banner if you're not tracking your users
I don't see why small organizations should get to be more careless with my personal data than anybody else. The value of my privacy doesn't change just because of the size of the company.
It isn't "your data". Which pages you have viewed on my website is my data. It relates to you but is does not belong to you.
You don't have any privacy right to control data that belongs to other people and happens to relate to you. Privacy is about the state needing a warrant to enter your home and search it or to wiretap you. The idea it has anything to do with information you GIVE to websites by visiting them is a complete delusion.
Thankfully European statutes don't have anything to do with what words actually mean in the English language and don't override basic logic.
The idea that you have the right to control eg. my opinions about you, just because they happen to concern you, is fundamentally contrary to the most basic right we all have: freedom of expression. The cornerstone of civil and political rights.
If you're careful about how you store personal data in the first place, meaning you start a greenfield project today, being compliant with GDPR is a breeze. You make it sound like there is a ton of paperwork to fill out because of GDPR if you start a business today, which there isn't.
>If you're careful about how you store personal data in the first place
Unfortunately this is a really big "if" looking at typical businesses. They have no idea about how compliance should work and they also hire barely qualified people to marketing teams (often interns), who may accidentally add some privacy-breaking stuff. To prevent that they hire an external DPO and then deal with the paperwork for that DPO, who never visits the company onsite and never meets real people touching privacy topics.
So no, it's not a breeze, because there's generally no enough expertise and temptation to use American non-compliant MarTech is high.
One possible solution to that could be a pan-European registry of data processors with enough metadata to a) generate privacy policy, b) request correct consent, c) provide a compliance implementation checklist for non-trivial cases. There could be a small fee for adding services to this registry, but that would make maintaining compliance much easier.
Yeah, compliance for people who weren't careful before indeed is harder than for the rest. I think this works as expected?
Consider if wire fraud wasn't illegal before, but next week there is a new law coming into effect that makes it illegal. Of course all the companies who were doing wire fraud since before will struggle to be compliant, some might not even be feasible to run anymore if their core business becomes illegal.
Again, sounds like it works as expected, compliance for organizations who been ignorant for a long time is expected to be more cumbersome.
1. It is a problem for greenfield projects too. Not everyone has sufficient expertise to be fully compliant from the beginning. The accidental non-compliance is possible and there's usually a cost to prevent it.
2. It may work as expected from EU charter perspective, but current implementation is adding extra to an already high bureaucratic workload. My point is, it can be better than that.
> It is a problem for greenfield projects too. Not everyone has sufficient expertise to be fully compliant from the beginning
Saying it's complicated because of missing experience or knowledge is like saying creating a CRUD application is difficult. Yes, it might be difficult if you've never done it before, but that doesn't mean the thing itself is complicated, just that you potentially lack experience.
Instead, I'd say it would be complicated if it's hard even if you have experience and knowledge about it. And for GDPR and safely storing data, it isn't difficult in a greenfield project if you have experience with it.
> but current implementation is adding extra to an already high bureaucratic workload
As someone who've helped SMEs become GDPR compliant, in terms of engineering, there really isn't a high bureaucratic workload unless you were already very careless with how you stored data. For the ones who considered how personal data was stored for more than half a second, becoming GDPR compliant was mostly about confirming things rather than having to shift things around.
Few companies though, had huge problems as they 1) were revenue dependent on selling user data or 2) never considered how they were storing or protecting personal data at all.
If you're speaking from the experience of those last companies, then again I think it works as expected.
This is mostly true with security compliance in general from my experience. SOC II, for instance, is pretty straightforward if you were already doing things in a sane way. It’s only a lot of work if you were previously sloppy with security and need to rectify that
This must not be an expectation for any regulation that applies to business in general. Let’s say I just graduated from a college where I learned to be a plumber. I registered my firm and now want to acquire customers online, so I hire some local agency to build a website and an order form. You cannot realistically expect that I have any experience with GDPR or fully understand its requirements. It is the job of legislators to ensure that I can achieve compliance with minimum effort. But now I have to carry the burden, because no business can survive without digital marketing channels and I have to outsource the compliance work to ensure I don’t accidentally break the law. In comparison to pre-digital era doing any business today is more expensive and I‘d argue, it’s unnecessarily more expensive. It is not how it should have been done and it doesn’t work as expected from business point of view. Non-compliant businesses are not those who are malicious or ignorant, they can make mistakes because legislators did not help them.
This kind of line of thinking assumes a couple of things:
1. People are doing things the “wrong” way in the first place. It’s already been established that compliance isn’t hard if you are doing things the “right” way.
2. Compliance is hard. It really isn’t if you are doing things already the right way
Ultimately GDPR is not the problem, it’s people getting into tech that either have no understanding or respect for the data of others wanting to to do business. You wouldn’t expect me to be building bridges without complying to bridge building standards would you? Why is this any different? Lives are not directly on the line here, but the consequences of being sloppy with data are still very bad. This whole paragraph puts the cart before the horse because it assumes the most important thing is that the person in question is supposed to be able to transact business, not that the most important thing is to protect the personal information of people.
I’m not expecting the plumber to be a technologist. If the plumber wants to roll his or her own technology, fine, deal with the compliance headache. I expect the plumber to instead pay someone to figure out how to build the thing properly, just like how I don’t go building load bearing structures on my home myself because I’m not a structural engineer and don’t want to spend the time learning how to do that.
This is fundamentally wrong expectation. To preserve the spirit of EU charter one does not need the law where every business engaging with customers online has to pay a compliance tax to another medieval guild of experts.
Do you do your own structural engineering or do you pay someone to do it who is qualified to do so in the EU? Structural engineering compliance is a medieval guild of experts, is it not?
Do you practice your own medicine in the EU or do you pay someone to do it? Medical compliance is a medieval guild of experts, is it not?
What are you doing is a classical straw man argument. I‘m not disputing that plumbers, doctors etc should be aware of their professional regulations. However certain regulations aren’t job-specific and work like tax, e.g. if you look at notary costs related to registration of business in Germany. Regulations like GDPR apply to business environment in general and they have to be designed so that the costs of compliance and risks of non-compliance are minimized. They are supposed to be followed by non-professionals, because privacy is not a job of DPO, it’s everyone’s concern. What you fail to understand in my comments is that part. I’m not disputing the usefulness of GDPR. I‘m saying that rather than strangling businesses with high compliance costs and complaining that everyone is choosing to show cookie banner instead of not tracking, we should look at how to avoid this nonsense. As a matter of fact, non-compliance is rife, people do cut corners and take the risk, because DPAs cannot catch or punish everyone. GDPR is suppressing the most egregious behavior, but it certainly not working as expected. It needs some careful reform.
> However certain regulations aren’t job-specific and work like tax, e.g. if you look at notary costs related to registration of business in Germany.
This is not that. You’re making it sound like every business has to jump through all of these hoops as a matter of doing business. You know how to not be bound by GDPR? Don’t bother storing sketchy cookie data or PII. The plumber in your example could just… not do that and not have to worry about compliance. It’s only but for the plumber choosing to store that data that they opt to be bound by the regulation. It’s not a requirement for them to operate. If the business feels like they need to store the nuclear waste, then I need to know that they are storing it properly. They could just not take in and store the nuclear waste and then there’s no compliance burden. 9 times out of 10 they don’t need it to transact their business anyway, and the tenth business probably only exists but for the sketchy data.
In the end we have arrived at the same conclusion: probably the regulation itself, the baby, has some dirty bath water. Any regulatory framework of any significant complexity does, especially a landmark first of its kind in scope regulation in the world. So we should not toss both out. We should try to get rid of just the bath water.
With above said, the plumber is not absolved here. Why did they need to store my PII again? I very much value the fact that they have to think about and answer that question. So whatever improvement should just streamline that process and not get rid of it.
Can you please read my comments in this thread in full and not just pick some parts of them?
I already explained that most businesses are not experts in privacy and usually become non-compliant accidentally, without malicious intent. If a plumber goes to some advertisement platform to promote their services online, they are not making fully informed decision with regards to privacy implications. They buy promises of lower CACs. They do not buy the storage of PII, neither they fully understand that targeted advertisement involves storage and processing of PII.
And regulation requires them to either fully understand the process or spend money on external consultant. That's stupid: GDPR moved the responsibility to protect human rights from those who aggregate a lot of data to a little guy. What really should have been done is requirement for MarTech to support "Do not track" on protocol level and risk being fined or banned from EU. It does not make sense to ask users again and again on different websites if they are ok with tracking by FancyMarTech LLC, when those users already gave the answer somewhere.
It's just one example. And then there's a case with storing PII in Google Spreadsheet: everyone does that. Nobody mentions that in their privacy policy, even if DPO is involved. And probably they should not. Regulation should also consider the public risk. If one of those millions spreadsheets with a hundred names is leaked, let's fine the owner, sure. But let's not make a big compliance process for every owner of those millions spreadsheets. Let's say: Dear Google, if you want to work in EU, you cannot share the data of EU users with NSA or anyone. Keep it safe. Figure this out, we don't care how. We really should put 99% of compliance burden on processors and spare controllers.
Thanks for sharing some in depth examples. Why is the marketing firm/platform not on the hook for noncompliance in your first example? That’s kind of where the metaphor falls apart for the doctor and structural engineer examples, because in this case if you were found to be liable the responsibility would actually fall on the doctor/structural engineer. Like if I hire a structural engineer and they build a thing that fails, they’re ultimately on the hook for it, not me. Why is it not the same here?
Your Google spreadsheets example is not, in my opinion, a good example of GDPR failure. I genuinely believe if people are dumb enough to keep PII in spreadsheets they deserve to be fined out the ass. “Everyone is doing it” is a poor justification for such risky behavior. The plumber in your example would never use the wrong pipe fittings or make dumb mistakes like that in their line of work. And if they did, they would understand that they would be on the hook for that. Why should they be absolved of responsibility in some other line of work simply because “everyone does it this way”?
Your example reminds me of HVAC technicians in the States who vent refrigerant into the atmosphere. “Everyone” does it because it’s way easier and more convenient to just do it and ignore the regulations, but the long term consequences for the environment are horrific. I’m sure if I asked those HVAC technicians they also would describe the regulations that they don’t want to abide by as onerous and not necessary.
>Why is the marketing firm/platform not on the hook for noncompliance in your first example?
Because they act in good faith and expect that consent is collected before their script is executed. This is usually written in their ToS, e.g. see Google Analytics. Google expects that you maintain compliance and if, because of your failure to stay compliant, they collect PII without consent, you are liable for the damages. See what happens? Every small business who wants to know something about visitors of their website is now on the hook. They are expected to understand GDPR, to understand legal details of Google ToS etc. Since you cannot avoid having digital presence today, this looks pretty much like a compliance tax.
>I genuinely believe if people are dumb enough to keep PII in spreadsheets
You are speaking about majority of population of this planet now. Everyone prepared at least once in their life a list of contacts to send wedding invitations, list of customers for a freelance job etc etc. People are not dumb. They just keep doing what they were always doing: having a sheet with a list of contacts. And honestly, they should continue, because why not? Why we should put significantly more thought in this simple task? Yes, the tools have changed and we now have implicit privacy and security risks associated with them. We should fix the tools and assign liability properly.
> Because they act in good faith and expect that consent is collected before their script is executed.
This is the unaddressed rub here. If the doctor commits malpractice in good faith, they’re still liable. If the structural engineer built a bridge that collapsed in good faith, they’re still liable. Why does the marketing firm get off the hook here?
The argument being presented here, that regular people should continue to be allowed to do Sloppy and Dangerous Thing, because it’s normal, is not sufficient. It also used to be normal and way easier for people to get on a plane without being strip searched and their privacy being violated. Society decided that forcing regular people to go through a ton of more hassle for safety was worth the trade off. The security is mostly theater, the implementation is burdensome, onerous and unpopular and a regular person is expected to navigate some kafkaesque nightmare with a bunch of rules and might unknowingly burn themselves. But we sure as hell don’t see a ton of plane hijackings any more, do we?
>Why does the marketing firm get off the hook here?
You may be surprised, but this is how this regulation is designed. Per GDPR it is the duty of controller to ensure compliance. Processor acts per instructions from controller. MarTech is not allowed to do anything outside of their contract with their users, but they are also not required to enforce consent collection, only to assist controllers with that when possible.
>The argument being presented here, that regular people should continue to be allowed to do Sloppy and Dangerous Thing
No, this is not the argument being presented here. Storing personal contacts or advertising is not "sloppy and dangerous thing" per se. The privacy risk is not that someone is processing your PII, but that this data may be used to harm you by processor or 3rd party. So the goal of regulation should not be to prevent processing, but to minimize such risks with minimal costs for society. If regulation focuses on just risk, but does not consider the costs, it must be fixed and solutions should be found that enable typical use cases.
> This must not be an expectation for any regulation that applies to business in general
Why not? We have that for a bunch of professions already, and for good reasons. You can't just claim to be a doctor, run a hospital or work as a electrician, you need to prove you're able to, before you can do certain things.
Engineers should already be data-aware by default, regardless of what regulations, since we do have the expertise to understand it. Then I guess the expectation was initially kind of that businesses would self-regulate, but seemingly not, so here comes the end of the cowboy developer days, if you want to build large companies that handle people's personal data at least.
> You cannot realistically expect that I have any experience with GDPR or fully understand its requirements
If you build websites where the idea is that you store people's personal data, then yes you should understand what that means and how that works. Like if someone called a plumber for a pressure problem, and the plumber says "How am I expected to understand how that works in your specific house?!", of course I expect the plumber to know their shit around their profession. If you don't understand the technology nor what rules you have to follow, then don't go into that profession.
> Non-compliant businesses are not those who are malicious or ignorant, they can make mistakes because legislators did not help them.
In my experience, the companies who had a hard time becoming compliant with GDPR were companies that either made their revenue by selling user data, and now had to make a lot of changes, or companies that were careless with data in the first place, not thinking twice about where to store things or who has access to what.
I'd be happy to see any sort of counter example of a company that A) doesn't make their revenue based on selling personal data, B) have a thoughtful architecture/design for data in the first place, together with C) had a difficult time becoming compliant with GDPR.
> Why not? We have that for a bunch of professions already
…
> Engineers should already be data-aware by default
Most businesses in this world are not run by software engineers. Engaging with people for whatever reasons via digital channels is not a profession. I don’t really understand your point: as I said already several times, the law can and should be improved. Do you disagree with that? Do you insist that every plumber or relocation business should be an expert in GDPR?
This pretty much. I've had a lot to do with GDPR in the projects I'm involved with. It's largely trivial if you aren't already doing terribly risky things, in which case yeah, it's a pain, but it doesn't change the necessity of fixing issues that put user private data at risk (with or without the GDPR existing). GDPR just puts more incentive on solving issues in regards to privacy instead of just letting companies shrug and move on because it's not their problem if data is stolen or leaked or letting them do what they want with the data without permission.
The cookie banners don't make companies less "careless"
They just introduce a needless bit of friction in the UX.
If the EU wanted to prevent digital identity triangulation or cross-domain advertising data gathering, it should have banned it outright. Rather than getting all users to click a stupid banner every time they visit a website.
So, since they didn't ban it outright, doesn't it make it clear that the goal wasn't to remove it fully? The goal was to let users be informed about it, so they can make their own choice, not to remove the choice at all.
The core of the system is simple - you list the third parties you send data to, you make accepting and rejecting equally easy.
Consider basically any popup on a popular website which: takes over most of the screen, makes "accept" the highlighted action button, requires going through "customise" to reject, sometimes requires unchecking categories manually, puts "save and exit" and "accept all" that so the same thing next to each other, either hide or not provide "reject all", etc.
There is no conspiracy here. You can either not use third parties, or if you do, your approval system doesn't have to be obnoxious at all, but almost every page makes it a shitty experience to 1. Make you accept out of frustration. 2. Make your angry that this is asked in the first place.
Let's say I want to improve my site by recording basic user analytics like unique user counts, to produce actionable data. I'm not nefariously collecting their social security number. I'm just putting some uuid in a harmless cookie in their browser so I can track which requests are from a unique browser.
Thanks to the GDPR I cannot do this without the stupid cookie warning popup.
In this regard, the GDPR is clumsy lawmaking that results in companies having to behave defensively, hoping that users will accept a damaged UX in order that the company is not fined by the EU.
In the UK (and broadly under the UK GDPR and PECR – the Privacy and Electronic Communications Regulations), yes, you generally do need to get consent before setting non-essential cookies, even if it's just for rudimentary analytics like a unique visitor count.
Here's the key distinction:
Strictly necessary cookies: No consent needed. These are required for the site to function properly (e.g., shopping cart cookies, login sessions).
Analytics cookies (including the case with a unique ID for tracking visitors): Not strictly necessary, so consent is required.
Even if the data is anonymous or pseudonymous (like a randomly generated unique ID), if the purpose is analytics and it involves storing or accessing data on the user’s device (like setting a cookie), you must ask for consent.
Cookie banners are not a requirement in the first place. They are a convention set by giant risk-averse consequence-free tech companies, and followed by everyone else.
>At the minimum I'd hope they a) do away with the worthless cookie banners requirement b) cut some generous but reasonable slack to small organizations.
Cookie banners aren't a requirement unless you wish to store cookies that aren't strictly necessary (statistics, marketing, etc)[0]. Cookies that are essential for the user to browse the site (login tokens) don't require consent.
It doesn't help the situation that a large number of sites seem to maliciously comply with these regulations.
>Cookie banners aren't a requirement unless you wish to store cookies that aren't strictly necessary (statistics, marketing, etc)[0]. Cookies that are essential for the user to browse the site (login tokens) don't require consent.
So if I use telemetry to catch some dirty frontend blob throwing a hissy fit of an exception and that telemetry is tracking sessions rather than individual events (hello ms app insights) -- is that functional or, statistics or etc?
If you are monitoring the system but not its users, then that is not collecting PII.
To be completely sure, you should eliminate anything that might be considered PII.
So unadorned exception counts would be anonymous, aggregated statistics, which is fine. But exception counts reports per IP address, or per session, or where the exception text mentioned the user's PII, would require consent from the user you're tracking by processing that data about them.
If your salary would drop 95% tomorrow if you didn't tell everyone at the office 'I may remember this conversation' every time you see them, what would you do?
Non targeted ads pay 90+% less than targeted. Sure it's not 'required', but the vast majority of businesses would fail overnight if their revenue dropped 90%.
If you heavily rely on performance marketing, your business model is anyway in trouble. In the past businesses survived with non-digital marketing channels just fine.
The cookie banners are largely a cargo cult and don't have to be nearly as annoying as they are.
Websites just love to say "we have to do this" rather than improve their UX because the latter just means more work while the former gets people to be wrongfully upset at GDPR.
I think cookie banners are a not-so-subtle sabotage of the GDPR. The more annoyance they can associate with GDPR the more the customers will want to water it down. And bonus, it's completely deniable.
And it's largely working. Even on a site like HN where you'd expect people to be educated about this stuff, we have people claiming that GDPR (and not their own data collection practices) forces them to pop up a cookie banner.
On a site like HN you'd expect a significant proportion of people to be willfully ignorant and/or make excuses about this stuff because it helps them sleep at night.
I have been suspecting for a while that the "consent" escape hatch was a concession to get GDPR past the advertising industry's army of lobbyists. Making the problem in-your-face-visible is hopefully only the first step in garnering support from the public. It's much easier for a politician to point to all the obnoxious pop-ups and say "look at this despicable behavior! These companies choose to nag you at every opportunity because abusing your privacy makes them a couple cents. They should just not be allowed to do that."
Nah, next step would be to pull the UX noose tighter and tighter, limiting things like number of clicks to reject non-essential cookies, restricting data loss (like if you already filled in some form data, etc.), maybe even limiting how much of the screen they're allowed to take until the user clicks on "read more" or whatever, etc.
I don't think this is necessarily going to happen, but that would be the reasonable next step from where we are now: boiling the advertiser frog slowly and with changes that users would consider uncontroversially positive.
Silicon Valley has such an antagonistic view of user consent and user control, and when they're forced to acknowledge and respect it, they do it in the most tantrum-y, malicious-compliance way they can. It's like the Bob's Burgers meme: "OK, Fine. But I'm gonna complain the whole time."
Ironically, if these companies didn't choose to make their consent UX so deliberately hostile and in-your-face, we might never have had this much visibility into how big of a problem it is.
They definitely aren't cookie opt-in popups in any browser. Nor is there coarse-grained cookie management, like what websites implement. Nor fine-grained cookie management, like they should have.
Be the change you want to see in the world. It is supposed to be a user agent. Instead of imposing this cost on everyone else, if you think it is important to be able to have fine grained control over cookies, make it happen.
Advantages:
1. A single UI in each browser instead of a different one on each website
2. The functionality would be built and maintained by someone with allied rather than adverse interests to the user.
Also you can disable cookies quite easily and whether your UI supports it or not is totally irrelevant anyway. If you use a web browser that sends cookies to websites then that you have authorised it to do so is your responsibility. Use a different browser or don't use one if you don't like it.
>> a) do away with the worthless cookie banners requirement
My understanding is that if your site doesn't use cookies, you don't even need that. Don't use cookies, don't collect or share personal data, and GDPR is complied with. Apparently from TFA it sounds like even then you have a lot of proving it to the government, and that's a hassle.
Nope and nope, same rules are for all. You want to steal private data, you will be labeled. If it comes from libs, maybe don't use shitty private data stealing libs?
Move fast and break things - fuck that, anybody smart enough can project to what sort of society it leads down the road.
> do away with the worthless cookie banners requirement
There is no such requirement. You're free to make a website that doesn't require cookies.
This very website on which we're discussing doesn't have a cookie banner, and isn't required to have one.
(I'm not saying HN is GDPR compliant though, it's missing a DPO mail address to allow edit/deletion of older PII messages and a privacy policy even though said policy would probably be max 10 lines)
> cut some generous but reasonable slack to small organizations.
I can't say for other countries, but in France there is already already a lot of slack even for bigger organizations. We have mainstream websites that are obviously violating the GDPR (most visited cooking site, most visited tv content provider, not allowing free choice of refusing tracking)
> (I'm not saying HN is GDPR compliant though, it's missing a DPO mail address to allow edit/deletion of older PII messages and a privacy policy even though said policy would probably be max 10 lines)
The privacy policy is here [1], linked in the footer. It also very clearly says: "For deletion requests, please contact us at privacy@ycombinator.com.".
You are required to have a cookie banner if you use cookies, and you have to use cookies or an equivalent technology to persist state in a logged-in website (like HN).
To pre-empt the typical reply, yes you must serve a cookie banner even if you are only using functional cookies.
You are required to OBTAIN CONSENT from people you want to process the personal data of. Their consent must be INFORMED by telling them who you are and what you intend to do with their data. Their consent must be FREELY GIVEN and can be WITHDRAWN at any time.
That's what's at stake; not the cookies/state themselves, but how you intend to process the data of individuals. As long as you are not profiling natural individuals, no matter how they leave traces, then you don't need to ask for their consent.
It's bad-faith people, who clearly want to process personal data, who make a huge fuss and tell you everyone needs a cookie banner. Mainly because they are raging that they can't data-mine and monetise every last byte of data they can get, without the consent of the individuals they're profiting from.
Please take a close look at the cookie banner that loads on the page you linked. It says:
> This site uses cookies. Visit our cookies policy page or click the link in any footer for more information and to change your preferences.
And then there are two buttons: "Accept all cookies" and "Accept only essential cookies".
The banner is doing two things. 1) It is notifying you that the site uses cookies. 2) It is requesting your consent for non-essential cookies.
Think about this for a moment, why is it doing both things? Why doesn't it just say "Do you consent to non-essential cookies? Yes | No"? Do you think this website added an extra sentence to their banner just for fun?
If you want to use essential cookies, you don't need to ask for consent. That is true. But you do still need to inform the visitor that you are setting cookies. Just as this banner does in its first sentence.
I spent months implementing GDPR compliance with a set of EU-based lawyers.
Most businesses are not actually GDPR compliant, even to this day. I assume this is a big reason the EU is willing to take another look at what is required for compliance.
From my experience, companies taking months to get GDPR are ones that want to tick the box, but don't want to follow the law, so they have to go through the trouble of justifying gathering unnecessary data for themselves and their 873 trusted partners. They usually end up noncompliant anyway because GDPR is a pretty sensibly written law that you can't just work around with a crappy popup, but enforcement has unfortunately been lacking.
I've also helped a bunch of organization become compliant, some were easier than others. The ones that were harder were the ones that generally didn't have good processes with data in the first place, where everything was scattered all over the place and everyone had access to everything. It makes sense to me that it's harder to be compliant if you were borderline malicious with how you treated personal data before GDPR.
Practically speaking, if you’re running a website, you can’t implement compliance with the ePrivacy Directive without also considering GDPR, and vice versa.
No. The reason it exists is businesses get guidance from legislators and existing case law on what prevents you from running a foul of GDPR and the cookie banner is what we ended up with. If those banners did nothing, companies wouldn't include them. They are there as the lowest effort legal defense.
Again, the cookie banners have nothing to do with GDPR, where are people getting this misinformation from?! Was there a popular article saying we have those cookie banners because of GDPR, or what?
The banners are the result of much earlier directives that predate GDPR by a lot...
It's not misinformation. Yes ePrivacy predates GDPR but it had no teeth. The reason your replies are full of people saying, "Our lawyers told us to implement it for GDPR" is because it was a minimal thing you could do to meet GDPRs emphasis of receiving consent from users for data stored in cookies. Basically the fear of fines from not being GDPR compliant forced companies add them.
I agree with you these cookie banners are not sufficient by the text, but in practice unless EU commission and courts make lawyers believe these banners are worthless, EU legal teams will still recommend them.
> What these two lines are stating is that cookies, insofar as they are used to identify users, qualify as personal data and are therefore subject to the GDPR.
gdpr.eu is by the way not an official resource of the European Union but by the Swiss Proton AG. They note down the page that gdpr.eu doesn’t constitute legal advice. Although they are correct in this case and your misunderstanding was in reading for future internet discussions I'd recommend not using private sources.
Consent for non-essential cookies, like analytics, is required. You must also provide a clear link to your cookie usage policy, and a simple way to opt-out. This notification is not necessary if you only use functional cookies; for example, using a cookie to only show an on-boarding tutorial once is acceptable.
Organizations, and typically lawyers, skew conservative and lazy. A little cookie-consent cottage industry popped up to handle GDPR, so instead of worrying about the regulations most companies pay the small monthly service charge for a third party to handle consent. The consent companies built the most compatible solution, a banner, with the most conservative options as default to prevent any legal quandary.
Most public facing sites do have analytics (usually LOTS of analytics) and ads, so the banner is mandatory for them. If you understand the regulations, and don't violate them, then consent is not necessary.
This is simply not correct. You absolutely DO NOT need to obtain consent for strictly necessary first-party session cookies (such as would be used by an online shopping cart, for example, or to maintain a persistent login) [1].
I didn't say "obtain consent," I said serve a cookie banner. If you are only setting essential cookies, the banner can just say "This site is using cookies," with no opt-out or preferences button. But it does need to appear.
Should is aspirational language, and is not legally binding or even coercing. It's like an encouraged practice.
Cookie banners where sites have to say "we're sharing your details with 287 partners" are okay because they should be shameful for the industry. Cookie banners where you're explaining basic technologies of the web -- "we store a cookie to create a stateful session with your browser" -- are obnoxious noise that do only harm.
> do away with the worthless cookie banners requirement
Not a GDPR thing, and the reason you see the banner is because companies refuse to understand the regulation correctly.
> cut some generous but reasonable slack to small organizations
Some more slack you mean, since they already have a lot of slack compared to larger organizations?
What exactly is so cumbersome for a small business to comply with? They're generally "common sense" requirements, and most organizations who already take care of their data basically had to do nothing to be compliant. What are you doing that is so complicated or essential that it's hard to comply, as a SME?
> Not a GDPR thing, and the reason you see the banner is because companies refuse to understand the regulation correctly.
Companies will never "understand the regulation correctly" because it's not in their interests. That is why the regulation should be bulletproof: as concise as possible while forcing the exact behaviour regulators intend.
> possible while forcing the exact behaviour regulators intend
That's what I'm seeing happened?
1. Companies store personal data willy nilly
2. Regulators create directives that force companies to stop doing that, or at least be upfront about it
3. Companies who still want to do it, are at least up front about it, telling users what is happening
4. Users now complain about regulators that companies are letting them know, missing the fact that the only companies who are adding those banners, are companies who are hellbent on doing these things anyways.
The GDPR does not enforce the use of cookie banners. Cookie banners is an IAB idea. My suspicion is that they were created to make people angry at GDPR, but they have nothing to do with GDPR.
On most website that I've analyzed (and it's quite a lot - into hundreds), you can remove the cookie banner and the website would be just as GDPR (in)compliant as with the cookie banner.
> Consent-O-Matic is a browser extension that recognizes CMP (Consent Management Provider) pop-ups that have become ubiquitous on the web and automatically fills them out based on your preferences – even if you meet a dark pattern design. Sometimes a website might not use standard categories, and in that case, Consent-O-Matic will always try to submit the most privacy preserving settings.
I believe uBlock Origin can automatically do this by enabling "EasyList – Cookie Notices" in the extension settings. If you have this extension installed, there's no need to install another.
Interesting choice to pick something like hiqlite over something like sqlite or an equally well-established solution as the default implementation for something as important and long term as an auth solution.
