[HN Gopher] New in Chrome 115
___________________________________________________________________
New in Chrome 115
Author : feross
Score : 49 points
Date : 2023-07-13 18:17 UTC (4 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| billyhoffman wrote:
| So they created a new event so people can use JS to create
| "reading indicators which move as you scroll." You know what else
| can do that? Scroll bars. In the browser. That don't disappear.
| Those tell you how far you are in the document as well.
| eyelidlessness wrote:
| There are already JS solutions for scroll-based behaviors and
| styling (the actual scroll event, IntersectionObserver which
| performs better because it's non-blocking and batched).
|
| Scroll Timeline is a CSS-only solution. And it's kind of a
| misnomer, it's really a position-based styling mechanism that
| can be used without any scrolling at all[1].
|
| At minimum, this API will allow existing functionality that
| relies on scroll position to perform better (first by
| integrating with the rest of the CSS-paint pipeline, next IIUC
| by offloading to GPU where possible), which itself is welcome.
| But it also unlocks a bunch of other styling possibilities that
| are either impossible without JS or rather brittle.
|
| 1: https://kizu.dev/position-driven-styles/
| hbn wrote:
| It's hard to rely on the scrollbar if the website either loads
| the article as you scroll (I think Ars Technica does this) or
| you know whether or not there's a comments section. Or
| sometimes there is a comments section but it doesn't load until
| you scroll it into view.
|
| I find myself frequently jumping to the bottom of the article
| to see if the small scrollbar is due to the article length or a
| comments section.
| ComputerGuru wrote:
| I don't think the new scroll timeline fixes the lazy loading
| issue.
| wtallis wrote:
| Websites that are doing obviously wrong things shouldn't be
| used to justify another layer of bad features being added.
| There's never any justification for deferring loading of the
| rest of an article until you scroll. The _images_ , maybe,
| but definitely not the text.
| paulddraper wrote:
| > Fenced frames
|
| Okay, seems cool, but.... _why?_
|
| > With a fenced frame, the publisher could display an ad which
| matches visitor interests, but the src and interest group will be
| known only to the advertiser in the frame. The publisher could
| not access this information.
|
| Ah, okay there we go.
| andrewstuart wrote:
| When does webgpu come for Linux?
| pjmlp wrote:
| As per Khronos meeting yesterday, really soon now.
|
| So are the priorities of MountainView for desktop Linux, it is
| literally the last platform on Chrome roadmap support for
| WebGPU.
| [deleted]
| _boffin_ wrote:
| How will I be able to disable this? If it's not possible, I won't
| be upgrading.
| dphnx wrote:
| I'm not sure. There could be a setting or maybe something in
| chrome://flags, but purely on principle I'm voting with my feet
| and switching to Firefox.
| londons_explore wrote:
| > Fenced Frames
|
| Fenced frames seem to break the 3rd party cookie isolation that
| has become standard in web browsers.
|
| Sure, they put protections in place... But nothing stops the
| forums on shadysite.com putting a fenced frame to
| this34yearoldmalehasanipof1234andsessionidof7775.advertiser.com
|
| I predict that this move is worth multiple billions to Googles
| advertising team...
| tgv wrote:
| That plus "topics" makes for another great day to switch to
| Firefox or Safari.
| parhamn wrote:
| Anyone know if fenced frames honor the No frame header? No reason
| they should now, right?
| Link- wrote:
| > The Topics API enables interest-based advertising (IBA) without
| tracking the sites a user visits. The browser observes and
| records topics that appear to be of interest to the user, based
| on their browsing activity. This information is recorded on the
| user's device.
|
| > For example, the API might suggest the topic "Fiber & Textile
| Arts" for a user who visits the website knitting.example.
|
| Hmm.. That doesn't sound good.
| WORMS_EAT_WORMS wrote:
| I guess I don't understand how it is different or better from
| Google's perspective for its users.
|
| Is the main benefit you don't know the exact site you visited
| but the type of site and basically all the contents or "topics"
| of it?
|
| Not looking to flame. Genuinely looking for just the rundown
| explanation // privacy benefits // etc..
| GordonS wrote:
| I actually think something like the Topics API could work - but
| with some pretty big changes.
|
| Firstly, it's a "hell no" from me on my browser recording what
| I'm doing and insinuating my interests. At the very least, I'd
| want to be able to disable that.
|
| Secondly, I want to be able to see the topics that are chosen.
|
| Finally, I want to be able to edit/set these topics myself.
| candiddevmike wrote:
| If you can edit/set these, what's the point in having any of
| this? If they want to know your interests they could just ask
| and accept no as a valid answer. The iOS changes proved that
| people do not want to be tracked, I think.
| GordonS wrote:
| The point would be standardisation - you set preferences
| once in your browser, rather than on several sites in
| several different ways.
|
| FWIW, I too do not want to be tracked, and so I use an ad
| blocker etc. I'm thinking more along the lines of improving
| things for those that don't mind so much - those that
| accept the "deal" of ads in exchange for content.
| superfrank wrote:
| I know a lot of people don't like the Topics API and FLoC
| (which I believe is dead now, but was kind of the MVP for
| Topics) and I'm not saying it's perfect, but from everything
| I've read on it, it seems like a massive improvement over third
| party cookies.
|
| Am I wrong in thinking this way?
|
| I realize there are plenty of people out there who just don't
| want to be tracked at all, but I don't think that option was
| really ever on the table for Chrome users. To me this seems
| like a step in the right direction.
|
| If there's anyone who can explain the downsides of this new API
| and has an alternative other than "don't track me" I would
| honestly love to hear it. I'm sure there are some, but I'm
| struggling to think of them.
| VPenkov wrote:
| > To me this seems like a step in the right direction
|
| This implies that there are more steps in that direction.
|
| Can you think of any follow-up steps that are in favor of the
| user? Or do you think it's more realistic that advertisers
| regain their former superpowers?
|
| I don't mean to nitpick your phrasing, I'd like to understand
| if there's some long-term benefit to users that I don't see.
| candiddevmike wrote:
| Why have either? What _user_ wants this? I really struggle to
| find people that want to be tracked, even anonymously, that
| have no ties to said tracking companies.
| [deleted]
| notatoad wrote:
| do users want it? no. do users _not_ want it? also, for the
| most part, no. people don 't care about this nearly as much
| as you want them to.
|
| fully informed and knowledgeable people can make a decision
| that they don't really mind if advertisers know a bit about
| them. especially when it's as benign as knowing what
| general topics they might be interested in.
| TechBro8615 wrote:
| This reads like "only tell people who ask, exploit those
| we can get away with, and when they start to catch onto
| our schemes, obfuscate the system by adding new
| complexity and telling them it's for their own good, then
| repeat."
| superfrank wrote:
| > What _user_ wants this?
|
| You're asking the wrong question. Chrome users are the
| product not the customer. Google cares about Chrome users
| in the same way a farmers care about their cows that they
| are raising to be slaughtered.
|
| Asking Chrome users if they want to be tracked is like
| asking cows if they want to live their lives in a fenced in
| enclosure (or worse). It doesn't really matter what they
| want unless not doing what they want affects the bottom
| line (and even then, there are trade offs).
|
| The correct question to be asking is "Which of Google's
| customers (the people paying for ads) want this?" and the
| answers seems to be most, if not all, of them.
| tomComb wrote:
| I want to use internet services that have no paywall. I
| want them to get paid, with a minimum of ads. And I prefer
| ads that might be relevant to me, and which might provide
| value even for small advertisers (as opposed to brand
| advertising).
|
| That all requires data collection and that's ok with me as
| long as they handle it responsibly (oddly the ones that
| handle users data responsibly - never selling or leaking
| yet - seem to be the most hated).
|
| I have no ties to said tracking companies, or any other
| skin in this game.
| candiddevmike wrote:
| Do you think that ads will provide them with enough
| revenue? Based on the current status-quo, ad-supported
| only services seem to be waning. Businesses would much
| prefer paying customers vs ad-supported, I think.
| SllX wrote:
| If that's a choice you get to make without that choice
| being forced upon me because I clicked a link, great!
| We're both happy.
|
| I don't mind a consent wall, or a paywall, but what I do
| mind is that the second I click a link, the page is
| already trying to turn my user agent against me to glean
| as much information about me as possible.
| rurp wrote:
| It's fine if you want to opt into any tracking info you
| want. The issue is that it should be opt in and a clear
| choice, not obfuscated in the background or framed as if
| it's necessary for basic services to work.
| jsnell wrote:
| At least the EU [0], UK [1] and two different US government
| entities [2][3] have all made it clear that Chrome can't
| disable 3rd party cookies without a replacement that keeps
| (non-Google) ad networks competitive. The theory seems to
| be that it would be anti-competitive, because Google
| doesn't actually need either 3p cookies or a replacement
| mechanism while ad networks do.
|
| So unfortunately the "neither" choice is not an option
| here.
|
| [0] https://arstechnica.com/tech-policy/2021/06/eu-
| antitrust-reg...
|
| [1] https://www.gov.uk/government/news/cma-to-keep-close-
| eye-on-...
|
| [2] https://www.engadget.com/google-antitrust-doj-cookies-
| privac...
|
| [3] https://www.theverge.com/2021/3/16/22333848/google-
| antitrust...
| cma wrote:
| Chrome already lets you delete cookies or browse in
| incognito mode, wouldn't the same argument mean they
| couldn't provide that? Disabling third-party cookies
| could be a switch in the settings that the user chose,
| like those.
| xg15 wrote:
| I wonder how Topics could change that reasoning.
|
| The Topics API is intentionally much less capable than
| 3rd party cookies. So if Google phased out 3rd party
| cookies and replaced them with Topics, the abilities of
| non-google ad networks would already be curtailed.
| Meanwhile, the same restriction doesn't apply to Google
| as they can just have the browser track users in much the
| same way as 3rd party cookies used to do.
|
| So even _with_ Topics, there would be a power imbalance
| between Google and other ad networks.
| chrismorgan wrote:
| I'm not deeply familiar with things, but I don't _think_
| that stuff should be relevant: if Google is getting
| information that other ad networks can't (and I have no
| real idea about this), _that's_ a problem, and it's
| unfair advantage and anticompetitive behaviour even while
| third-party cookies are a thing--just perhaps less
| extreme than after third-party cookies are removed. But
| any probes then should be more along the lines of "why is
| google.com privileged" rather than "Google must add the
| Topics API before removing third-party cookies".
|
| Safari and Firefox already disabled third-party cookies a
| while back. There's no problem with _that_ , right?
| jsnell wrote:
| You entire premise is flawed since google.com is not
| privileged in this. It has exactly the same capabilities
| of setting first-party cookies as every domain.
|
| "But Apple's and Mozilla's moms let them disable third-
| party cookies" isn't likely to be a winning argument in
| court when the major Western competition authorities
| threatened you in advance with anti-trust action.
| rcme wrote:
| I think the argument is that disabling 3rd party cookies
| in Chrome would not be anti-competitive is Google didn't
| collect any information about Chrome users.
| xg15 wrote:
| As a matter of fact, Google domains do have (or at least
| used to have) privileged treatment in Chrome: There are
| special request headers that Chrome automatically
| includes in requests to Google-owned domains - and only
| those. [1]
|
| But even if not, Chrome makes all kinds of API calls to
| the Google backend, independently of browsing. It would
| be trivial to e.g. upload the browsing history there and
| associate it with the user's Google account.
|
| [1] https://www.theregister.com/2020/02/05/google_chrome_
| id_numb...
| chrismorgan wrote:
| If google.com _isn't_ using any privileged position (I
| was guessing they were, from your comment), then where's
| the problem? There's no antitrust: third-party cookies
| are a privacy problem, and the browser industry has
| unanimously decided to remove them, and in fact everyone
| else has already removed them--Google is _last_ here. The
| fact that one of the browser providers (and yes, maker of
| the biggest one) happens to be an advertising company
| _should_ then be irrelevant--either Google is simply
| doing things better than everyone else in the advertising
| industry, or they're behaving anticompetitively in some
| _other_ way. But I don't see how this could legitimately
| be tied to removing third-party cookies.
| jsnell wrote:
| Look, I really don't know what to say here.
|
| I agree that what you say _should_ be true. But it is
| not, and I 've already posted the sources to show it in
| my first message in the thread. Do you think the sources
| are fake? Or do you think that all those regulators are
| just joking around, and when Google does something they
| expressely forbid, it'll just be laughed off?
| summerlight wrote:
| And surprising to many ordinary HN readers, it is actually
| better for Google to deprecate 3p cookie as early as possible
| since the digital ads market competes on finite budget and
| whenever something uncertain happens it almost always works
| in a way that benefits big, established players. Of course
| other small players definitely understand this and has
| approached to competition regulation entities so Google
| cannot simply get rid of 3rd party cookies and kick the
| ladder... Advertising is an extremely optimized business
| sector and its landscape is not that simple; no one is going
| to get everything they want.
| TechBro8615 wrote:
| Do you work at Google? The reason I ask is because I fail to
| understand how the premise of "topics" or "floc," or whatever
| you want to call it, benefits anyone other than Google
| shareholders and employees. Browsers don't need to be
| advertising machines, and the idea that somehow ads need to
| "work" or be "private enough" is a false premise that only
| exists because Google depends on tracking users so they can
| extract maximum prices from advertisers.
|
| The problem is not that there's a "downside" to the feature -
| the problem is that it exists at all.
| Natuerich wrote:
| While Google does has an interest in people having a secure
| tool to use their services, the fundamental way Google is
| as accessable to everyone as it is is because of ads
|
| It's shitty.
|
| Now Google makes this shitty existing architecture better.
|
| At least I agree to the op and think this is better.
| superfrank wrote:
| I don't work at Google and never have. I'm just being
| realistic.
|
| Companies don't make products out of the goodness of their
| hearts, they create products to make money. I'm not saying
| that's good or right, but that's just how the world is.
|
| Google makes money off advertising and advertisers want to
| be able to target certain audiences. It's important to
| remember that you and I are not Google's customer in this
| case. We are the product. Advertisers are the customer.
| Google is going to give advertisers *something* to be able
| to target ads toward certain audiences because that's what
| Google's customers want and that's what they will pay for.
| If Google doesn't give that to them, they will take their
| business else where. We (Chrome users) have some say in the
| direction of the product because there's always the threat
| that Chrome users will leave en masse, but for the most
| part, our wants are secondary to the wants of the people
| who are directly giving Google money.
|
| My comment is starting from the following assumption - We
| don't get a choice in this matter and some feature for
| targeted advertising is going to exist. So my question is,
| are there any ways in which this is worse than the current
| solution (third party cookies) or are there any other
| alternatives that would provide Google's customers
| (advertisers) with similar features that are invasive to
| Chrome users.
| TechBro8615 wrote:
| Ok, so what is the product in the case of Google? As a
| user I've been led to believe the product is Google
| Chrome, a web browser that can browse the open internet.
| But it seems like in Google's mind, the product is my
| attention, which they sell to advertisers on behalf of
| publishers who insert tracking code (ads) on their sites.
| So in effect, the previously open internet becomes a
| product belonging to Google, where every site with
| adsense on it may as well be a Google property, in the
| sense that it's Google who is the ultimate benefactor of
| the fact that I viewed multiple sites in its "network."
|
| This is a fine argument when talking about walled gardens
| like Facebook (setting aside for a second the issue of FB
| tracking pixels) - the entire site _is_ their property,
| and it 's their right to track me within it. But what
| rubs me the wrong way about Google adding tracking
| features to Chrome, is that they're exploiting an open
| platform to essentially turn it into a giant walled
| garden. And many publishers wouldn't necessarily be okay
| with this, in the sense that they're helping their
| competitors by leaking tracking data that ultimately
| leads to higher priced ads on those competing websites.
| But they don't have a choice because Google has an
| advertising monopoly.
|
| The root problem is that the leading browser is developed
| by the leading advertising company, even though there's
| no fundamental reason for the two products to be so
| closely coupled. As a result, malign incentives leak into
| the product development because unlike other browsers
| from companies not supported by ads, which have removed
| third party cookies with no adverse consequences, Chrome
| cannot do the same without hurting their parent business.
| But note how fundamentally this has no impact on the
| browser itself - the conundrum is an artifact of who
| develops the browser.
|
| In an ideal world, a web browser would be a piece of
| software thats either bundled with my operating system
| and subsidized by hardware sales of the manufacturer (as
| is the case with Safari and Apple), or if I wanted an
| alternative, an application that I could purchase with a
| one time payment or even a recurring fee. I would happily
| support the development of the product by paying for it,
| as I do with many products. But it's a false dichotomy to
| suggest that's what the Chromium tracking code is doing -
| it's supporting the Google monopoly, which extends far
| beyond just Chrome. If Google were simply a company that
| offered a web browser, then none of this would be an
| issue - third party cookies would be gone and there would
| be no need to add any tracking code, because removing the
| cookies didn't do any material harm to their business.
| But alas that's not the case, and we the users are left
| holding the bag and paying for it by letting Google and
| advertisers follow us around the internet.
| drekipus wrote:
| * * *
| peter422 wrote:
| I don't work at Google and don't use ad blockers because I
| want the sites I visit to get paid.
|
| Anyways, all things being equal, I'd prefer more relevant
| ads.
| type0 wrote:
| How about getting malware through ad networks?
| userbinator wrote:
| Drink verification can.
| chrismorgan wrote:
| "Topics API or third-party cookies" kinda goes beyond being a
| false dichotomy to being a blatant lie. The conflict of
| interest demonstrates how Google is unfit as the custodian of
| a leading browser. This is a single-vendor thing to bolster
| their own interests and which they can only do because
| they're a leading advertising company, and which no one else
| supports in any way.
|
| Firefox and Safari have already stopped supporting third-
| party cookies, and nothing bad happened.
|
| (There are a few cases here and there of legitimate systems
| breaking due to relying on third-party cookies for things
| like login, and these _have_ broken in Firefox and Safari,
| but they'll break in Chromium too when it kills off third-
| party cookies, and the Topics API is completely irrelevant to
| these cases, being exclusively about advertising interests,
| so these cases aren't part of the "third-party cookies or
| Topics API" deceit.)
|
| Note also how Apple and Mozilla have both taken negative
| positions on the Topics API: it's extremely unlikely either's
| browser engine will ever support it, making the falseness of
| the dichotomy even clearer.
|
| Useful further reading, identifying various concrete problems
| with the Topics API (if "but why should it even exist at
| all?" wasn't enough):
|
| https://github.com/WebKit/standards-positions/issues/111
|
| https://github.com/mozilla/standards-positions/issues/622
|
| https://github.com/w3ctag/design-reviews/issues/726
| superfrank wrote:
| > "Topics API or third-party cookies" kinda goes beyond
| being a false dichotomy to being a blatant lie.
|
| From my original post:
|
| > If there's anyone who [...] has an alternative other than
| "don't track me" I would honestly love to hear it. I'm sure
| there are some, but I'm struggling to think of them.
|
| Not only did I never say that the only options were "Topics
| API or third-party cookies", I explicitly said that I'm
| sure there were other options, but that I just didn't know
| what they were.
| SllX wrote:
| > If there's anyone who can explain the downsides of this new
| API and has an alternative other than "don't track me" I
| would honestly love to hear it.
|
| "Don't track me" should be sufficient.
| dahwolf wrote:
| The alternative is context-sensitive ads based on surrounding
| context.
| sourthyme wrote:
| Yeah I want to know what my topics are and when they change,
| and if I can disable or fudge my topics.
| eis wrote:
| There is an internal page chrome://topics-internals where you
| can see the topics but I don't think you can fudge them
|
| https://developer.chrome.com/docs/privacy-
| sandbox/topics/#ob...
| hbn wrote:
| You'd figure it would be a pretty easy thing for a fork to
| just... not implement?
|
| I'll assume they won't be so polite as to allow extension to
| disable this "feature"
| madeofpalk wrote:
| Just as easy for any browser to just not implement third
| party cookies.
| eli wrote:
| Not sure if it landed yet, but being able to edit/disable
| individual topics was an announced feature.
|
| FWIW most ad networks already let you do this. Here's
| google's https://myadcenter.google.com/home
| davidjade wrote:
| From the FAQ:
|
| Why can't I block sensitive topics entirely?
|
| We'll do our best not to show you ads about the topics you
| limit. In some cases, you might still see an ad containing
| images related to the topic you've limited. For example,
| you might see an airline ad featuring someone holding a
| glass of champagne. This isn't an alcohol ad, even though
| the ad shows alcohol.
|
| In other cases, you might still see an ad about a topic
| you've limited if you search for info about one of those
| topics or you watch a video related to those topics.
|
| So I can make suggestions to Google for ads but not truly
| disable topics.
| jawns wrote:
| A few years ago, I worked for a company that helped retailers
| infer user intent. And you would not believe the lengths that
| they would go to to infer simple things like sex (for clothing
| sites with male and female sections). I kept saying, "Wouldn't
| it be great if, you know, we just asked people?" And everyone
| said, "Oh, no, people are never going to volunteer that. They
| want privacy!"
|
| So, great, now we get a Topics API to help advertisers extract
| this info involuntarily.
|
| But without a Shopping API or similar method of volunteering
| info that's actually useful and makes my browsing experience
| easier, I have to re-apply the same filters incessantly on
| every online shopping site I visit, even though I really don't
| care if anyone knows that I'm a Men's Large with a 36-inch
| waist.
| ssss11 wrote:
| Yeah you're right - just ask the user. They can say no, or
| they can tell you what you want to know. I think companies
| know that most ppl don't want to hand over info.
|
| This current opaque adtech system coupled with dark pattern
| 'options' to appear like they care is insulting and arrogant.
| 98codes wrote:
| It's like Google is trying to give the government evidence of
| browser / ad vendor bundling effects
| kgwxd wrote:
| At this point, I wouldn't be surprised if they announce the
| "User-Agent" request header will be "Google-Agent" going
| forward.
| sixothree wrote:
| Yeah. That's sounds icky and gross.
| marginalia_nu wrote:
| Dunno, seems useful.
|
| Build a zero effort dmoz by visiting individual sites with a
| clean headless browser and then querying the topic API.
| paulddraper wrote:
| Please elaborate? It seems a terrific idea.
| Aardwolf wrote:
| > For example you can create reading indicators which move as you
| scroll:
|
| You know, scroll bars used to do that. Why are they not shown, or
| if shown extremely thin, on mobile devices?
| dvt wrote:
| Fenced frames seem so over-engineered. Why not just add a
| `fenced` attribute to a regular `iframe` which we can toggle on
| or off? Looking at the Chromium source, the `fenced_frame.cc`
| implementation is almost literally copy-pasted from `iframe`
| anyway.
| [deleted]
___________________________________________________________________
(page generated 2023-07-13 23:02 UTC)