Of course they haven't what?

> "this is not really true" and "all chrome-only proprietary APIs were dropped"

First of all, that's insane, but secondly, no one is even claiming the latter. It's easy to make up things all day. Say something connected to reality.

2. Someone who was wondering whether I'd made a huge mistake by moving stuff there a year or two ago and whether I should know something about the folks behind it that would indicate that I should reverse that decision, not support it, and not recommend it (alternatively: advise against) in the future.

1. What can you point to that explains or even suggests that repos "should [...] be findable" directly on codeberg.org and for "people browsing [it] and pages within"? E.g. that creating an unlisted repo and then setting up a publicly facing project landing page/mailing list/etc. that independently refers potential contributors to the repo but doesn't make available a top-level index of all such (possibly unrelated) repos that a given person controls, is something that would run afoul of either Codeberg's policies or goals.

2. What is your relationship to the Codeberg e.V. organization?

It would be nice to also disable the public listing of repositories for your profile page and to control it for organizations, too. (Not talking about private repos. Instead: these should be ordinary repos that remain accessible to anyone who has the link, but they are simply not aggregated into a single unified list that's available to anyone who clicks over to the "Repositories" tab. Think of them like unlisted YouTube videos, except they are all unlisted by default, rather than having to specifically designate each one as being unlisted—although that would work, too, it's just not the way it should be implemented.)

This sleight of hand is not going to work.

> Literally not a standard shipped in Chrome, literally is something Chrome came up with and implemented on its own, literally only shipped in Chrome without any consensus or input from other browser implementers

... and literally hasn't gotten "someone to type up something that describes the Chromium implementation into the standard". Your choice to ignore this does not bode well for whether you should be taken seriously on matters of intellectual honesty.

The fact that other browser vendors have not been forced to implement it by now contradicts what you are arguing to be true.

All of the Chrome-proprietary APIs that shipped once upon a time in Chrome but were later removed from Chrome (incl. no remaining signs in subsequent draft standards) also contradicts it.

Does Chrome ship non-standard stuff? Yes. So has Gecko. Webkit, too. Has Mozilla in particular been forced to implement some things for no reason other than it because became unavoidable at some point after it started shipping in Chrome? Yes. Does the standardization process merely consist of Chrome doing whatever it wants and the eventual result is a new standard (with nobody else being able to influence this or contribute anything of their own)? No.

> And yet "no, this isn't true, this isn't how Chrome works at all".

Nice strawman. The moment where you resort to putting words in someone else's mouth is the moment you forfeit. Goodbye.

> This is 100% true.

It literally is not, unless you think 100% means "less than 100%".

But IEEE 754 doubles have a significand that supports a 53-bit range. What am I missing?

An acceptable response, then (to both you and the original commenter), follows: "While some particular browser version doesn't currently protect individuals from that proposed form of tracking, any browser vendor could trivially start thwarting that form of tracking by exploiting the latitude afforded to UAs by the semantics of these headers." And that's the form that the previous comment takes and how it should be understood. The fact that "users go to the web with the browser they've been given [i.e., today, and which isn't providing this sort of tracking protection]" doesn't change anything; we are explicitly talking about steps that each side _can_ take in the arms race related to the subject of this discussion...

If I fetch your /foo.html today in November 2022, and you send me a last-modified from 1978, that gives me and my UA a huge range from which to select a different datetime (anywhere between the 1978 value and now-ish) on my next request. How are you going to correlate my original and subsequent requests if in the latter I ask if you've got a copy that's been modified since 1999?

Do they? Ten years ago Walmart distribution center workers were making what the writer says he made at Amazon, which is itself surely the result of recent increases. No idea what Walmart pays today, especially in these post COVID-induced work and price changes. Four or five years ago, on the other hand, I'd heard Amazon was around $13 to $14.