Sun, 16 Oct 2022 07:47:29 EDT
Toward A New Web
HTTP is braindead. The surveillance web is evil. Let’s replace both. I have written two servers as proof-of-concept of how it can be done.
Multifile is a secure, multiplexing, event-driven TCP file server that has only the functionality that a client needs to pull down files and directory listings from a server. A client specifies one or more paths in a single request. The server delivers responses serially or multiplexed. Files have filename suffixes that are IANA-registered for specific data types. The only means of content negotiation are the ability to request ranges of bytes from files and the ability to conditionally request data from files with a modification time more recent than a specified time. Time values are UNIX time values with a 1 second resolution.
Libmessage provides a generic, secure, event-driven, message-based TCP server for use in apps. Clients and servers exchange messages of arbitrary size and structure. The library handles message discrimination. Clients connect directly to servers. The file server is not an intermediary. Apps use persistent connections to eliminate the need for cookies. The intent is that servers can timeout their connections, and clients can store credentials and automatically re-authenticate, but clients cannot store state of any other kind, nor can they make credentials available to domains other than the credentials’ origin domains.
The intent for the hypertext client is that it render content in a standard visual style across the new web. Users without design skills can craft attractive sites.
You make money on the new web by selling products or services and not by trading surveillance data. Advertising cannot appear interspersed with content. Advertising appears in a separate pane that cannot be a pop-up.
Update March 13th 2024: The file server knows nothing about the hypertext service. That service is an abstraction maintained by the browser. The browser enforces same-origin policy. The current mechanism of the server using the Origin: or Referer: header only works with well-behaved browsers. Why not let the browser do the job?
A server’s cross-origin policy is specified in the file named .access.txt that specifies open access or same-origin access for file types by filename suffix. Same-origin is the default, so the access file only specifies entities with open access. In the absence of an access file, all entities are considered same-origin access. An example .access file:
.html .pdf .txt .tar.gz .tgz
Consider a cross-site request forgery for a service that uses a persistent connection without cookies. The CSRF URL arrives via email. The user clicks the link, the browser opens a new tab and connects to the server. If the service is a public service, the transaction proceeds. If the service is a protected service, the server discards the request and presents a login form. The browser automatically fills-in the form without enabling the forged request. If the client has a pre-existing open connection with the service, the browser is forbidden from submitting the request over that connection.