New in Chrome 113 | Hacker News Reader

New in Chrome 113

developer.chrome.com

180 pointsfeross96 comments

I honestly think this move toward "less tracking" (3rd party cookie restrictions) is having the opposite intended effect.

It used to be you could just "clear your cookies" and you'd have a virtually clean identity on the internet. Now basically every ad platform, including Google Ads, is heavily encouraging the use of "first party data" - aka name, email addresses, phone numbers, mailing addresses - as a way to target customers. Google Ads help docs specifically cite the phasing out of cookies as the reason advertisers should send Google as much "first party data" as possible.

In effect, that means "clearing your cookies" will do nothing if you're the average Google users who's still logged into chrome/google after clearing your cookies.

And instead of Google + ad networks just having your data in cookies, now they have your name, email, mailing address, zip code, etc provided to them on the backend with no way for the consumer to easily opt out or delete their data.

Edit: adding another supporting example: for advertisers tracking conversions, it’s no longer good enough to just fire a conversion pixel on a checkout page. Now it’s heavily encouraged to send the user’s personal data (email, name, phone, etc) along with the conversion pixel/tag so Google (or whatever ad platform) can match the conversion to clicks without cookies at all. This type of conversion tracking was not pushed or encouraged until browsers started phasing out 3rd party cookies.

Edit 2: Google has even gone as far as adding a setting to their AdWords tracking tag that automatically scrapes the HTML of a page in search of anything that resembles a user’s email address or phone number to make it easier to collect first party data automatically.

I agree with your general comment, and would add fingerprinting to the list. Many ad networks now fingerprint users to generate an identity for tracking when cookies are not available, which didn't used to be worth it before the phase out. And of course clearing your cookies doesn't clear your fingerprint.

> Google has even gone as far as adding a setting to their AdWords tracking tag that automatically scrapes the HTML of a page in search of anything that resembles a user’s email address or phone number to make it easier to collect first party data automatically.

Really? Link?

“Automatic enhanced conversions”

https://support.google.com/google-ads/answer/10763826?sjid=1...

The help docs are a bit cryptic, but the UI within Google Ads is a lot more straightforward in how it works. It searches the landing page for an email address to automatically pair with a conversion event. All the advertiser needs to do is accept some privacy policies and enable the feature.

Thanks! They write "sending hashed first party conversion data from your website in a privacy safe way" but it's just hashing (https://support.google.com/google-ads/answer/9888656) the email address etc, which really does not deserve that description.

Who the hell is giving my name, email, mailing address, zip code, etc. to Google? I'd like to have my lawyer get in touch with them.

I definitely did not consent, in fact I go out of my way to tell companies I give such information to not to share it with anyone.

Now you can just not have an account or any first party data given to a customer, or with tools like anonaddy and fake people generator, you can spoof first party data that won't be matched when hashed and compared across different platforms.

I'm curious, would you purchase a membership to youtube if it included absolutely no tracking, sharing of first-party data, or advertising at all?

I guess I shouldn’t have been shocked but this week looking at some display ads, in Googles audience builder there’s literally an “upload email of who you want to target” feature. Made my skin crawl. Can’t tell me that’s not abused to the ends of the earth and back - some marketing interns will just go nuts, GDPR be damned

Thats remarketing. Target your existing customers. Your cohort needs to be a certain size and can't just put one person in the ad target.

The problem is remarketing used to work great without sharing email addresses with ad platforms.

Now without cookies, you typically want to share email, phone, zip code, etc in order to do remarketing without 3rd party cookies.

No ephemeral 3rd party cookies = ad platforms rely on user data that never changes (email addresses, phone numbers, etc)

There's got to be some more regulation around advertising in general. I just don't see how it adds anything to the world that even begins to compensate for the damage. It should be like cigarettes, something we used to see as a legitimate business but decided we're really just better off taxing the heck out of and boxing into very limited places.

I agree with your advertisement of your viewpoint.

