Hacker News Reader

Comment by tgsovlerkhgsel | Hacker News Reader

Background (which also explains why it's being rolled out in France first): https://www.theguardian.com/technology/2022/jan/06/france-fi... - on January 6, Google was given 3 months to fix this, with a 100k fine for each additional day.

I'm wondering why it took slightly but not significantly more than the 3 months. On one hand, adding a button doesn't have to take 3 months despite all the necessary reviews etc., not if it's actually considered a priority. On the other hand, if the benefits were considered worth the fine/fee, you'd expect a bigger delay.

View on HN

Personally I wouldn't read too much in to the timing. Although the end result looks small the change affects multiple large projects, each with hundreds of millions of users, and likely has knock on effects in other parts of google. Sprinkle in a bit of legal review + big company bureaucracy and I can easily imagine it taking 3 months.

They'll gladly pay (maybe) 2 million in fines so that later they can pretend complying was extremely difficult for them. Drop in the bucket in the long run.

Just came here to say I really liked your userid (or whatever is called nowadays).

> I'm wondering why it took slightly but not significantly more than the 3 months

Maybe they planned for 3 months and it took longer?

I can guarantee that the vast majority of implementation time was more likely due to verification and auditing of the solution, rather than the solution itself.

The company I work at would break if cookies weren't allowed. It would be a mad scramble to change many many things to just function at all. 3 months seems pretty fast to me to be honest.

you don't need to ask permission for functionality cookies, only tracking and such

The line is blurry sometimes.

Also there is likely lots of code that would break without a tracking cookie passed to it because tons of code is written with the assumption the cookie would be there.

well, it wasn't just the last 3 months that there was supposed to be a way to disable those, just that it has to be a single button now (which afaik was previously already the case anyway)

GDPR is in effect since four years ago. Are your deps older than that?

Most people's deps are older than that. And vast swathes of easy-to-use open-source web infra has non-GDPR-compliant defaults.

Cookies have been controversial for at least a decade. They knew this was coming.

The blog post mentions:

> This update meant we needed to re-engineer the way cookies work on Google sites, and to make deep, coordinated changes to critical Google infrastructure.

That's acknowledgment of the fact that trampling people's privacy is Google's business model.

Google has a very strong interest in developing tracking techniques that do not require cookies, so they can appear to be on the side of the public with respect to privacy, while also securing a competitive advantage for tracking in a post-cookie world.

The good thing about the GDPR is that it's about the act of tracking and collecting data as opposed to focusing on specific technical means, so moving away from cookies won't allow you to work around the law.

No they didn't have to. Rejecting all cookies was possible before, it was just hidden behind convoluted and confusing menus. To make this functionality available with a single click of a button they didn't have to invent any new technology or process or backend service. Just move the onClick handler to a different HTML element on a different page.

And everyone could build Twitter in a weekend.

Google cookies do not work that way. Ironically, one of the challenges is that some of them are firewalled from each other so that it's harder to aggregate a holistic picture of a user in one location. You know, for privacy reasons.

And not even moving an onClick handler is trivial given the layers of abstraction that Google's UIs are built on top of.

Submitting a form with toggle controls set to the off position is not “building Twitter”.

The only reason this would take 3 months rather than a few days is if:

A) they were lying before in the old cookie popup

B) they are dragging their feet out of spite

Not sure which is worse honestly.

There is also room for C) they had millions of crappy partial copies of the same pop-up, much of which had to be fixed by hand

It's D) The hard part is the backend data storage, not the frontend.

People's intuition of how user data storage and retrieval works at Google scale doesn't align with the reality. Cost of storage (immediate and secondary), effect on creation of new permissions, privacy protection, user security (can this new option somehow be used to leak userdata or trick users into doing something they didn't want to do?), and (if they're only rolling this out in Europe) region gating all have to be accounted for.

> Submitting a form with toggle controls set to the off position is not “building Twitter”.

That's also not what "reject all" does.

It should be effectively the same, otherwise

A) they were lying before in the old cookie popup

Not at all. The previous pop-up gave you the opportunity to switch off every item individually. What do you think would happen if new items were added?

The new button sets a new default that affects new options for data collection. And yes, adding one new field that affects user configuration across all Google properties (or even two major Google properties, such as the main site and YouTube) is a one-quarter project. Privacy review, legal review, data storage assessment to make sure an additional Boolean isn't going to blow a limit somewhere, thinking through all permutations of options users could already have set to make sure that this new feature doesn't break existing user configurations... Hell, they probably had to do analysis to make sure that you couldn't uniquely identify users based on the setting because of how many / how few people would click reject all. And did they roll it out everywhere or just in europe? Europe only requires additional work.

It's a big corporation, extrapolating how it works from small corporations leads to inaccurate conclusions.

That may well be. However, I’d argue that effects like these are just the cost of doing business at their scale – and therefore entirely their problem. No one outside of the affected corporation should need to care at all.

Oh, definitely. This overview was an explanation for why "Just adding one new option" is a one-quarter project and not nearly as simple as people from smaller operations assume it will be.

... in fact, I think this is indicative of the risk Google experiences now of disruption. At their scale, they are no longer agile. When a company is willing to spend money on a daily fine for exceeding the target deadline after three months, they're signalling strongly that smaller, more focused operations can out-maneuver them.

I have seen websites were you have to go through a list of 20 fucking companies that want to put a cookie in your browser.

Honestly I'm at the point where I just give up. Whomever gets to infiltrate beyond Firefox tracking protection and ublock: congratulations.

Get noscript

Yes, you will need to white list many websites, yes, you will also become appealed at the sheer amount of cookie requests you receive and thank God that you have installed noscript every day

uMatrix is/was even better - fine grained website x technology control with an intuitive interface.

I wonder if they switch the button order for Windows vs. Mac users.

Maybe they just wanted some extra time to do A/B tests of different layouts.

They are definitely already A/B testing this. I'm in Germany and sometimes I see the "Decline" button when opening Google in an incognito window.

I wonder what they'd be A/B testing for... which 'Decline' button gets the least clicks?

My guess is they just A/B test everything by default, even stuff that's court ordered.

Basically true but not the terms I'd use; they aren't really A/B tests but staged rollouts, though the process and tooling required is similar. We did staged rollouts of _everything_ back when I worked on google search that wasn't a trivial bug fix. We'd move it to 1% for a day, check metrics, increase to 10%, hold a couple more days and check metrics, then to 100%. Very sensitive or risky launches might hold at a full 50% for some time. UI changes were "dark launched" behind a flag that we incrementally flipped on. The reason is that no test suite captures reality and this discipline forces you to account for easy rollbacks (just turn the flag off) and handle "skew" (the case where I user starts a session where the flag is off but then starts talking to a machine where it is on, or vice/versa). This was in addition to the binary that released multiple times a week and rolled out slowly over the course of the day, and often this happened after multiple versions were tested in experiments with statistically significant samples.

Or which version results in the least engagement / fastest click. You don't necessarily want to prompt introspection about privacy.

This is absolutely true. I took a survey through MTurk from Google, from back when they were reworking the "ad" icon on search results. They wanted me to quickly select the first non-ad, with different "ad" icon styles (same color as rest of text, different shapes, etc).

To check it's not broken before they roll it out Europe-wide.

That's not an A/B test per se, thats a blue/green release.

Reply on news.ycombinator.com