[HN Gopher] New in Chrome 113
___________________________________________________________________
New in Chrome 113
Author : feross
Score : 109 points
Date : 2023-05-03 19:47 UTC (3 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| bhouston wrote:
| WebGPU! Wohoo. I'm tracking the increase in availability of
| WebGPU across the web here:
| https://twitter.com/benhouston3d/status/1653865357080248321
| aigoochamna wrote:
| [flagged]
| arrow7000 wrote:
| Back in 2011
| runlevel1 wrote:
| 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?
| lxgr wrote:
| 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?
| stefan_ wrote:
| 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.
| sebazzz wrote:
| Also another GPU driver attack vector.
| cubefox wrote:
| I'm also excited about WebGPU!
| runlevel1 wrote:
| 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.
| MuffinFlavored wrote:
| Are you aware of any examples/demos of onnxruntime-web using
| the WebGPU backend that was merged but not yet released for
| v1.15?
| nikeee wrote:
| 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.
| slowhadoken wrote:
| [flagged]
| smt88 wrote:
| What value does your comment have? Do you want people to just
| pile on to this woman who is trying to speak another language?
|
| I grew up in one of the whitest states in the country and have
| no trouble understanding her. Her accent is strong, but she's
| not like a spokesperson or actress. She actually works at
| Google and has subject matter knowledge that's relevant to this
| video.
| KeplerBoy wrote:
| Because she's a developer relationship engineer and that's her
| job.
|
| English is not my first language and i have no problem
| understanding her. get over it.
| high_priest wrote:
| I agree with the OP. The tolerance and promotion of
| imperfection has been devaluing useful content at an
| exponential rate. I see more and more comments under old
| engineering videos "I miss how not only descriptive and
| concise, but easy to understand are these materials. I miss
| the good old days".
| Dalewyn wrote:
| >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.
| joshuamorton wrote:
| [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.
| kokanee wrote:
| 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.
| Wowfunhappy wrote:
| Couldn't Google easily achieve the same by just moving
| their ads to doubleclick.google.com?
| kokanee wrote:
| 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.
| Wowfunhappy wrote:
| But aren't those groups of domains that are controlled by
| the same entity? That means they are domains that could
| be merged anyway.
| shadowgovt wrote:
| 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.
| GauntletWizard wrote:
| 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?
| maccard wrote:
| > 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.
| [deleted]
| cj wrote:
| 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.
| RowanH wrote:
| 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
| adrr wrote:
| 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.
| cj wrote:
| 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)
| svachalek wrote:
| 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.
| nr2x wrote:
| Blame the Irish.
| MichaelZuo wrote:
| 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?
| ripley12 wrote:
| 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.
| judge2020 wrote:
| 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.
| petemill wrote:
| We already have response editing. You can save a file in
| devtools and set up workspace folders to override responses
| at any url.
| jbroman wrote:
| This is an improvement to that feature which allows you to
| modify the response headers in addition to the response
| body.
| adrr wrote:
| 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.
| echelon wrote:
| 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.
| VHRanger wrote:
| 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?
| echelon wrote:
| 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.
| kccqzy wrote:
| 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.
| bonestamp2 wrote:
| 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.
| krono wrote:
| 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.
| paulddraper wrote:
| > 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.
| ozaark wrote:
| 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
| dagenix wrote:
| > 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.
| makeitdouble wrote:
| 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.
| krono wrote:
| 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.
| MichaelZuo wrote:
| If the user is perpetually confused, why wouldn't they
| switch to another browser that does that anyways?
| [deleted]
| Xeoncross wrote:
| > 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
| renewiltord wrote:
| 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.
| VWWHFSfQ wrote:
| 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.
| zagrebian wrote:
| 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.
| nr2x wrote:
| Yup.
| NoMoreNicksLeft wrote:
| I keep hoping something will show up that'd make it possible to
| do a proper DHT in js.
___________________________________________________________________
(page generated 2023-05-03 23:00 UTC)