Sure, but the government HAS to make that determination in a data-driven way. It cannot be based on anything subjective, for what should be obvious reasons.

On top of that, said lack of knowledge is a stated goal of all privacy-focused browsers. GA-blindness is an implementation detail of these policies. Any method the government could use to accurately track that information is effectively a bug in need of fixing from the POV of the browser's developers.

The most practical answer is, as was posted by someone else here, the government spec'ing to a standard instead of a set of browsers, which it really should be doing in the first place. The mere fact that the current setup means that the government accidentally makes and/or breaks winners in that space is justification enough.

There is no standard that you can use instead of a set of browsers. There is no way of making sure that a website works with a browser other then testing it with that browser. The reason people test with different browsers is not that they want to use non-standard features, it's that even standard features often do not work in certain browsers.

Sort of agreed as of today, but this is not something that we just have to accept, especially considering the government doesn't really have a need to make use of the full suite of tools provided by the various existing standards. There are safe subsets to be picked in 2023.

The government doesn't design roads to conform to the top brands of cars and trucks. It specs them to a standard and any manufacturer can have their product certified as compliant. This both protects the public and gives anyone an opportunity to provide products no matter how small their market share is. Doing it the other way around would be madness, and I don't see why the same principle shouldn't apply here.

> The reason people test with different browsers is not that they want to use non-standard features, it's that even standard features often do not work in certain browsers.

This is exactly why sites should be tested for their conformance with the standard rather than with specific browsers. Testing against specific browsers just encourages browser-makers to continue to avoid fixing their shit.

If you want to make money or reach constituents, this isn't actually a viable option for anyone.

When people complain that they can't submit their DMV forms (or whatever) and you say, "well we followed all the standards, go find another browser" and they say "which one" and you say "I don't know, we didn't test with any browsers, we just test against the standard" who do you think they'll blame?

So we can't have a well-functioning system because that would interfere with some people making money. We truly do live in sad times.

That's why I said "reach constituents". Governments, nonprofits, utilities, etc, all ideally need to actually reach everyone, it doesn't matter how.

Is it really a standard if no one implements it in a way that everyone agrees on?

Is it really a standard if the dominant vendor just ignores the standard and does what it wants because then it becomes the "actual standard" ?

As a (terrible) example, look at FIPS. The government has the power to mandate a standard that everyone needs to implement. If instead of "supporting specific browser vendors" they "support a specific standard" then all vendors have a target that works with an agreed upon common ground.

> Is it really a standard if no one implements it in a way that everyone agrees on?

Plenty of standards are guidelines. The point is the website’s purpose trumps dogmatic adherence to a standard. If the site works against standards but not in the browser, it’s a failure.

But we can still have websites that work against existing browsers while also being strictly conforming to the standard, surely?

Basically, no proprietary features whatsoever. No draft features. No optionally-supported standard features without a fallback that fully covers the same underlying use case.

Given the history of standardisation for promoting interoperability includes numerous success stories and a pattern of resistance fading over time I don't see why we should expect web standards to be any different. The level of functionality needed by a typical government site has worked close to 100% correctly in literally every major browser for literally decades.

Then perhaps we should look at how we ended up in this state of affairs where testing against the standard doesn't actually ensure that your website works in the most popular web browsers out there, and do something about it? Like, say, mandatory standard conformance testing for browsers with >X% market share?

They're the government. They can create a spec or standard for browsers to be able to use government supplied digital services. It's done all the time.

This would be beneficial guidance for browser developers, but also for anyone developing government sites. Saying "whatever chrome is doing is our standard" is a cop out.

There was until Google and Mozilla decided W3C wasn't moving fast enough and introduced WHATWG.

Sure there is a standard, are you saying the w3 doesn't exist? The issue is that somehow people here are arguing that it is sufficient to test that you are adhering to a standard by only testing against chrome, edge and safari (two of which are the same engine).

If you want test that you are adhering to a standard (if there is no testsuite available) you need to test against more than 2 independent implementations.