An easy example is that websites with billions of satisfied users (tiktok, facebook, instagram, reddit, twitter, and google) are all primarily funded through advertising.

Blame the Irish.

Sorry but this just sounds like victim blaming. If a guy threatens you with a stick, and you take his stick away and he pulls out a gun and goes “look at what banning my stick led to!”, it’s not the banning that’s the problem.

So with first party sets is this suggesting that Google can declare doubleclick.com as a "trusted first party" and undermine any ability to allow Google.com and YouTube.com cookies but block their 3rd party ad tracker?

It seems like they're just trying to remove any distinction between 1st and 3rd party cookies at all.

https://github.com/WICG/first-party-sets#non-goals has:

Non-goals: ... Information exchange between unrelated sites for ad targeting or conversion measurement.

To get something onto the list (https://github.com/GoogleChrome/first-party-sets/blob/main/f..., currently empty) you need to make a public PR with rationale (https://github.com/GoogleChrome/first-party-sets/blob/main/F...). It doesn't look to me like DoubleClick would qualify?

Sure, for now. Until people are accustomed to this system and it's just a "small update to policy" they hope goes unnoticed in 12 months' time.

Quite literally the same company is trying to neuter adblocking with Manifest V3 right now and pitched it as "improvements to security."

I mean, if you block cookies, you’re using a browser extension, and that extension blocks whatever you tell it to; it’s not affected by First Party Sets.

Google’s changes only affect people who use vanilla Chrome. And the people who use vanilla Chrome without any privacy extensions don’t have much privacy to begin with, so First Party Sets does not make things much worse than they already are.

> I mean, if you block cookies, you’re using a browser extension

If all you want to do is blocking cookies, why would you use a browser extension for that? Most browsers ship with a configuration option to disable them.

For Chrome/Chromium it's over at chrome://settings/cookies

> why would you use a browser extension for that?

To avoid breaking sites that cease to function without cookies. EFF's Privacy Badger is pretty good at this and it allows you to select individual domains in the popup to add or remove the ability to receive cookies.

I use Privacy Badger to selectively restrict cookies. It lowers the tracking at least a bit, while it's almost never broken a site. Completely disabling cookies can break a lot.

Why would they need to? DoubleClick literally has a built in backdoor with the undisclosed and impossible to disable "X-Client-Data" telemetry header.

DoubleClick is hard coded into every Chrome browser :) [1]

[1] https://chromium.googlesource.com/chromium/src/+/e51dcb0c148...

Yup.

Google pretend-playing "building a more private web" again.

Blocking third party cookies is great, but with these "Third-Party Sets", self-appointed gatekeeper Judge Google (Judge Dread) takes requests from website owners for lists of domains they control to be partially exempted from these third party cookie restrictions.

Instead of making third-party cookies obsolete as is one of the exclaimed goals of the broader initiative, they turned it into an insidious and opaque tool that lets them increase their insight, influence, and control over the web and all its users even further.

This is bad for both advertisers and their prey alike.

Addendum: Getting rid of third-party cookies whilst not breaking Single Sign-On and similar such features could also have been achieved with a user-controlled local browser setting and a new type of permission request popup.

The need for Google to be in control of this is non-existent and the people working there are more than smart enough to understand this. They are playing us all here.

> with a user-controlled local browser setting and a new type of permission request popup.

Settings and pop ups mean that users have to understand them - which can be a huge user education challenge. I'm pretty skeptical of the argument that it's simple to add in a new user facing pop up and have the majority of users use it correctly.

I made no such argument regarding simplicity.

Nevertheless: even if a solution turns out to be too difficult for users to understand no matter how you present it (at which point you might want to rethink whether this apparently fundamentally flawed idea should even be implemented at all), violating your users' agency by taking the reigns and obfuscating the whole thing to them is morally wrong and in simple terms: an arsehole move.

