Hello everybody! In connection with the growth of blockages, including unreasonable ones, by the state, the description of the idea is offered to your attention, as well as a prototype of the settings of the site that is protected from blocking by a specific path and domain name. Ideas for blocking protection:

• with an asterisk
• at IP

will be outlined in other posts. Who cares about the topic, go under the cat.

Link

https://github.com/http-abs/http-abs/

Description of the idea

The protection principle is that each user receives a unique pair from the individual (sub) domain and the path prefix for viewing the site. Call this pair the agent identifier .

How does this protect against blocking?

• If the lock is limited by the path and / or the exact domain, then by sending an application to block such a path and / or domain, the lock operator will block only its own access, without affecting the interests of other users.

• When and if you, as a site administrator, find a blockage, you can exclude (say, replace with seals) the issue of disputed material at this address: this will not affect the delivery of the same material to other users.

• Local replacement of content will give you the opportunity to try to exclude the link from the list of locks, avoiding, for example, total blocking by domain name.

But how then to share links?

Easy. The agent identifier allocated to the user for viewing the site is stored in his cookies. The user simply shares the link from the address bar.

• If the user does not yet have the corresponding cookie, clicking on the link containing the identifier of another person initiates the process of allocating a new agent identifier, with a redirect to an individual material viewing URL that includes this identifier.
• If the user already has a cookie with an agent identifier, clicking on a link containing someone else’s identifier initiates a redirect to the individual material viewing URL for this user, with his own identifier.

Why save cookies?

To isolate the operator locks. If you are lucky, after several locks, it can even be identified.

Will this complicate the life of the user?

Not at all, literally nothing is required of him. He visits the site in the usual way, reads materials and shares links. In his life, only the appearance of the address bar changes.

Will this complicate the life of the server developer?

Maybe. It will not have to consider the path prefix and subdomain included in the agent identifier: they will be cut off by the handler at the first stage of processing the incoming URL. However, to make the process completely transparent, you may still have to work hard.

Can the lock operator bypass the insulation?

Of course. But it will be much more difficult for him to prove the need to block an infinite number of links to material formed by an intricate rule, despite the fact that the rules can even change to even more intricate ones.

The operator will simply block everything with an asterisk and IP address

Such a development of events is not excluded, but I want to consider these cases separately in another article. Perhaps together we will come up with something additional in the comments.

Implementation

Architecture

In order to make the process as transparent as possible, the code is concentrated in the front-end server nginx. This allows you to protect a wide variety of application servers with virtually no limits.

Since request processing will be very non-trivial, an additional package is used libnginx-mod-http-luathat implements the language luain the process of processing requests under nginx.

Additional terms

Ideally, the processing should be done so that the backend (uplink, application server) is not at all concerned about whether it was put under protection. He receives requests by URL, from which all elements of the agent identifier are removed (let's call such pure URLs ). In order not to redo the returned pages, clicking on a clean URL with the agent identifier cookie set causes a redirect to an individual URL.

The frontend does not store the state anywhere except for the agent identifier cookies.

No lines of javascript code involved on browser. Only the HTTP protocol is used.

Alpha Implementation Limitations

In fact, only proof-of-concept is implemented, which allows you to observe the actual operation of the algorithm. Many parts related to product packaging have not been decided: modularity, selection and verification of parameters, and so on.

For subdomains, a scheme with a fixed set of subdomains is selected, suitable for use in conjunction with a file hosts, without installing an additional DNS server.

The format of the path prefix is ​​predefined and consists of 32 digits at the base of 16.

Installed startup options

Launch parameters are set right in the code so far.

The set of subdomains (a, b, c) is set in a variable and can be extended.

The domain is set as example.com.

The backend is expected at point http://127.0.0.1:8000

conclusions

The growing threat of sudden blocking forces to prepare in advance and invent methods to protect owners of even completely loyal sites from them. Such protection is quite possible, does not require any gestures on the part of the user, and can be implemented by a quite modest amount of effort by the site administrator.