Maybe I missed it, but I was surprised there was no mention of passwords.
Mandatory password composition rules (excluding minimum length) and rotating passwords as well as all attempts at "replacing passwords" are inherintly dumb in my opinion.
The first have obvious consequences (people writing passwords down, choosing the same passwords, adding 1) leading to the second which have horrible / confusing UX (no I don't want to have my phone/random token generator on me any time I try to do something) and default to "passwords" anyway.
Please just let me choose a password of greater than X length containing or not containing any chachters I choose. That way I can actually remember it when I'm not using my phone/computer, in a foreign country, etc.
> Mandatory password composition rules (excluding minimum length) and rotating passwords as well as all attempts at "replacing passwords" are inherintly dumb in my opinion.
I suspect that rotating passwords was a good idea at the time. There was some pretty poor security practices several decades ago, like sending passwords as clear text, which took decades to resolve. There are also people like to share passwords like candies. I'm not talking about sharing passwords to a streaming service you subscribe to, I'm talking about sharing access to critical resources with colleagues within an organization. I mean, it's still pretty bad which is why I disagree with them dismissing educating end users. Sure, some stuff can be resolved via technical means. They gave examples of that. Yet the social problems are rarely solvable via technical means (e.g. password sharing).
Much of the advice around passwords comes from time-sharing systems and predates the internet.
Rules like "don't write passwords down," "don't show them on the screen", and "change them every N days" all make a lot more sense if you're managing a bank branch open-plan office with hardwired terminals.
It's funny, writing passwords down is excellent advice on today's Internet.
Physical security is easy, who's gonna see inside your purse? How often does that get stolen? Phones and laptops are high-value targets for thieves, and if they're online there could be a vuln. Paper doesn't have RCE.
(That said, I use KeePass, because it's nice to have it synced and encrypted. These days only my KeePass password is written down.)
I was going to say such advice does have its limits. Then I remembered something: even though my current credit card does have a chip, the design suggests that it is primarily intended as a record of a "user id" and "password" (e.g. large easy to read numbers, rather than the embossed numbers intended to make impressions upon carbon copy forms that typically became impossible to read with wear).
Not exactly. Some transactions are cryptographically authenticated. "The algorithm" looks at those bits. Transactions with proper chips authentication are less likely to be flagged as fraud
Also the embossed numbers are not that common in countries outside the US. For quite a while the numbers themselves are also disappearing from the front. (If you even use the physical card rather than your phone)
I remember being mind-blown on my first trip to the US when a taxi driver took my card and literally carbon copied it manually (with a pencil and carbon copy booklet) on the spot.
I had been using my credit card for at least a decade (Europe) and it never ever occured to me that the embossed letters had any function other than aesthetic.
I had a food delivery guy use one in the US 2012/2013. It was like seeing a native tribe perform their traditional dance. It still blows my mind that chip + "signature" is a thing in the US. What good is a random indiscernible scribble on a tiny resistive touch screen as far as proving anything?
I could be wrong but I'm pretty sure it is also illegal to steal someone's credit card and use it. If you have already done that, I don't think the idea of scribbling illegally is going to warn anyone off. Chip+PIN is objectively far more secure. People used debit cards with swipe+PIN for decades just fine and chip+PIN is used in many other countries without an issue. It is just silly to keep using signature and acting like it does absolutely anything at all.
>I suspect that rotating passwords was a good idea at the time.
yes, when all password hashes were available to all users, and therefore had an expected bruteforce/expiration date.
It is just another evolutionary artifact from a developing technology complexed with messy humans.
Repeated truisms - especially in compsci, can be dangerous.
NIST has finally understood that complex password requirements decrease security, because nobody is attacking the entrophy space - they are attacking the post-it note/notepad text file instead.
This is actually a good example of an opposite case of Chesterton’s Fence
> NIST has finally understood that complex password requirements decrease security, because nobody is attacking the entrophy space - they are attacking the post-it note/notepad text file instead.
Actually NIST provide a detailed rationale for their advice [1]. Attackers very much are attacking the entropy space (credential stuffing with cracked passwords is the #1 technique used in breaches). But password change and complexity rules are pointless precisely because they don’t increase the entropy of the passwords. From NIST:
> As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.
> yes, when all password hashes were available to all users, and therefore had an expected bruteforce/expiration date.
Pretty much anyone I've spoken to candidly about rotating passwords has said that they use a basic change to derive the next password from the old. For example, incrementing a number and/or a letter. If that was as common a practise as I suspect, then rotating passwords doesn't add much security. It just meanstthat hackers had to go through a few common manipulation strategies after breaking the hash.
This is actually the third-order effect of itself, by itself.
Require frequent passwords, humans cheat, boom: your brute-force space just went from 1024 bits to 14, assuming you can onboard a red-team plant far enough to get the template for the default passwords.
If I know _bigcorp_ gives defaulted credentials in the format of [First Initial + Middle Initial + month_day] then not only can I piggyback a trivially-created IT/support ticket, I can also just guess that in 60, 90, 120 days, your credentials are the same, but the month_day - even if not correct, the search space is reduced by magnitudes.
It's not crazy to want a system to be designed such that it tends to converge to a secure state over time. We still have expiration dates on ID and credit cards and https certificates.
The advantages just didn't outweigh the disadvantages in this scenario.
You had 6 systems to log into, each with different requirements put on password. You are not supposed to share the password between system. Each system forces you to change the password in different schedule. And IT acts angry when you, predictably, forget password.
It did not converged to secure state, it necessary converged to everyone creating some predictable password system.
Expiration dates on passwords is probably a good idea, except that it encourages bad habits from the end user. It encouraged bad habits since the expiration period was typically very short. For example: I don't have much of an issue with the 1 year period at one workplace, but I do have an issue with the 3 month period at another work place. The other issue is that people have to manage many passwords. Heck, I worked at one place where each employee was supposed to access multiple systems and have different passwords on each system. (Never mind all of the passwords they have to manage outside of the workplace.)
Contrast that to the other examples you provided. All of them are typically valid for several years. In two of the cases, people are managing a limited number of pieces of plastic.
The cert can still be broken. The signatures are difficult, but not impossible, to break: it can and has been done with much older certificates, which means it will likely be doable to current certificates in a few years. In addition, certificate rotation allows for mandatory algorithm updates and certificate transparency logs. CT itself has exposed a few actors breaking the CA/B rules by backdating certificates with weaker encryption standards.
Certificate expiration, and cryptographic key rotation in general, works and is useful.
> which means it will likely be doable to current certificates in a few years
It is extremely unlikely a modern certificate will be broken in the time horizon of a few years through a cryptography break.
All systems eventually fail, but i expect it will be several decades at the earliest before a modern certificate breaks from a crypto attack.
Keep in mind that md5 started to be warned against in 1996. It wasn't until 2012 that a malicious attack used md5's weakness. That is 16 years from warning to attack. At this stage we dont even know about any weaknesses about currently used crypto (except quantum stuff)
Rotating certificates is more about guarding against incorrectly issued and compromised certificates.
I disagree. I don't think rotating certificates would help against birthday attacks or bad prng.
Tbh, i have no idea which part you are attacking with the birthday attack in this specific context. It doesn't seem particularly relavent.
(At the risk of saying something stupid) - i was under the impression RSA did not use nonces, so i don't see how that is relavent for an rsa cert.
For an ecdsa cert, nonce reuse is pretty catastrophic. I fail to see how short lived certs help since the old certs don't magically disappear, they still exist and can be used in attacks even after being rotated.
If properly generated even the smallest RSA key sizes used in practice are still safe from birthday collisions.
But there have been several high-profile cases of bad RNGs generating multiple certs with RSA keys that had common factors. I think if you were put at risk by such a broken RNG, frequently re-generating your certs would tend to make things worse, not better.
CT isn't used for revocation. CRLs aren't really a thing in practise. Refusing to accept expired certs is important for other reasons but won't save you from a reused ECDSA nonce.
Crypto breaks are a concern for sure, but typically the more short-term concern is server compromise. Cert revocation is not reliably checked by all clients, and sites may not even know to revoke it.
So it's essential that if/when a bad guy pops a single server that they don't get a secret that allows them to conduct further attacks against the site for some indefinite period into the future.
TBH where you see this kind of thing (mandatory periodic password rotation every month or two) being recommended, it's people not keeping up with even regulators view of good security practice.
Well, my experience working in the industry is that almost no company uses good security practices or goes beyond some outdated checklists - a huge number wants to rotate passwords, disallow/require special characters, lock out users after X attempts, or disallow users to choose a password they used previously (never understood that one).
I think the number of orgs that follow best practices from NIST etc is pretty low.
It's not necessarily the organization's fault. In several companies that I've worked for (including government contractors) we are required to implement "certifications" of one kind or another to handle certain kinds of data, or to get some insurance, or to win some contract.
There's nothing inherently wrong with that, but many of these require dubious "checkbox security" procedures and practices.
Unfortunately, there's no point in arguing with an insurance company or a contract or a certification organization, certainly not when you're "just" the engineer, IT guy, or end user.
There's also little point in arguing with your boss about it either. "Hey boss, this security requirement is pointless because of technical reason X and Y." Boss: "We have to do it to get the million dollar contract. Besides, more security is better, right? What's the problem?"
I’ve had several companies, including cyber insurers, ask for specific password expiry policies and when I’ve gone back to them explaining that we don’t expire passwords and referencing the NCSC and NIST advice all of them have accepted that without any arguments.
As you say, these are largely box ticking exercises but you don’t have to accept the limited options they give you as long as you can justify your position
And to add to this, it can sometimes be helpful to reply to every wrongheaded security request with "I am not going to decrease the security of my users.". You can use before or after, but once you've explained why a request is not permissible, you can use this line instead of repeatedly explaining.
> disallow users to choose a password they used previously (never understood that one)
That’s because you never responded to an incident when user changed their compromised password because they were forced to only to change it back next day because “it’s too hard to remember a new one”.
Disallow the use of breached passwords - whenever a password change occurs check against e.g haveibeenpwned.
No need to remember past passwords (which is another security risk btw if you ever get breached it will leak all passwords the user ever had).
Legitimate users usually aren't going to fail more than a couple times. If someone (or something) is repeatedly failing, lock that shit down so a sysadmin can take a look at leisure.
>disallow users to choose a password they used previously (never understood that one)
It's so potentially compromised passwords from before don't come back into cycle now.
I fail all the time. Oops, forgot to change my keyboard layout back or 'is it flamingmonkey1, 2, or 3 this time?' (because I have to rotate it every N months and clearly I'm not going to keep generating new passwords that I have to remember, unless the security people really explain why, which they never do), or 'oops, capslock was on', or 'does this password prompt require special characters (is it flamingmonkey1!?) or does it ban them? (or worst of all 'is whatever validates passwords just broken mysteriously and I have to reset my password to fix it?')
There's so many reasons I get passwords wrong. (it doesn't help that work has 4 systems that all use different passwords, all with different requirements).
If you locked me out (without me being able to easily unlock myself), I would immediately consider this an even-more-hostile relationship than normal and would immediately respond in kind.
> Legitimate users usually aren't going to fail more than a couple times.
Have your users authenticate to the wifi with a certificate that expires after 18 months, and you'll find users will reboot a dozen times or so, racking up authentication failures each time, before they call IT support.
I’ve been preaching this message for many years now. For example, since password generators basically make keys that can’t be remembered, this has led to the advent of password managers, all protected by a single password, so your single point of failure is now just ONE password, the consequences of which would be that an attacker would have access to all of your passwords.
The n-tries lockout rule is much more effective anyway, as it breaks the brute-force attack vector in most cases. I am not a cybersecurity expert, so perhaps there are cases where high-complexity, long passwords may make a difference.
Not to mention MFA makes most of this moot anyway.
Most of us can't remember more than one password. This means that if one site is compromised, then the attacker now has access to multiple sites. A password manager mitigates this issue.
People used to memorize the phone numbers of all important family members and close friends without much trouble. Anyone without a serious disability should have no trouble memorizing multiple passwords.
Sure, I do use password managers for random sites and services but I probably have at lower double digit amount of passwords memorized for the stuff that matters. Especially for stuff that I want to be able to access in an emergency when my phone/laptop gets stolen.
People used to memorize a few phone numbers, likely less than 10, and used notebooks made specifically for writing down phone numbers to keep track of the rest.
Phone numbers of the people you called the most (the 10 you memorized) were overwhelmingly likely to be local numbers, so you were only memorizing (3 number chunk) + (4 number chunk). Password rules are all over the place. Memorizing numbers, letters, whole words, the capitalization of those letters and words, and special characters, that are far longer than ye olde timey phone numbers, is orders of magnitude more difficult.
I have over 100 passwords in my password manager. They are all unique, so if any one is compromised, it is contained. My password manager is protected by strong 2FA, so someone would have to physically interact with my property to gain access. In the real world, there is no scenario where memorizing all your passwords is more secure.
They did not. They had papers with all those numbers written down next to landline phones. They also had little notebooks they carried everywhere with them with those numbers written down. You could buy those little notebooks in any store and they fitted into a pocket.
Moreover, those numbers did not changed for years and years. Unlike passwords that change, like, every 3 months.
"MyPasswordIsSecureDespiteNotBeingComplexBecauseItIsLong_BobsForum" is great until Bob's Forum gets hacked and it turns out that they were storing your password in plain text and your password of "MyPasswordIsSecureDespiteNotBeingComplexBecauseItIsLong_Google" becomes easily guessed.
You need a pattern that only you recognise/understand, not just remember. It takes only one leak of your password from service FooBar that looks like "f....b" to know what to try on other sites. Patterns easy to remember are mostly easy to understand.
My bitwarden plugin locks out after a few minutes of inactivity. New installations are protected by totp. So one has to physically be at one of my devices few minutes after I leave even if they have a password. This reduces the attack source to a few people that I have to trust anyway. Also I can lock / logout manually if situation suggests. Or not log in at all and instead type the password from my phone screen.
I understand the conceptual risk of storing everything behind a single “door”. That’s not ideal. But in practice, circumstances force you to create passwords, expose passwords, reset passwords, so you cannot remember them all. You either write them down (where? how secure?) or resort to having only a few “that you usually use”.
Password managers solve the “where? how secure?” part. They don’t solve security, they help you to not do stupid things under pressure.
> so your single point of failure is now just ONE password, the consequences of which would be that an attacker would have access to all of your passwords.
Most managers have 2FA, or an offline key, to prevent this issue, and encrypt your passwords at rest so that without that key (and the password) the database is useless.
Normal dude in a secure office? An auto-locking password manager would suffice.
Someone that should be concerned with passwords in-memory is someone who believes another has full physical access to their computer (and can, say, freeze RAM in nitrogen to extract passwords
My largest concern would be an adversary snatching my phone while my password manager was actively opened
Locking a password manager and your computer is certainly good enough in many cases. But gaining access to memory might not need the sophistication of using nitrogen (see eg https://en.m.wikipedia.org/wiki/DMA_attack).
My point is that you need to read up on it to ensure the implementation of memory handling for your password manager is really safe. As you demonstrate yourself, KeePass has different clients with different memory protection profiles which also depends on the system.
But still not particularly hard. mmap has a
MMAP_FIXED flag for this particular reason — overwrite the arena you’re decrypting to, and you should be set.
If the data was always encrypted, then simply discarding the keys effectively means the drive is left filled with random data. Also, NVMe drives can be sent the sanitize command which can erase/overwrite the data across the entire physical drive rather than just what's mapped into the logical view. I believe there's SATA commands to perform similar actions.
Bitlocker (or anything comparable) makes it safe or ATA Secure Erase if you can issue it (not usable for the system drive most of the times) and check it afterwards.
> And even if it were, who would buy a used SSD with unknown
it doesn't worth it for $30 drive, for the multi-TB ones it's quite common, especially for the ssrver grade ones (look for the PM1723/PM1733)
The one password and the app that uses it are more secure than most other applications. Lock out is just another term for DDoS if a bad actor knows usernames.
I was going to say passwords too ... but now I think passkeys would be a better candidate for dumbest ideas. For the average user, I expect they will cause no end of confusion.
Password policies are a joke since you use 5 websites and they will have 5 policies.
1. Bank etc will not allow special characters, because that's a "hacking attempt". So Firefox's password generator, for example, won't work. The user works around this by typing in suckmyDICK123!! and his password still never gets hacked because there usually isn't enough bruteforce throughput even with 1000 proxies or you'll just get your account locked forever once someone attempts to log into it 5 times and those 1000 IPs only get between 0.5-3 tries each with today's snakeoil appliances on the network. There's also the fact that most people already know that "bots will try your passwords at superhuman rate" by now. Then there's also the fact that not even one of these password policies stops users from choosing bad passwords. This is simply a case of "responsible" people trying and wasting tons of times to solve reality. These people who claim to know better than you have not even thought this out and have definitely not thought about much at all.
2. For everything that isn't your one or two sensitive things, like the bank, you want to use the same password. For example the 80 games you played for one minute that obnoxiously require making an account (for the bullshit non-game aspects of the game such as in game trading items). Most have custom GUIs too and you can't paste into them. You could use a password manager for these but why bother. You just use the same pass for all of them.
Dear user with password “password11111111111” logging in from a random computer with two password stealers active, from a foreign country, and not willing to use MFA, incident response team will thank you and prepare a warm welcome when you are back to office.
Honestly, this comment shows, that user education does not work.
But when someone tries to attack such a password, as long as whatever the user devised isn't represented by an entry in the attack dictionary, the attack strategy falls back to brute force, at which point a repetition scheme is irrelevant to attack time. Granted, if I were creating a repetitive password to meet a length requirement without high mental load, I'd repeat a more interesting part over and over, not a single character.
If cracking techniques catch the concatenation of those as suffixes to short undefined things, which I think many people would do at minimum, that would be worrisome indeed.
Undisclosed minimum length is particularly egregious.
It's very frustrating when you've got a secure system and you spend a few minutes thinking up a great, memorable, secure password; then realize that it's too few (or worse, too many!) characters.
Even worse when the length requirements are incompatible with your password generation tool.
I would love to see most drop-in/bolt-on authentication packages (such as DotNet’s Identity system) to adopt “bitwise complexity” as the only rule: not based on length or content, only the mathematical complexity of the bits used. KeePass uses this as an estimate of password “goodness”, and it’s altered my entire view of how appropriate any one password can be.
IIRC the key point there is that it's contextual to whatever generation method scheme you used--or at least what method you told it was used--and it assumes the attacker knows the generation scheme.
So "arugula" will score is very badly in the context of a passphrase of English words, but scores better as a (supposedly) random assortment of lowercase letters, etc.
Based on the type of this rant - all security focused with little thought about usability of systems they're talking about - the author would probably be one of those people that mandate password rotation every week with minimum of 18 characters to "design systems safely by defatult". Oh, and prevent keyboards from working because they can infect computers via USB or something.
(Yes, I'm commenting on the wierd idea about not allowing processes to run without asking - we're now learning from mobile OSes that this isn't practically feasible to build a universally useful OS that drove most of computer growth in the last 30 years).
I don't get how it took until present day for randomly-generated asymmetric keys to become somewhat commonly used on the Web etc in the form of "passkeys" (confusing name btw). Password rotation and other rules never worked. Some sites still require a capital letter, number, and symbol, as if 99% of people aren't going to transform "cheese" -> "Cheese1!".
I'm genuinely curious if people still think gov.uk is a good example - or I guess, as good as it was.
I'm slightly biased from past experience but my feeling is a lot of the critical thinking that went into gov.uk has been lost. I just can't see the original form of GDS having an cookie banner on gov.uk for example. These were the guys that rightly pointed out that there is no actual need for people to have user accounts to access most govenment services and that no one cares about what govt department they are forced to interact with and yet, I reccently had to create a DVLA account to get an updated drivers liscence (something that happens once a decade).
I think a lot of the more recent issues with gov.uk are the result of some defanging of the central service, leaving departments with more rope to do their own thing and believe that they know best.
Identity in particular is a complex subject, AIUI the original Verify project had to exist in the shadow of the No2ID campaign, which led them to avoid a centralised ID system. This then led to a much more complicated approach that was unable to cater for the needs of some of the departments.
For example, HMRC needed individuals and companies to be able to log in, and for whatever reason this was deemed unworkable with Verify, and thus they build the grandly titled "goverment gateway" auth system - and then I would assume that other depts saw this and decided that meant they could or should build their own auth systems too.
It depends. Usually local councils' websites are purely terrible.
DVLA is mostly very good, I'd say. Especially when dealing with vehicle registration, ownership change, taxing etc.
HMRC is in a category that I'd call "scary". Their website is nice and all but if you ever get locked out of their mobile app for confirming identity (or you delete it by mistake), it's really hard to fix the issue. This is connected to the fact that UK has no national ID card so they use various heuristic to confirm your identity.
UKVI is probably the worst as they don't offer a consistent experience. You can tell that some of their websites were developed in early 2000's and never updated.
It's hit and miss, but I still largely like it when I have to interact with it.
I just re-registered to postal vote from overseas, and the information and links were a labaryinth, often sending me in circles.
Out of exasperation – since I thought my use case didn't match what I was looking for – I clicked the big green "Start" button on the wizard and it worked swimmingly.
When re=applying for a passport in the recent past it was great too, even allowing me to upload a photo from my phone.
Perhaps they have focused on some key interactions that would typically be seen as complex.
The Identity side of GDS has definitely been the worst. I wonder if due to the politics around that service, the thinking has stopped and the Just Get It Done, Even If It's Silly crowd has replaced it.
The identity side has allways been a problem (P)politically and technically.
I think the original GDS was completely correct in basically forcing services not to have them, they are unnecessary for almost/all transactional inerteractions - where they are useful is for things with long term, cosistent interactions i.e. where theres an actual relationship, such as benefits or tax - unfortunatly HMRC and DWP both want to "own" the relationship as individual departments (or even benefits) rather than as a part of the government, and the UK is adverse to anything that looks like a national identity system (ignoring the fact we already have national insurance numbers for everyone(?), passport numbers, etc.)
Where I think the loss of critical thinking bites the most though are the small things:
- cookie banner on gov.uk
- my DVLA password, had to have numbers etc (despite password compostion rules not been a recommeneded best practice for almost 10 years [thanks NIST / GCHQ])
- forms are now so simple due to the mantra of "only ask one thing at a time" that you lose all context as you now have a page for "name", "date of birth" etc. instead of one page for "personal details"
I've participated in some user research with the team building it and I've also designed GOV.UK services pre-One Login that needed to verify people's identity. It's obviously a very difficult problem to solve when there's no universal central ID database. The people working on it are definitely cognizant of the failure of Verify and they're keen not to repeat it.
I do hate the 'GOV.UK One Login' name though. It's previously been called 'GOV.UK Account' and 'GOV.UK Sign In', I'm not sure what was wrong with either of those.
Renaming stuff is the easiest job, so it gets done first :) Thanks for your work on gov.uk. I interviewed (a five hour interview!) with GDS about 6 years ago, and it was a nice place. I declined the offer in the end, but it always looked very promising.
Not quite web 1.0 but I do wonder if there's a market for services that are closer to early web 2.0 products.
For example something closer to Facebook circa 2006. No infinite scroll, a simple timeline, basic media sharing.
Would it be possible to make a reasonable profit by offering simpler versions of existing services just without the engagement dark-patterns we currently have. And if so, could you create enough disruption to move the needle back slightly?
> Not quite web 1.0 but I do wonder if there's a market for services that are closer to early web 2.0 products.
It has for a long time been my position that technical people who are aspiring entrepreneurs (esp. those itching to practice building something) should just clone an existing product and wait for the original to change or shut down. Whenever I say "clone", I really do mean that, and not "our own take on solving the same problem". Gmail's interface changes for the worse, or Vine gets bought and shut down? Boom, there you are on day 1 of the backlash, ready to capture anyone looking to (or forced to) jump ship.
This worked so well by accident with Reddit being able to acquire the exodus of the Digg userbase that I don't understand why people don't try to do it deliberately. And in cases like Vine, due to the nature of abandoned trademarks, you could (eventually) even legally "relaunch" it under the the same brand. This is something that pizza shops do all the time, but it doesn't really happen in SV.
There isn't actually anything close to a standard user account for gov.uk
Again one of the original goals was that services shouldn't require a persistent account. Unfortunately that makes sense in 80% of cases but misses some important ones (Universal Credit, Child tax benefit, Tax).
For whatever reason the people looking at accounts also got fixated on identity (you are Sam Smith) rather than authentication (you have X credentials and have accessed the service before) combined with the UKs aversion to an identity system and central databases (we actually have several) it resulted in Gov.UK Verify, which, last I checked works about 30% of the time.
Ultimately the big departments (HMRC) just built their own thing and created user portals which GDS didn't like... So everyone argued and no one fixed the actual problem.
GDS used to recommend matomo, especially for services with 'sensitive' content (each service on gov.uk is actually developed, hosted and deployed separately). I know the foreign office used it, unfortunately the trend amongst the designers/analysts/product managers had been to push GA without any real thought process (because frankly it's easier than getting permission to setup and maintain a self-hosted product)
GA is already approved and installable via a meta tag, so besides the warm feeling of fighting the giant, there is not too much upside and lots of questions to answer.
Upper stakeholders should connect the ideas : "Google data monopoly" and "other option for analytics should be available".
GDS have done some excellent work in the past, especially around usability and design. Unfortunately since the various senior leaders have left and it's moved further into government/cabinet office they have increasingly started to become something of a parady of themselves.
It's interesting that one of the original principles behind gov.uk navigation was that it should be secondary to Google. The focus was on getting people to the right page from Google/Bing/DDG (where they start) without the need to navigate gov.uk itself.
I also find it odd that the problem they identified from the Discovery was poor information architecture but their solution is to redesign the navigation menu. The use of the word 'topics' is also interesting. Again, GDS and gov.uks intent was to make it easier to access services, but the word service or a list of services isn't represented in either the current design or prototype.
Sir Francis Maude and the team he had around him untill about 2016.
I don't have the links to hand but there was some really great thinking going into what it meant to provide government services online at the time.
Unfortunately when he and the original team left and more people joined GDS / departments started to develop their own services a lot of direction and momentum was lost.
There used to be a twitter account @govdigirati that was great at satirising GDS after around 2017
Unfortunately GDS is now mostly toothless in all honesty
The GDS, even today, has an intrinsic beauty to it. It's really a marvel of engineering, though not the prettiest.
A big problem is that now a lot of designers, particularly among the contractors, who are several generations removed from the creators, simply don't understand it and don't follow the guidelines.
Shameless plug: I wrote a template pack for Django Crispy Forms so you can get fully GDS compliant, fully accessible pages with zero effort, https://github.com/wildfish/crispy-forms-gds
> Unfortunately when he and the original team left and more people joined GDS / departments started to develop their own services a lot of direction and momentum was lost.
If this is true, then it proves everything that comes around, goes around. My first ever professional web development job was rebuilding the England and Wales Housing website[1], which was around the time that gov.uk was beginning its work to bring all central government online activity into the one site. The resistance from Government Departments - who all greatly value their semi-independence from the clutches of the Cabinet Office (and HM Treasury) - was immense!
I'm glad gov.uk won that fight: allowing each Government Department to have its own online presence, and their individual policies and procedures surrounding that presence, can never lead to a good outcome for people who have to access and use government services online.
> they have increasingly started to become something of a parady of themselves.
I think a huge contribution to that were IR35 changes in public sector that created a brain drain. Talent was replaced by poor quality service from big consultancies.
This, although I would call it the 'enterprise' model.
This is how teams in the UK Gov are structured (infact we have more roles [52 at last count]) and its horrible. Aside from the lack of ownership and autonomy at an individual level you also end up with increadibly fragile teams as theres no depth of experience.
If you have 7 people and they all do different things you spend more time finding things for people to do than working on valuable problems - much better to find people with overlapping skillsets in the domain you want to solve a problem then let them get on with it. So if you want to build some software - hire people that can write code, if you want to provide information - hire some writers. Hire smart people and they can do the bits around the edges 'enterprises' think they need specialsists for.
"A jack of all trades is master of none, but often times better than a master of one"
Mandatory password composition rules (excluding minimum length) and rotating passwords as well as all attempts at "replacing passwords" are inherintly dumb in my opinion.
The first have obvious consequences (people writing passwords down, choosing the same passwords, adding 1) leading to the second which have horrible / confusing UX (no I don't want to have my phone/random token generator on me any time I try to do something) and default to "passwords" anyway.
Please just let me choose a password of greater than X length containing or not containing any chachters I choose. That way I can actually remember it when I'm not using my phone/computer, in a foreign country, etc.