If the user is perpetually confused using 'show all popups' Chrome, why wouldn't they switch to another browser that does that anyways?

I agree with you, but SSO is also not that seamless in practice and requires user education on which sites they use it with which ID.

I'd see a browser side system that could actually more user friendly and more unified than the current SSO situation.

Can't there be a setting to allow that setting / experience?

> self-appointed gatekeeper Judge Google (Judge Dread) takes requests from website owners for lists of domains they control

More specifically, website owners populate /.well-known/first-party-sets.json for their site and Chrome will always allow those cookies.

I don't think so? It looks to me like you also need to follow https://github.com/GoogleChrome/first-party-sets/blob/main/F... and get your sites onto https://github.com/GoogleChrome/first-party-sets/blob/main/f...

The FPS spec as described looks entirely duplicable by others and openly reimplementable by just cloning the FPS repo and following the same spec (which is open). Someone could choose in their browser to use a different set or a different repo or some hierarchical structure.

Because domain owners use /.well-known/first-party-sets.json, others can also scan for that themselves and perhaps build an independent repo from spidering.

Doesn't part of this update also make fingerprinting users even more robust with webGPU? Aka you don't need cookies because we can see who you are without them based on your machines unique specs

> they turned it into an insidious and opaque tool that lets them increase their insight, influence, and control

Sounds like most of the laws passed in my lifetime

Google- we've got your privacy

Literally. Lol.

WebGPU! Wohoo. I'm tracking the increase in availability of WebGPU across the web here: https://twitter.com/benhouston3d/status/1653865357080248321

Are you aware of any examples/demos of onnxruntime-web using the WebGPU backend that was merged but not yet released for v1.15?

Any updates on adding integrity checking to the script? Makes it a bit worrisome to embed it on sites otherwise.

Check the homepage: https://web3dsurvey.com

Instead of direct JavaScript includes I now recommend just putting it in an iframe and I share example code on the homepage.

This lets me still update the script while also ensuring it can not access cookies or other things in the main page context.

What do you think?

The point of the integrity hash is to be able to include a remote resource after reviewing and verifying it, and then being sure it doesn't change to do other things automagically, that you haven't reviewed before it runs on your users browser.

Wrapping the script tag in a iframe does not accomplish this as far as I can tell.

Right. But the main attack vector of a raw JavaScript include into the main page is that it can access anything you are doing in that page include logins or secrets or cookies or other private data. Moving it into an iframe sandboxes it and reduces the majority of nefarious things it can do. Especially if it is running off of web3dsurvey in the iframe and not the host website origin - thus a bunch of cross origin protections kick in.

So the iframe sandbox deals with the security issue is a different fashion.

Also the iframe can not block the main pages so it has even less impact on the main page experience.

This is as secure now as the majority of ads served on the web.

That sounds like a fun new fingerprinting attack surface.

---

EDIT: That might have been too cynical. Let me take another stab:

That opens up some cool new possibilities, but also a seemingly large new attack surface.

Does anyone know what's been done to mitigate it?

To partially answer my own question, some of the risks are identified here: https://www.w3.org/TR/webgpu/#malicious-use

The mitigations, however, feel rather light given the exposure.

The alternative would be to ask for explicit permission per website, similar to notifications or webcam access. Sounds like overkill to me.

Malicious/non-informed cryptocurrency mining in a background tab also comes to mind.

Would it make sense for GPU access to be a permission that users have to explicitly grant?

Surely that's how it's implemented? I want nothing to do with websites fuzzing that mountain of (driver) code that sits behind shaders & co.

I’ve been able to run some demos without any prompt, and WebGL has always worked like that (and exposes compute shaders too, I think?)

Also another GPU driver attack vector.

I'm also excited about WebGPU!

What's going on with Chrome and their seeming push for advertising this week?

They've restarted actively advertising their browser on Youtube, and now random releases are getting to #1 slot on HN.

I'm guessing this is having to do with Edge gaining popularity?

