They're doing a lot more than scanning for "compromised or misleading extensions"; there are a lot of scummy/spammy extensions on the list, but among the extensions included in the list of those they probe are also extensions such as:
- "Highlight multiple keywords in a web page", an extension that re-implements the equivalent Firefox's "Highlight All" findbar button in Chrome—and happens to mention LinkedIn in the description when describing one use case <https://chromewebstore.google.com/detail/ngkkfkfmnclhjlaofbh...>
- "Delayed gratification Research", a study/focus extension created "for OS semester at CODE University of Applied Sciences" to "Temporarily Block distracting websites"—with all of 4 active users <https://chromewebstore.google.com/detail/mmibdgeegkhehbbadeb...>
It's pretty clear that LinkedIn, like many website operators, don't think of themselves as a source of information that it will send to your UA upon request. It's not even just that they want total visibility into your habits like the worst of the advertising/tracking companies. What they want is as control as they can manage to wrangle over the experience of what it's like when you're "on" their site (i.e. looking at something on your computer that came from their site)—not least of all so they can upsell their userbase on premium features. LinkedIn doesn't care so much that people are inundating other users/orgs that might not appreciate that they're being treated as a "lead", so much as LinkedIn cares that the people doing the inundating are doing it with tools where LinkedIn wasn't able to get a cut.
> PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages.
The solution is not moar toolz. That's the problem—this crazy mindset that the problems endemic to bad tooling have a solution in the form of complementing them with another layer, rather than fewer.
Git and every sane SCM already allow you to manage your source tree without jumping through a bunch of hoops to go along with wacky overlay version control systems like the one that the npmjs.com crew designed, centering around package.json as a way to do an end-run around Git. You don't need to install and deploy anything containing never-before-seen updates just because the NodeJS influencer–developers say that lockfiles are the Right Way to do things. (It's not.)
Opting in to being vulnerable to supply chain attacks is a choice.
This comment highlights a basic dilemma about how and where to spend your time.
Here's a basic rule of thumb I recommend people apply when it comes to these sorts of long, contentious threads where you know that not every person showing up to the conversation is limiting themselves to commenting about things they understand and that involve some of the most tortured motivated reasoning about legal topics:
If the topic is copyright and someone who is speaking authoritatively has just used the words "copy written", then ignore them. Consider whether you need to be anywhere in the conversation at all, even as a purely passive observer. Think about all the things you can do instead of wasting your time here, where the stakes for participation are so low because nothing that is said here really matters. Go do something productive.
Yet you still wasted your own time and everyone else’s time with a reply that has even less substance.
I was making an argument based on quotes from the actual legal code and you’re saying pions who don’t use the exact correct terminology shouldn’t even consider what should or shouldn’t be legal? What a load of junk. This is a democracy. We’re supposed to be engaging with it.
LibreOffice needs to pull their heads out of the sand and recognize that both OOXML and ODF are the past.
Make it a polyglot ZIP à la SingleFileZ if you have to (or polyglot JSON[1] or just straight up XHTML with a big sidecar blob of embedded metadata), but nothing trying to take on Microsoft Office is "the future" if it's trying to get there with a strategy shackled to the notion of people downloading the appropriate format-compatible software for something as simple as being able to view (not even edit!) the document that has been sent to them.
It's great to have open standards and free software, but be compatible by default with the universal formats understood by the readers for the ubiquitous document infrastructure that everyone already has installed (WHATWG-/W3C-compatible hypertext readers, i.e. Web browsers), or be forever doomed to the same level of obscurity that OpenOffice/LibreOffice were fated 10–15 years ago due to their myopia.
> A forward-looking format is one that reduces future dependency, not one that reinforces it[…] A “backward-looking” format, by contrast, is one that ties the future to the commercial strategies of a single vendor. In this sense, OOXML Transitional is an archaeological artefact that preserves the past at the expense of the future.
This is delusional. As long as it's modeled on the same outdated paradigm of 80s- and 90s-style office suites (no matter which one), then any format whether it's an ISO standard or not is hopelessly attempting to preserve the past.
> Even today, web formats cannot render documents with the same fidelity as ODF. Especially not for spreadsheets.
That's a nonsense claim—literally a category error. You're conflating the limitations of what can be represented in a given file format with an implementation's (lack of) support for doing things encoded in that format.
LibreOffice doesn't render documents encoded in plain-text, browser-compatible formats with the same fidelity as ODF because LibreOffice has not implemented encoding documents in plain-text, browser-compatible formats that it renders with the same fidelity as ODF.
There is nothing in ODF that's inherently unrepresentable in JSON or pure XML.
If you try to print any non-trivial Web page with any of the existing Web browsers, all of them will print different things and none of them will print the same thing that they render on the computer display. For all of them the printed files will have various obvious defects, caused by incorrect size ratios between various elements or by an incorrect stacking of the elements, so that some of them obscure others that should have been visible.
For instance, Firefox and Chrome almost always print garbage, while Vivaldi is typically much better, but it also fails from time to time. It looks like all those who maintain Web browsers only test how pages are rendered on displays, but they never test how they are rendered by a print command.
With a file format intended for documents, the first property that I demand is that the document will be rendered perfectly in a deterministic way and it will look absolutely the same regardless on what medium it is rendered.
Nothing could be less true for anything that is used on the Web.
I strongly hate anyone who provides documentation in the form of Web pages, instead of using real documents, e.g. PDF files, ODF files or even Microsoft Office files, which can be used offline without problems. Nowadays, even the attempt to save Web pages in browsers is unreliable, due to the embedded scripts that may fail to work offline, making impossible the rendering of the saved pages.
> I am not sure what you claim about web formats.¶ If you try to print any non-trivial Web page with any of the existing Web browsers[…] For instance, Firefox and Chrome[…]
... why do you think this matters? Like, at all? We're talking about LibreOffice.
> Nothing could be less true for anything that is used on the Web.
This is, uh, crazy. In the first place, PDF is used on the Web, and it's both better suited for print-perfect sources and it's more portable. In the second place, believing that there's some magic inside ODF (or some other office suite's native format) that can't be represented in XML, JSON, or some other plain-text format is delusional.
If you claim that some text format used on the Web is suitable for storing a document, you should be able to point to some application that demonstrates the use of that text format in a manner that can be used for a document.
If none of the existing Web browsers can render a Web page in a predictable way in all circumstances, that clearly disqualifies all "Web formats". If the most complex programs like the Web browsers cannot always render correctly a Web page, then who can?
> There is nothing in ODF that's inherently unrepresentable in JSON or pure XML.
Since ODF is XML, that is a tautology.
I do not doubt that it is likely that ODF is more complicated than really necessary, and that something better could be designed.
However anyone who criticizes it should define an alternative better format and describe its advantages.
Pointing to some of the existing markup text formats is not this, because those lack a great number of features that are absolutely necessary for any document file format, so they are not comparable at all.
Saying that a markup text format can be suitable as a document format resembles the claim of the Americans that ASCII should be good enough for the speakers of non-English languages.
It would be great if you would stop and at least try to understand the argument you find yourself in and what's being claimed/described by the other side, especially in the comments you're choosing to respond to, instead of hallucinating some altogether completely different claims, like whether any two Web browsers consistently render HTML- and CSS-based Web pages in the wild the same—as if that's somehow pertinent.
> If none of the existing Web browsers can render a Web page in a predictable way in all circumstances, that clearly disqualifies all "Web formats"[†]. If the most complex programs like the Web browsers cannot always render correctly a Web page, then who can?
There is no brilliant observation here. We are not talking about how "the existing Web browsers can render a Web page in a predictable way in all circumstances". The answer to your question literally doesn't matter.
We're talking about the choices available to LibreOffice—choices about how to encode documents in a bytestream that can still be processed by apps that don't have explicit support for formats like ODF, and processed by those that do (apps like, you know, LibreOffice) that's (a) done in a way that's still consistent with the way that it (again: LibreOffice) treated the content the first time around, before it wrote it out to disk (b) consistent with the way that other apps that commit to the same standard of interoperability treat that content. Those are the _only_ tests that matter in this conversation. You can imagine all sorts of other tests and cross-examine against them, but no matter what you manage to come up with, they do not matter.
It's your insistence on not understanding this that's the problem.
The questions—again, the _only_ questions—to answer are:
1. Can LibreOffice encode its documents in such formats and in such a way that it doesn't compromise its ability to have the documents cleanly "round tripping" their way out (of LibreOffice) and back in (to LibreOffice) again—i.e., whether it can use one of these formats as its container (rather than the ZIP-for-XML-&c container that ODF uses). The answer to that question is an unequivocal "yes"—there is literally _nothing_ magical about ODF that can't be captured/encoded using some other scheme for representing data. It's equal parts baffling and maddening that this needs to be stated so, so, so, so, so many times in this discussion.
2. And whether LibreOffice—and any other desktop publishing app that aims to be interoperable—can render those documents "in a [reliably] predictable way in all circumstances". The answer is "yes—assuming it's able to do that now with ODF, and you aren't just putting your thumb on the scale in two dimensions [instead of just the one, as you've been doing throughout this exchange]".
Any and all other of these asinine tests and complaints about the deficient behavior of non-LibreOffice apps (like Firefox, or Chrome, or Windows 95's calc.exe…) are all half-thought-out red herrings that have next to no bearing on the topic at hand. Just mindnumbing attempts to move the goalposts.
† As I already pointed out in my previous comment, and which you inexplicably ignored, PDF is, in fact, quite good at this—and not even just that; it's so much better suited for what you're kvetching about.
> ODF is XML
Uh, no. ISO 26300[1], much like the Open Packaging Conventions[2] used for Microsoft's OOXML and XPS, "uses a package file to store the XML content of a document together with its associated binary data, and to optionally compress the XML content. This package is a standard Zip file". Leaving that aside and the monumental difference that that detail makes wrt the claim and its relevance to this situation:
There are no provisions within the spec requiring ODF producers make sure to spit out a ZIP bytestream that is carefully constructed so it can be processed by a pipeline that is expected to yield a meaningful result when it's treated as something other than ODF-flavored-XML-inside-ZIP (like application/pdf, image/png, image/svg+xml, or text/html, etc)—i.e. ODF packaging has none of the guarantees that SingleFileZ archives provide.
> However anyone who criticizes it should define an alternative better format and describe its advantages.
The media (web or desktop) is irrelevant: a file format must exists for backup and interoperability. I barely use office documents myself, but I work on software that produce and parse many spreadsheets every day.
An open standard is even more very relevant in public administrations where the process follows legal constraints and ISO standards. The Document Foundation's article reacts to an German institutional decision.
What an absurd double standard. The language is patterned after GitHub's own caveats about misuse of GitHub Pages:
> you may receive a polite email from GitHub Support suggesting strategies[… such as, and including] moving to a different hosting service that might better fit your needs
GitHub Pages has never been a free-for-all. The acceptable use policy makes it clear:
> the primary focus of the Content posted in or through your Account to the Service should not be advertising or promotional[…] You may include static images, links, and promotional text in the README documents or project description sections associated with your Account, but they must be related to the project you are hosting on GitHub
They're not. If there's nothing wrong with it, one could ask whether the person here would be okay sitting in a room with their supervisor, the head of the company, and 10 customers, say the same things they're saying here, and get a consensus that this is how this should all work out.
> There are only two ways to make money. One is to bundle; the other is to unbundle. —Jim Barksdale
The original (or just the Firefox 3-era Places revamp?) bookmarks implementation in Firefox had a multi-line field to jot down a personal note or add a description of the page. Even bookmarks folders were allowed to have descriptions—see the New Folder dialog in this screencapture at ~1 minute in <https://youtu.be/QoJXmLuGM3s?t=60>
The "Description" field was removed in 2018. <https://bugzilla.mozilla.org/show_bug.cgi?id=1463738> Being able to capture and redirect the resources that would have inevitably gone into the maintenance costs of this feature over the last 8 years is likely to be the reason Mozcorp has been able to stay afloat on their meager budget that they have to carve out of their half-a-billion-dollar revenue stream stream year after year. Giving users uninterrupted access to Descriptions over that amount of time would likely have bankrupted them.
They're doing a lot more than scanning for "compromised or misleading extensions"; there are a lot of scummy/spammy extensions on the list, but among the extensions included in the list of those they probe are also extensions such as:
- "LinkedNotes" (basically the Personal Note feature from Mastodon, but on LinkedIn profiles) <https://chromewebstore.google.com/detail/neefoldancbjljnnnpn...>
- "Highlight multiple keywords in a web page", an extension that re-implements the equivalent Firefox's "Highlight All" findbar button in Chrome—and happens to mention LinkedIn in the description when describing one use case <https://chromewebstore.google.com/detail/ngkkfkfmnclhjlaofbh...>
- "Delayed gratification Research", a study/focus extension created "for OS semester at CODE University of Applied Sciences" to "Temporarily Block distracting websites"—with all of 4 active users <https://chromewebstore.google.com/detail/mmibdgeegkhehbbadeb...>
It's pretty clear that LinkedIn, like many website operators, don't think of themselves as a source of information that it will send to your UA upon request. It's not even just that they want total visibility into your habits like the worst of the advertising/tracking companies. What they want is as control as they can manage to wrangle over the experience of what it's like when you're "on" their site (i.e. looking at something on your computer that came from their site)—not least of all so they can upsell their userbase on premium features. LinkedIn doesn't care so much that people are inundating other users/orgs that might not appreciate that they're being treated as a "lead", so much as LinkedIn cares that the people doing the inundating are doing it with tools where LinkedIn wasn't able to get a cut.
reply