pwdisswordfish0

> Of course they haven't.

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.

1. Dodging the question with non-answers that conflate unlisted repos and better account privacy settings with the stuff that is known to be forbidden on Codeberg does no one any favors. It is no surprise that repos for non-free software and private repos for general use are not allowed. Where is the part that's relevant to what was asked?

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.

I've read that. It doesn't say or even suggest anything like what we're actually talking about here. Someone pointing to those terms in the TOS is either confused about what this discussion is about, confused about what exactly the TOS is addressing, or both.

Two questions:

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 took a long time, but GitHub has finally (thankfully) shipped privacy settings that allow you to disable the way it broadcasts/publicizes your every move on your profile page. Does Codeberg or Gitea allow this yet? (They really should have been the first to do so...)

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.)

> You "counterpoint" isn't even a counterpoint, but just reinforces the original comment.

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.

I sometimes fear I shouldn’t play driving games too much, so that I don’t get desensitised against those intrusive thoughts I sometimes get on the road. I wonder how irrational that actually is, because it feels like pretty much the same thing as your idea. I mean it doesn’t seem far fetched that a very realistic VR driving simulation with subtly “easier” physics might make you a worse driver in reality. More closely related to the fear of heights, we also jump from greater heights in video games than we would in real life, and much more frequently. I practically never have a reason to jump down from anywhere, so I could imagine making some wrong estimations when, after years of doing it in VR, I’m somehow faced with a real-life situation.

Sorry, try again. That's not how proof-by-contradiction works.

> This is 100% true.

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

This is not really true. Chrome's extensions to the Web platform comprising its Page Lifecycle APIs are coherent, well-reasoned, and valuable/inoffensive, yet other browsers have not implemented them (yet; but the proposed APIs are old enough now that if what you're saying were true it'd already be a done deal).

Mozilla has been behaving the way it's been heaving lately for the last 10 years.

That doesn't make any sense.

> 52 bits because of javascript

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

Context is important. The replied-to comment starts off, "While this particular implementation doesn't track individuals, couldn't your trivially start tracking individuals by[...]"

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...

Only if you disregard the amount of latitude that the semantics of these headers give to UAs that would effectively thwart this method of tracking.

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?