If you look at historical submissions from chrome.com you'll find that Chrome 112 and Chrome 111 release posts are submitted to HN as well. The fact that this submission was near the top probably reflected people's excitement over WebGPU.

I think you're probably right. For example, we're no longer recommending that Windows users to download chrome since Window's default browser (Edge) is fine now... so I'm sure edge popularity is taking away a lot of marketshare from Chrome. Not to mention the news this week of Safari surpassing Edge in popularity. Either way it's clear there is competition and Google is a little afraid.

Google makes 50% of their revenue from Google Search.

Google can only funnel people to Google Search with Chrome and first party Android. If Chrome falls, they're in a precarious position.

Google is being IBMified right now.

I'm not sure I understand the "Override network response headers" feature.

Haven't the responses already been handled? Assuming no time travel, it's not clear what actually happens after you edit a response header.

Javascript and the browser use the response headers. The example they gave is overriding CORS. Let say you're running code locally and using remote APIs. Now you can override CORS to allow your local code to still call the APIs.

That's incredibly useful! Dev and staging environment setup involves proxies, SSL, CORS, etc., and can be a total nightmare.

If they integrate request header modification, we can get rid of cookie tools and plugins such as ModHeaders.

This is a really great dev experience improvement.

It's an override, so I imagine future requests will follow the header changes you institute. Now all we need is response editing to really integrate burp/mitmproxy-esque response hacking.

We already have response editing. You can save a file in devtools and set up workspace folders to override responses at any url.

This is an improvement to that feature which allows you to modify the response headers in addition to the response body.

That’s only for GET requests, isn’t it?

The 'Chrome 113 deprecations and removals' link in the 'Further reading' section leads to an error page:

https://developer.chrome.com/blog/deps-rems-113/

Does that mean there are no changes here?

I appreciate all the concern everyone has with third party cookies with respect to privacy but this really kills the use case of third party embedded web apps. Saleforce ecosystem is going to take a real hit as a result of this change. Hopefully everyone will figure out away to implement First Party Sets quickly and Saleforce will be able to offer a solution.

Still no sign of any initiative to declare that you do not give consent to use your page's contents as a training set for ML models. Yet the overcomplication of web standards is ongoing with light speed. Whats next, another color space coordination system after rgb, hls, lab, oklab, oklch??

Ridiculous.

>First-Party Sets (FPS) is starting to roll out to stable. First Party Sets is part of the Privacy Sandbox. It is a way for organizations to declare relationships among sites, so that browsers allow limited third-party cookie access for specific purposes.

Am I correct in my understanding that this basically undermines a user's choice to block third party cookies? Because a third party cookie is a third party cookie no matter how much icing you dump on it.

I hope this is an option that can be disabled or is separate from the current blocking of all third party cookies.