Firefox is not IE8, which declared lot of CSS3 and HTML5 standards as "won't be supported" in 2009, paving the way for its own extinction.

USDS serves basic pages and applets which work fine on Firefox. It is only a handful of very complex web apps like Photopea where the developer will say "run this on Chrome for best results".

Server-side tracking of user agent strings should still be possible.

Yeah, I think the root comment of this thread is talking out of his ass. Third-party trackers are not needed, and wouldn't make sense to use, to discern browser market share; browsers self-report their identity and operating system unless specifically configured not to. For example, my User-Agent string in my GET request to retrieve Hacker News is: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0".

Except we should be pushing for the elimination of user agent strings, too. They just end up being used as a lazy way for lazy developers to not test for capabilities.

The most recent example I've run into is Snapchat's web client: It reject's Firefox purely by user agent string, but then works perfectly in Firefox if you just have your browser lie.

I strongly agree. I don't think a website is going to do anything with my user agent string that benefits me. I'd much prefer a web where websites can't do things outside of the standard. We ne er needed webmidi, but a company that makes a browser/is hybrid definitely wanted it.

Speaking of Google, won't this interfere with their "look we're not a monopoly" payments to Mozilla Corp?

That's the sort of this that should be illegal for anticompetitive reasons.

> Sure, but the government HAS to make that determination in a data-driven way.

They really should be hiring a pollster to ask people which browser they use. It might be a bit difficult for those who use the default, but it wouldn't be that difficult to ask a couple of followup questions (e.g. which device) to determine which default browser that is.

I think most people would say "the internet" or "my phone" rather than something useful.

GOV.UK is dramatically more competent than USDS, are they not? I admit I'm not terribly familiar, but I wouldn't want to depend on the agency behind the Department of Education and VA websites for anything. I've seen the VA site, in particular, do serious harm to the people it's meant to serve.

I don't think the USDS makes all or even most of the current federal gov websites.

No, they don't. But they did create the VA site: https://www.usds.gov/projects/va-dot-gov

And they're involved with the Department of Education, although I couldn't find out exactly what they built.

the va site is vast, to say any one team created the VA site would not be even close to correct.

They did help change over the old va.gov to the new va.gov (which was built as vets.gov), which imo has been a huge improvement.

(There are still many, many problems with the VA and its website. Just saying that 1. the new va.gov is a big improvement and 2. the USDS is far from being a single point of responsibility for it, or even _the_ major point of responsibility)

Oof, that sucks to hear. I had a hard time believing they'd be behind that website seeing that I often hear complaints about it. :(

USDS certainly does not. The guiding principle at the time from what I remembered is to try to set "some standard" for all federal government websites to strive to because there were none.

We also helped with design and infrastructure support for ssa.gov (launched earlier this year) with a contractor team to try to boil down 60,000 pages to ~30 pages that people tend to use.

// opinions of a former USDS, no longer with the team

Hi!

Can you elaborate on what in particular on the VA site that causes serious harm to the people it's meant to serve? I'm happy to bring it to the team or if you don't feel comfortable with stating it here, please bring it up to the open source website for va.gov. https://github.com/department-of-veterans-affairs/vets-websi...

I get unsupported browser warnings on my country's government portal when I use Firefox.

I think it's been the case for a good 10 years.

It works fine, of course

Some of the USDS people are even ex-Mozilla!

The 2% rule USDS use is taken directly from GDS (gov.uk), so that isn't what your old employer's policy is at all. They have to define reasonable, after all.

That part of the article was just wrong, to be fair (I used to be head of the front-end community at GDS and helped set things like browser support schedules). Our default approach was to add up all browser share (yes, based on GA, but this was a while ago) until we got to 99%, then removed the browsers that were left over. So typically we wouldn’t consider dropping a browser version until it was less than 0.4% usage. You can use a colleague’s client-side tool to test this approach: http://edds.github.io/browser-matrix/ (assuming it still works).

The browser support is currently listed at https://www.gov.uk/service-manual/technology/designing-for-d... . The mention of 2% is specific to IE11, so I guess this was special-cased at some point.

I stand corrected, thank you.