Re: A+ 0
On Wed, 24 Apr 2024 18:58:05 -0400 bill-auger wrote: > i will re-state the proposed A+0 more precisely: > > A+0: > > All important site functionality per criteria (C0) works correctly, > > without contacting any third-party service(s) delegated by the site. (A+0) > > because in practice, every request > to the website cascades hundreds of requests to third-parties who are not > subject to any of these criteria to elaborate, the motivation is as if there were these criteria: > A+0: > All third-party service(s) delegated by the site must also meet criteria the > same criteria as the site. (A+0) > A+1: - Does not log anything about visitors. (A+1) + The site and all third-party service(s) delegated by the site do not log anything about visitors. (A+1) but those criteria are not satisfiable; because the site admin could not sincerely attest to either, unless there are no third-parties involved in the communication
Re: A+ 0
On Tue, 23 Apr 2024 19:46:45 -0400 Richard wrote: > I don't see a need to > give a site a bad mark for referring to Google Analytics or anything > else that doesn't stop the site from functioning with LibreJS. this is a different concern - for a site to fail the proposed A+0, it would implicitly "stop the site from functioning with LibreJS" - in the case of gitlab.com, it would stop the site from functioning for anyone, any computer, any web browser, whether or not the website used any scripts - the proposal is the privacy analog to C0: C0: > All important site functionality that's enabled for use with that package > works correctly (though it need not look as nice) in free browsers, including > IceCat, without running any nonfree software sent by the site. (C0) i will re-state the proposed A+0 more precisely: A+0: > All important site functionality per criteria (C0) works correctly, > without contacting any third-party service(s) delegated by the site. (A+0) the criteria is not related to scripts - it is a privacy concern, on par with the "no logging" criteria - in fact, the "no logging" criteria (A+1) is meaningless without this proposed criteria; because in practice, every request to the website cascades hundreds of requests to third-parties who are not subject to any of these criteria
Re: A+ 0
I guess the concern I've been bringing up relates to how disruptive or abusive some JS might be, and in practice it is unlikely that free JS is involved in such problems. However, I do think that, e.g. GitLab running some third-party request to CloudFlare and blocking access if it doesn't return a particular result — that seems to me to be a problem independent of the licensing of any JS involved. In practice, since this does not pass LibreJS validation, it is caught by that criterion. I just think that if somehow that was adjusted to pass LibreJS validation, it would still be a problem. Having said this, I don't care to discuss the issue further here. On 2024-04-23 4:46, Richard Stallman wrote: [[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > elsewhere in the criteria there is language about functionality > I think there's confusing with language of "impose" > Many websites function with requests blocked. For example, Google > Analytics being blocked doesn't break anything. The intention of the criteria about JS code is that the site should work if the user blocks the Javascript code. I don't see a need to give a site a bad mark for referring to Google Analytics or anything else that doesn't stop the site from functioning with LibreJS. Our general policy towards JS is that if you appreciate the issue you should make your browser block it, so we judge sites assuming you have done that. However, I wouldn't okject to an A+ criterion of "no nonfree JS at all in the pages" or "no JS at all in the pages."
Re: A+ 0
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > elsewhere in the criteria there is language about functionality > I think there's confusing with language of "impose" > Many websites function with requests blocked. For example, Google > Analytics being blocked doesn't break anything. The intention of the criteria about JS code is that the site should work if the user blocks the Javascript code. I don't see a need to give a site a bad mark for referring to Google Analytics or anything else that doesn't stop the site from functioning with LibreJS. Our general policy towards JS is that if you appreciate the issue you should make your browser block it, so we judge sites assuming you have done that. However, I wouldn't okject to an A+ criterion of "no nonfree JS at all in the pages" or "no JS at all in the pages." -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: A+ 0
elsewhere in the criteria there is language about functionality I think there's confusing with language of "impose" Many websites function with requests blocked. For example, Google Analytics being blocked doesn't break anything. Given A+ level, I think it could be appropriate to be critical of any third-party requests being made. My inclination is to have it be a lower grade requirement (A or B) to not have breakage of *functionality* when requests are blocked (contrast that not loading particular fonts or analytics etc doesn't break functionality) On 2024-04-18 10:37, bill-auger wrote: On Fri, 19 Apr 2024 01:30:13 -0400 bill-auger wrote: which deliberately makes the website useless if third-party requests are blocked that may not be exactly accurate though - i think that cloudflare deal is not a third-party request, but a re-direct, which (i think) blockers would not block
Re: A+ 0
On Fri, 19 Apr 2024 01:30:13 -0400 bill-auger wrote: > which deliberately makes the > website useless if third-party requests are blocked that may not be exactly accurate though - i think that cloudflare deal is not a third-party request, but a re-direct, which (i think) blockers would not block
Re: A+ 0
On Thu, 18 Apr 2024 22:07:36 -0700 Aaron wrote: > "Impose" is a little funny, there are two levels: one is using > third-party requests at all, the other is functioning when such requests > are blocked. i agree but in practice, those are usually the same - blocking third-party requests typically renders the website useless - developers need to take precautions consciously to ensure otherwise; and that is not the norm - gitlab's use of cloudflare is an extreme example, which deliberately makes the website useless if third-party requests are blocked so "Impose", as in "take it or leave it"
Re: A+ 0
"Impose" is a little funny, there are two levels: one is using third-party requests at all, the other is functioning when such requests are blocked. On 2024-04-16 2:52, bill-auger wrote: On Tue, 16 Apr 2024 14:16:23 -0700 Aaron wrote: Codeberg DOES pass that criteria I think. There are no third-party requests, they actually care about this sort of thing. thats great - so a new criteria could highlight that some service operators are conscientious of that concern, withing constraining it to that one specific usage "browser validation" - bear in mind, that is really what this list is evaluating - much more than the properties of the software, it is evaluating how the service operators treat their users - surely a website could do it's own "browser validation" with libre code and without a third-party; in which case, it would be much less objectionable A10: Does not impose connecctions to third-party services. WDYT?
Re: A+ 0
On Tue, 16 Apr 2024 14:16:23 -0700 Aaron wrote: > Codeberg DOES pass that criteria I think. There are no third-party > requests, they actually care about this sort of thing. thats great - so a new criteria could highlight that some service operators are conscientious of that concern, withing constraining it to that one specific usage "browser validation" - bear in mind, that is really what this list is evaluating - much more than the properties of the software, it is evaluating how the service operators treat their users - surely a website could do it's own "browser validation" with libre code and without a third-party; in which case, it would be much less objectionable > A10: Does not impose connecctions to third-party services. WDYT?
Re: A+ 0
Codeberg DOES pass that criteria I think. There are no third-party requests, they actually care about this sort of thing. I know that some extreme sticklers found some reason to complain about Codeberg and cloudflare something related to https://blog.codeberg.org/on-the-cloudflare-tor-takedown.html or whatever, I don't know. Some few people got mad about something. But when I go to Codeberg, the important thing is I see zero requests to any other domains. Whatever offloading they do (if any), it does not happen on the client side. On 2024-04-16 12:23, bill-auger wrote: On Tue, 16 Apr 2024 15:14:29 -0400 bill-auger wrote: savannah and notabug would meet that criteria, and gitlab would not ... also probably codeberg would not - most websites offload some work to third-parties - i dont think the cloudfare thing is much different than relying on third-parties to deliver scripts - regardless of what the third-party does (as long sa it is libre), "relying on third-parties" is the essential problem; and probably codeberg does that if you are looking for a new criteria which would penalize gitlab but not codeberg, i dont think there is any meaningful criteria which would distinguish them, other than the one which got gitlab demoted a few years ago
Re: A+ 0
On Tue, 16 Apr 2024 15:14:29 -0400 bill-auger wrote: > savannah and notabug would meet that criteria, and gitlab would not ... also probably codeberg would not - most websites offload some work to third-parties - i dont think the cloudfare thing is much different than relying on third-parties to deliver scripts - regardless of what the third-party does (as long sa it is libre), "relying on third-parties" is the essential problem; and probably codeberg does that if you are looking for a new criteria which would penalize gitlab but not codeberg, i dont think there is any meaningful criteria which would distinguish them, other than the one which got gitlab demoted a few years ago
Re: A+ 0
FWIW, i could propose another criteria, which would penalize gitlab for using a third-party gate-keeper; but one more general - when i was helping with notabug, we made it a point to ensure that visitors would not need to connect to any other server - that was accomplished for gogs by serving all scripts from the same server - so i would propose this (maybe at the A or A+ level?): > Does not impose connecctions to third-party services. savannah and notabug would meet that criteria, and gitlab would not
Re: A+ 0
On Tue, 16 Apr 2024 11:28:58 -0700 Aaron wrote: > GitLab has this > verification obstacle. This difference is not addressed by your > suggested wording. it could be interpreted that way though, depending on what "viewing" means - but that cloudflare thing is not "authentication" precisely - that conflicts more with the discrimination or no-JS criteria; but it is not obvious that it is a problem - it is not disciminating people; but their choice of client - a JS-heavy forge like codeberg may not work with all web browsers or curl - i dont know if that can be a criteria (eg: it must work with all web browsers) the bug reporting and patches criteria was not intended to address gitlab; but several forges (savannah, sourceforge, and sr.ht) would meet that criteria, and it is a rather nice-to-have one
Re: A+ 0
On 2024-04-15 10:23, bill-auger wrote: On Mon, 15 Apr 2024 22:09:20 -0700 Aaron wrote: indeed the access to git directly is unencumbered, it's only the loading of the website in a browser that is affected ok, so i propose working it out this way: move A+0 to level B or C (specifying that it is WRT the most basic public access to "source code") Allows viewing and downloading source code without authenticating. that seems fine to me replace A+0 with a new stronger one Allows bug reporting and offering patches without authenticating. That seems inadequate to me. It makes zero distinction between Codeberg and GitLab. But Codeberg allows far more "without authenticating" such as *seeing* issue tickets and so on. Codeberg allows *read* access to everything without any sort of verification-wall. GitLab has this verification obstacle. This difference is not addressed by your suggested wording.
Re: A+ 0
On Mon, 15 Apr 2024 22:09:20 -0700 Aaron wrote: > indeed the access to git directly is unencumbered, it's only the loading > of the website in a browser that is affected ok, so i propose working it out this way: move A+0 to level B or C (specifying that it is WRT the most basic public access to "source code") > Allows viewing and downloading source code without authenticating. replace A+0 with a new stronger one > Allows bug reporting and offering patches without authenticating.
Re: A+ 0
indeed the access to git directly is unencumbered, it's only the loading of the website in a browser that is affected On 2024-04-15 10:05, bill-auger wrote: On Tue, 16 Apr 2024 00:54:20 -0400 bill-auger wrote: im quite sure that one can download the source code via the git program without authentication or a third-party mediator, or download source-balls with curl that was a rather weak statement actually - in fact, i _know_ that is possible - that is how every distro gets source code for packaging - if that ever changed, most distributors would complain loudly to the maintainers, asking them to provide some other way to access the source code - if they did not comply, i would not be surprised if most dropped that software - the packaging tooling is not equipped for that; because the notion is quite preposterous
Re: A+ 0
On Tue, 16 Apr 2024 00:54:20 -0400 bill-auger wrote: > im quite sure that one can download the source code via the git program > without > authentication or a third-party mediator, or download source-balls with curl that was a rather weak statement actually - in fact, i _know_ that is possible - that is how every distro gets source code for packaging - if that ever changed, most distributors would complain loudly to the maintainers, asking them to provide some other way to access the source code - if they did not comply, i would not be surprised if most dropped that software - the packaging tooling is not equipped for that; because the notion is quite preposterous
Re: A+ 0
On Mon, 15 Apr 2024 21:46:19 -0700 Aaron wrote: > I'm not sure you understand my point. GitLab does the Cloudflare > "authentication" when someone visits a public listing of a project with > no logging in at all. i was not aware of that - the last time we discussed gitlab, cloudfare was only involved during the login process - still i think that is more of a privacy or discrimination concern, regarding your choice of web browser im quite sure that one can download the source code via the git program without authentication or a third-party mediator, or download source-balls with curl, wget, etc - so arguably, that hurdle imposes no loss of freedom - its just kinda ... icky
Re: A+ 0
On Tue, 16 Apr 2024 00:33:44 -0400 bill-auger wrote: > people should be able to send patches and report bugs > without authentication; but even savannah does not allow that ... with one caveat, unlike most forges, savannah does offer optional mailing lists - if the project opts for a mailing lists, then people may report bugs and offer patches without authentication - i would consider _that_ as an A+ nice-to-have feature; but unauthenticated read access is the norm
Re: A+ 0
On 2024-04-15 9:33, bill-auger wrote: On Thu, 21 Dec 2023 19:17:32 -0800wolft...@riseup.net wrote: I don't like the phrase "operate on projects", I don't think that is the key point. I think the key point is to access the projects at all. Maybe something like this: "Access to any public parts of projects is not limited by any form of authentication of visitors." ? i think i and aaron basically agree - i would not even bother specifying "public parts of projects" so verbosely - the only "parts" that is important is the source code - unauthenticated git access alone, would satisfy this; and every forge that i have ever seen allows that - any other "parts" are the ones that should require authentication (write access - eg: posting tickets, offering patches, etc) - even "reading" tickets and patches is not so essential to software freedom to swing to that the extreme, one could suggest that people should be able to send patches and report bugs without authentication; but even savannah does not allow that IMHO, my version is concise and adequate Allows viewing and downloading source code without authenticating. (A+0) bearing in mind that this proposal is to elevate A+0, and bearing in mind that every public forge satisfies A+0 and would not conceive to do otherwise, because to do so is effectively to make the forge private, what other "public parts of projects" does that exclude, which are important enough at the B level? On Thu, 21 Dec 2023 19:17:32 -0800wolft...@riseup.net wrote: Also, I still think "authentication" seems not specific enough. Is it "authentication" when GitLab.com does some cloudflare check that blocks the entire site from loading upon failure? yes, that is part of their authentication procedure - that is a separate issue - that is suggesting "what of the website does not allow some users to login", which is C2 (Does not discriminate) - the point of A+0 is simply "must you login?", regardless of how (password, API token, whatever - the form of the auth is irrelevant I'm not sure you understand my point. GitLab does the Cloudflare "authentication" when someone visits a public listing of a project with no logging in at all. It is a cloudflare-verification-wall to even loading the normal public website. And if someone visits with a generic browser with JS functioning and typical cookies etc. whatever, they don't do any logging in, they don't see the verification wall, they just see the regular public project and do not know that the verification was even happening. And despite it happening, they are not logged in, there's no account involved.
Re: A+ 0
On Thu, 21 Dec 2023 19:17:32 -0800 wolft...@riseup.net wrote: > I don't like the phrase "operate on projects", I don't think that is the key > point. I think the key point is to access the projects at all. > Maybe something like this: "Access to any public parts of projects is not > limited by any form of authentication of visitors." ? i think i and aaron basically agree - i would not even bother specifying "public parts of projects" so verbosely - the only "parts" that is important is the source code - unauthenticated git access alone, would satisfy this; and every forge that i have ever seen allows that - any other "parts" are the ones that should require authentication (write access - eg: posting tickets, offering patches, etc) - even "reading" tickets and patches is not so essential to software freedom to swing to that the extreme, one could suggest that people should be able to send patches and report bugs without authentication; but even savannah does not allow that IMHO, my version is concise and adequate > Allows viewing and downloading source code without authenticating. (A+0) bearing in mind that this proposal is to elevate A+0, and bearing in mind that every public forge satisfies A+0 and would not conceive to do otherwise, because to do so is effectively to make the forge private, what other "public parts of projects" does that exclude, which are important enough at the B level? On Thu, 21 Dec 2023 19:17:32 -0800 wolft...@riseup.net wrote: > Also, I still think "authentication" seems not specific enough. Is it > "authentication" when GitLab.com does some cloudflare check that blocks the > entire site from loading upon failure? yes, that is part of their authentication procedure - that is a separate issue - that is suggesting "what of the website does not allow some users to login", which is C2 (Does not discriminate) - the point of A+0 is simply "must you login?", regardless of how (password, API token, whatever - the form of the auth is irrelevant
Re: A+ 0
On Wed, 20 Dec 2023 23:20:00 -0500 Richard wrote: >Does not impose any authentication requirements for visitors to operate >on projects, other than what the managers of each project have chosen. this is substantially different than the current A+0 > Allows visitors to look and download without authenticating. (A+0) i would not consider to "look" or "download" to be "operating on projects" - that is plainly (passively) "fetching data" - "operating on projects" suggests write access, which of course should require authentication, and is of course subject to the maintainers approval - all of these are the common expected norm - no one would so much as suspect that a public forge would work differently
Re: A+ 0
I don't like the phrase "operate on projects", I don't think that is the key point. I think the key point is to access the projects at all. It's one thing if someone can see public stuff (see code history, issue tickets, download the source code etc) and another for someone to submit anything (create an issue ticket or send in a code patch or similar). Also, I still think "authentication" seems not specific enough. Is it "authentication" when GitLab.com does some cloudflare check that blocks the entire site from loading upon failure? Maybe something like this: "Access to any public parts of projects is not limited by any form of authentication of visitors." ? On 2023-12-20 8:25 p.m., "Svetlana Tkachenko" wrote: Hi Richard > I agree with the point, but I think those words don't make it totally > clear. I think these would be clearer. > > Does not impose any authentication requirements for visitors to operate > on projects, other than what the managers of each project have chosen. > > WDYT> Maybe this: Does not impose any authentication requirements for visitors to operate on projects, other than the requirements set by the managers of each project; provides a facility to host a project in which all such requirements are absent, allowing full public access.
Re: A+ 0
Hi Richard > I agree with the point, but I think those words don't make it totally > clear. I think these would be clearer. > >Does not impose any authentication requirements for visitors to operate >on projects, other than what the managers of each project have chosen. > > WDYT> Maybe this: Does not impose any authentication requirements for visitors to operate on projects, other than the requirements set by the managers of each project; provides a facility to host a project in which all such requirements are absent, allowing full public access. -- Svetlana Tkachenko, Associate Member of the Free Software Foundation = Gryllida, Developer and volunteer for the Wikimedia movement http://www.wikimedia.org http://www.fsf.org http://www.gnu.org SIP: gryllid...@sip.linphone.org E: svetl...@members.fsf.org
Re: A+ 0
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > If we want to be picky, we might use wording like, "Does not require > visitors to do any form of authentication in order to look and > download". So, that means the service doesn't require these limitations. > It doesn't strictly say that they can't offer private repo settings. I agree with the point, but I think those words don't make it totally clear. I think these would be clearer. Does not impose any authentication requirements for visitors to operate on projects, other than what the managers of each project have chosen. WDYT> -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: A+ 0
> If we want to be picky, we might use wording like, "Does not require > visitors to do any form of authentication in order to look and download". > So, that means the service doesn't require these limitations. It doesn't > strictly say that they can't offer private repo settings. I agree.
Re: A+ 0
The concern is that the host service *allows* projects to provide access without these intrusive obstacles. Whether projects can restrict access is not the point. If the service allows limitations on access, then it's a matter for each project what they set and whether it is appropriate. If we want to be picky, we might use wording like, "Does not require visitors to do any form of authentication in order to look and download". So, that means the service doesn't require these limitations. It doesn't strictly say that they can't offer private repo settings. On 2023-12-17 8:11, Richard Stallman wrote: [[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Someone on gnu-misc-discuss suggested that this Allows visitors to look and download without authenticating. (A+0) should have an exception for private repos -- those that are explicitly not accessible by the general public. What do you think of this?