First party sets are a centralized list of sites that act as one logical site. The list is gated by the browser vendor. Details here (https://github.com/GoogleChrome/first-party-sets/blob/main/F...).

This is intended to deal with several technical challenges (https://github.com/WICG/first-party-sets#use-cases), such as the technical challenge that when company A buys company B, the process of fusing the auth rules so that being logged into A implies a login to B is a colossal nightmare project under first-party-only rules. So, for example, this lets Facebook declare that instagram.com is in the same FPS as facebook.com to simplify the auth story. What it should not allow is for joe-random-domain.com to declare that the DoubleClick ad endpoints are first-party to them.

> What it should not allow is for joe-random-domain.com to declare that the DoubleClick ad endpoints are first-party to them.

But it lets Google declare that doubleclick is part of them.

You mean the company that's been part of Google for near 20 years?

Like I don't like tracking either, but this is kind of the point of the first party thing. They're clearly the same party.

I do. This now means that double-click can treat my google.com cookies as first party cookies whwther I as a user want them to or not. I know that's the intention, and I'm not ok with that.

What tracking capability do you think treating DoubleClick cookies as first party on Google sites gives Google that they don't already have by just combining the logs from visits to google.com, youtube.com, etc., since all of those logs are stored in the same data warehouse and can be cross-compared?

doubleclick is part of them.

There are already reasonable ways to proactively or unproactively copy session-cookies from one domain to another one that shares a backend. What does this solve except saving a roundtrip when you visit google.co.kr?

[I work at Google, not on chrome, I don't have any particular insight into this feature].

From poking at https://github.com/GoogleChrome/first-party-sets/blob/main/F..., it looks like at a minimum, a given domain can only belong to one FPS, and needs to be preregistered publicly.

That makes the opportunities for abuse much more limited. And the "service-domains" (intended for things like auth or CDN that want to be isolated) have some reasonably strict automated checks (github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md#subset-level-technical-validation), while you're limited to 3 "associated" domains.

Abuse is subjective. Outside of Google, the general sentiment is that Chrome treating doubleclick.com as a first party to anything other than doubleclick.com is abusive.

Couldn't Google easily achieve the same by just moving their ads to doubleclick.google.com?

That would allow them to share doubleclick cookies across all subdomains of google.com. This FPS feature will allow them to share doubleclick cookies (or whichever cookies) across any domains that they choose to group into a "set." So regardless of whether you selected the "block third party cookies" setting, Chrome now ships with an internal list of domain groups for which it will ignore that setting.

Right as the parent mentions, it only allows grouping among sites that are logically owned by the same entity anyway, if someone wanted to make this work with first-party cookies, they could redirect from myapplication.com to myapplication.owning-party.com (which is what google does with gmail.com -> mail.google.com today)

This just allows you to do that while maintaining security boundaries around things like user generated content (e.g. facebook.com vs. fbcdn.net).

This doesn't allow some random site that uses third party ads to allow doubleclick cookie access, or vice versa.

^ This was my understanding too, so if it's wrong I'd like to know why! (The parent post is downvoted as of this posting.)

Can Chrome 113 give me a user-toggle to turn off the new annoying-ass daily New Tab Promo bullshit? I don't want to have to bury into the enterprise policies to turn that off.

(New Tab Promos are the stupid one-line blurbs that come up under your website list on the new tab page that "you won't see THIS SPECIFIC message again" when you dismiss. Please respect my decisions, I should be able to say "I don't want to see these at all".)

At least in iOS chrome, 113 brings with it a "fix" to the bookmark sync problem [1] they themselves recently created with the the cap on mobile bookmark sync raised to that of desktop chrome (100,000 bookmarks up from 20,000!)

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=134746...

edit: correct URL

I was one of first the "insane number of bookmarks" users on the thread after they quietly pushed this change out:

https://bugs.chromium.org/p/chromium/issues/detail?id=134746...

What still galls me is that instead of doing the right and reasonable thing and making a feature flag (and adding some indication that you're over their arbitrary limit) they did the bare minimum possible short of nothing at all, replacing one arbitrary mobile limit with the arbitrary desktop limit. And their communications on this? tumbleweeds pass by...

This still hasn't dropped for Android so there's no way to test it out fully yet, and if you're a user with over 100K bookmarks? Too bad, so sad, apparently.

It's a reason to look for alternatives. If no one there has 100,000+ bookmarks, they can't understand their users and problem domain that well.

Once Android chrome is out with the update, I'll start looking at other browsers and bookmark options.

So, if I'm using Chrome and I can't log out of my Google account any more, does that mean that site-owners are incentivized to use Google-based tracking? Because if they add Google-based tracking to their first party, it could use the data of my logged-in session of my Google account. What am I missing? This doesn't seem as if this should be possible.

So can you now just mine crypto in a pool by going to a site?

I keep hoping something will show up that'd make it possible to do a proper DHT in js.

>WebGPU is here.

>Can not create WebGPU Device and/or context.

Oh well.

What about the masonry layout?

Reply on news.ycombinator.com