The story around universal #SSL has been presents as a purely technical and inevitable improvement, make everything encrypted and the problem is solved. But technology is not separate from the social systems around it. SSL/TLS encryption improves security, the question here is not whether encryption is useful – it clearly is. The question is what happens when one technical approach is treated as a universal requirement, and what that tells us about the changing culture of the web.
The distinction matters because the original #openweb was built around accessibility, decentralization, linking, experimentation and the ability of ordinary people and communities to publish their own material. The #closedweb, by contrast, concentrates infrastructure, ownership and control in #dotcons platforms and technical institutions. From this view, the universalisation of SSL raises an interesting #openweb question – when does a useful security technology become part of the centralizing infrastructure?
This is where the #geekproblem enters, not as an argument against technical expertise, technical knowledge is essential. The problem comes when technical solutions are treated as if they exist outside social context – when a technically elegant answer becomes more important than accessibility, participation, resilience or the paths of ordinary people.
Universal SSL becomes an example of this thinking. For a technically confident organization, obtaining and maintaining certificates may be straightforward. For a small community project, #DIY server operator or someone trying to put a simple service onto the web, the accumulated requirements becomes another layer of technical knowledge, infrastructure and administration. Each individual requirement may appear reasonable, the cumulative effect can still be exclusionary.
There is also a deeper infrastructure question – security versus centralization. Modern web encryption depends on certificate authorities and a chain of trust. That creates powerful intermediaries between the person running a website and the person visiting it. Let’s Encrypt is an important part of this ecosystem and has made HTTPS certificates easier and cheaper to obtain. That is a genuine achievement.
But concentration still deserves scrutiny. If large parts of the web depend on a relatively small number of organizations and technical systems for establishing trust, then those systems become important points of power and potential failure. The isse is whether security has to mean centralization, a very #openweb question – that the more interesting issue is not SSL itself but the cultural shift – from voluntary tool to universal rule “This is a useful security tool.” to “Everything must work this way.”
Once a technical standard becomes mandatory through browsers, hosting providers, search engines, platforms and infrastructure, the choice is no longer being made by the person running the website. The web becomes easier for some people and harder for others, large #dotcons platforms absorb the complexity were the small community projects have to learn another system.
The corporate developer gets another abstraction layer, the DIY operator gets another thing that can break. This is how the #openweb slowly become a #closedweb without anyone explicitly deciding to close it. Nobody has to say “Ordinary people shouldn’t run websites.” instead, we simply keep adding requirements until doing so becomes difficult.
This is the problem for the fear-based path to security, were security is presented through fear: Hackers – Attack – .Surveillance – Identity theft – Compromise – Catastrophe. Yes, some of those threats are real, but fear paths produce a particular response: more control, more centralization and more dependence on trusted authorities. That is a conservative path to security, were the assumption becomes that safety comes from putting more infrastructure between ordinary people and the systems they use.
The #openweb asks a different question – can we create security through distributed trust, understandable systems and resilient communities rather than simply adding more layers of authority? That doesn’t mean abandoning encryption, it means refusing to treat encryption as the whole answer. A healthy #openweb needs encryption, it needs transparency, it needs understandable infrastructure with multiple paths to trust. It needs decentralization, it needs people who can actually participate – this is where the #4opens idea of trust becomes useful.
The #openweb needs systems that can fail locally without taking huge parts of the web down with them. Secure, open, understandable and resilient infrastructure that ordinary people and communities can use. We need to be able to ask – Who controls the infrastructure? Who gets to participate? Who gets excluded? Where are the points of failure? Who decides what counts as trusted? Can communities maintain their own systems? Can ordinary people understand enough of the infrastructure to control it? And what happens when the trusted intermediary fails?
These are not only technical questions, they are questions about power. The #openweb should not become a place where security means handing more control to increasingly centralized technical institutions. We need a different balance: encryption where it is useful, open standards wherever possible, decentralized infrastructure, transparent processes and multiple forms of community trust.
The criticism is of the assumption that one technical solution should become universal without considering the social and infrastructural consequences. Security should protect the #openweb, not become another mechanism for closing it down. That is the #4opens challenge and why the debate about universal #SSL is ultimately not just about SSL, it is about what kind of web we are building.
