ciprian_craciun

Like this product, there are many other products that focus on allowing one to back-up crypto-currency wallet seed phrases.

However, they all have in common the following major disadvantages:

* cost -- I can't see myself paying 50+/100+/150+ EUR for such a product, no matter how fancy is the marketing;

* they are meant primarily to encode ASCII passphrases, thus they have low information density; (most formats allow one to encode only one letter per column;)

* size / format -- I want something easily portable, not a large slab of metal, or a heavy paper-weight; (thus I've used the standard CR80 ID card size;)

Please see my reply to this other similar question:

> Looks like a new 2d barcode format to me. Why I would want this rather QR or any other that have redundancy built in?

https://news.ycombinator.com/item?id=44145202#44145279

Initially the bits were counted from 0, however this had two issues:

* using 0 as starting point would immediately trigger one's "computer science" instinct, and then it's uncertain which bit is actually bit `0`? the least significant one (as is in most cases), or the most significant one?

* by using 1 as the starting point, I hope would induce most people to just use it as a counter to number things in the "normal" (for westerners) left-to-right top-to-bottom, thus encoding / decoding is more "natural";

With regard to the puzzle idea: if the secret is quite sensitive, and assuming you split the card in say 4 parts, then coercing 2 of them to reveal their puzzle pieces, would reduce the brute force security of the secret from 128 bits to just 64 bits, which could be easily breakable.

With regard to the superimposed cards idea: this is equivalent with an "and" operation on bits, which in terms of entropy means that having one of the cards would reduce the brute force security by the amount of "0" bits (i.e. non holes in the card), because those bits can never be "1" due to superimposing.

The only safe way one can *easily* create multiple shares is through bit-wise XOR-ing:

* generate two random number, encode them into the cards, the actual secret is the XOR of the two numbers;

* K out of N is possible (I've seen some articles / StackOverflow posts), similar (though not quite exactly) to how RAID5 handles data;

The only one minor issue with this snippet (which I now just realized), is that if the secret has the first few bits on zero (i.e. anything that starts with something under `7`) then the resulting bits would be less than 128, and thus the user has to copy them from right to left (the least significant one) on the card from bottom-right upward.

Alternatively, one could use the `.rjust(128,"0")` to pad the bits, as in:

python -c '_secret = "d74ae47dc6f599d3f9cb847bd77d6b7c" ; print (bin(int(_secret,16))[2:].rjust(128,"0"))'

> Cool but wouldn’t you forget how to decode it after some time?

Not necessarily.

First of all there isn't much decoding to be done: if one follows the recommendation, and one uses the hex input variant as the password (or secret), then decoding is as simple as just writing the number is binary base. For example this password `d74ae47dc6f599d3f9cb847bd77d6b7c` can be recovered by simply starting a Python interpreter and writing `"%032x" % b1101011101001010...`

Moreover, by just providing the card to a computer science graduate / enthusiast, his first hunch would be to just try to convert the bits into a number and use that (either base10 or base16), perhaps after rotating / flipping the card (if he didn't knew about the alignment). (This can easily be deduced because there are 2 groups of 8x8 bits.)

(Alternatively, if one scratches on the card the URL `purl.org/999/1`, provided Archive.org, which currently hosts PURL.org, doesn't delete the links like Google just did with `goo.gl`. I intend to update the redirect from this PURL to a page hosted by Archive.org.)

> I.e. wouldn’t engraving regular characters be simpler?

The first, and perhaps greatest issue, is that not many people have access to engraving hardware. One could go to a shop and have the characters engraved, but then they wouldn't be secret.

So, the main purpose is this: how could one with minimal access to power or precision tools, create the sturdiest physical backup of a small piece of information.

Thus this proposal: with a sheet of metal, a nail, and a hammer, one could just encode the 128 bits by banging with the hammer on the nail through the sheet of metal. :)

If the CNC machine is not connected to a network, and (I don't know much about CNC, but I do wonder) if one can provide a generic program, then just fill in the parameters before execution, right at the machine, the secret would be confined to just the CNC machine.

Regardless, provided the CNC machine is not networked, and provided it doesn't have any solid state (only RAM), one could perhaps load a large job to overrite the previous one.

Although, perhaps the CNC machine could be used to just provide templates, with small indentations for where the holes could be punched, and additional engraving to provide a link to a document on how to use the card in case of disaster recovery.

This is how much I could pack on a standard (CR80 ID) card sized plate, while still being able to punch the holes without power (or precision) tools. (The aspect of ease of creation with household items was paramount for my design.)

There is also the problem of long term durability. Not being a construction engineer, or metallurgist, I have no idea what is considered "survivable" in case of an unlikely accident (such as fire, flood, crash, etc.), especially if one uses aluminium as the material. The more holes, the smaller the holes, I think the less likely chance they wouldn't degrade easily if not treated with care. (Aluminium is cheap, easy to work with just a cutter, screwdriver, and ruler.)

Moreover, 128 bits is plenty enough for encryption purposes. The AES standard uses key sizes of 128, 192 and 256 bits, but at the moment even the 128 bit keys provide plenty enough security.

Thus, if one needs to store more than 128 bits, one could just use a standard encryption tool like Age or GnuPG, and backup just the password. (The encrypted file could be mirrored all over the place without fear of brute-forcing.)

There is:

* press `reset` (to clear the checkboxes);

* press `tab` (to select the first checkbox);

* if the current bit is `1` (i.e. there is a hole in the pattern), press `space`;

* move to step 2 (i.e. press `tab`);

Indeed, this is another use case I've had in mind. (Protect a X25519 private key, and use the public key to encrypt against, without the need to have the private one online.)

However, the current scheme supports only 128 bits, thus requiring two cards per X25519 secret key. (One could of course, extend the sheet to another four blocks.)

Alternatively, one could do either one of the following:

* with the help of `age` (which uses X25519 keys), create a private / public key pair, and use a random secret as the private key password;

* given how X25519 secret keys work (i.e. almost any 256 bit random number, after some tweaking would do), one can just create a random 128 bit number, backup like described here, then to get to a X25519 key, use something like `HMAC-SHA256(key="00bbcc...", message="description of key")` to get the cryptographic material for the X25519 key; (thus one could have an infinite supply of X25519 keys, starting from just a simple 128 bit secret;)

(This second scheme, might reduce the strength of the resulting X25519 keys, however I doubt they can be broken, given the requirement to brute-force the HMAC-SHA256.)

Besides the issue with printing and paper longevity, another issue with QRCodes is that you can't easily convert them back to data without a proper application that implements the decoding algorithm, and thus you need to extend your trust to the application you use to recover the data.

However, with the proposed format (which is in fact just the oldest storage technique in computer history), one can just use a pen and paper (or any dumb 70s calculator) to easily convert the backup into something usable.

For example: group 4 bits together, and compute `b1*8 + b2*4 + b3*2 + b4` to get the index of a hexdigit; write that down choosing between `0-9a-f`; move to the next group; and that's your password.

Provided that the information one wants to keep safe is sensitive and important long term, there are two main issues with printing (either text, QRCode, or anything):

* (paranoia) can you trust your printer not to leak the secret? (either in local memory, or to send it to its cloud mother-ship?) you can encrypt your information and print that, but then you are back to square one: where do you backup the password;

* and most importantly, long term resilience: given that with normal printers you can only print on soft materials (like paper, or perhaps plastic), they won't last floods, fire, and other unlikely events; (even if one laser etches some information on a steel sheet, I don't know how resistant to abrasions it is;)

However, by actually drilling holes into a metal sheet, the only way to permanently make the data irrecoverable, is to destroy the object completely.

Software performance, which translates into CPU/memory/disk resources, are only one aspect of the costs incurred by crawling bots, and fall under the unmetered / virtually infinite category. However, there are also the metered resources, that do translate (after a certain threshold) into monetary costs: network bandwidth.

Thus, regardless how well one optimizes his site delivery (static site, minimizing, CDN, caching, etc.) a stampede of bot crawling does in the end become a DDoS, which if it doesn't take down the infrastructure, it might leave a deep hole in one's budget.

For example, for one of the sites I manage, I get daily peaks of ~300 requests per second measured at the backend, for a site that already employs heavy caching (both client-side, CDN, and even server-side). This wasn't so a few months back, and the site didn't just jump in popularity.

I don't see how respecting one's rights (in this case one's copyright over his own works) leads to having revoked the right to buy books.

I agree that it is sad to see many online book stores moving from "selling" to "renting". But that is a completely different problem.

As a personal note, I know the pain of not being able to access scientific papers because they were behind paywalls, and I had to search for drafts to be able to read them. But that model was well in place circa 2010, thus it's and old tactic applied to a new field: books (and others).

Unfortunately no purely technical solution works. As I've said in the end of my article:

> We need to support the case when a person wakes but-naked in a corn field, suffering from complete amnesia, and remembering nothing about himself. Today, such a person has a chance of getting his identity back, but in a pure technological world, "the computor just says no!"

----

Regarding the various European ID initiatives: they might seem a good idea, but they don't actually work in practice: for better or worse, our internet solutions seem to have settled on email as the de-facto identification system. Are any of these EU ID initiatives completely interoperable with the email system? If not, they are useful only for purely official interactions with the government, and solve nothing outside of that realm.

Also, because most such ID initiatives are actually X.509 tokens that work solely on Windows, with Adobe products, they are beyond useless...

(Let alone that one costs ~50 EUR per year in my country, Romania...)

[Post author here,] thanks for nailing it! I want anyone to be able to choose any of these two extremes ("right to be forgotten" and "right to be remembered") or anything in between.

I want to be able to configure my Discord or Slack "profile" to have all my messages automatically deleted after say 2 months. But at the same time I also want my email address to be permanently available (even after I die) because it's registered in so many places, tied to so many important things, so that if Google decides to erase me I'll be in a lot of pain...

And although I do use a *payed* GMail account, I do it mainly because I trust them more from a security point of view than I trust myself. However I don't trust them not even 1% not to screw me over if the accountants say it's more profitable to drop GMail...

At the same time I don't trust the government not even 1% not to screw the security of such a system, or not try to misuse it for political gains. But, I also don't see any way out of this situation with the technology, society, economy, and judicial system we have right now...

UTF-8 is both "binary" and "text" at the same time. :)

It's binary because the UTF-8 standard states how each Unicode code-point (i.e. character) is to be translated into a series of bytes.

But, because each (correct) UTF-8 byte sequence can be translated back into a Unicode code-point sequence, you can see it as text also. :)

(BTW, from my knowledge, UTF-8 doesn't specify a canonical encoding of Unicode text, thus for cryptographic purposes, especially signatures, perhaps one should treat it with care.)

The main highlights (for me) are support for `backup --read-concurrency` to control the I/O pressure on the underlying file-system and disks and `backup --no-scan` which also helps. (I'll have to test these options myself, plus the compression from `0.14`.)

The other highlight is the `rewrite` command which allows you to remove (or include) files in a former snapshot without a complete re-backup.

Yes, the Cloudflare web-analytics does require JavaScript.

With regard to no-JavaScript sites I understand; and for example the only JS on my site is the one for GoatCounter and Cloudflare web-analytics. GoatCounter does fallback nicely in case of no-JavaScript, meanwhile Cloudflare just doesn't work.

However, with regard to Cloudflare web-analytics, given that I already serve my site through them, there is no privacy lost by also using their analytics.

GoatCounter is good for assessing a long-term picture regarding readership, meanwhile CloudFlare is good for assessing performance issues.

Also note that if one registers a domain with Google for their webmaster tools (previously called Search Console?), although one doesn't use any of the Google services on the site, just because your visitors are using Chrome you can get performance metrics that way... So that's that about privacy... :)

No, with Cloudflare you can use for free the "web analytics" product; you can even use it for any site, not only those hosted at CloudFlare. (Perhaps what you've seen is the "cache analytics" or "traffic analytics" which indeed are payed.)

(I use it "web analytics" on my own site thus I can confirm that it's free.)

You could also just throw a CDN in front of Netlify (I do this with Cloudflare) and it will be extremely hard to reach that limit.

> [...] the article somehow concludes that bringing your own server with the right configuration is not an option.

[the author here] On the contrary, it is an option to fine-tune your web-server configuration to put all the right headers in the right places. (I usually do this from HAProxy and just ignore the web-server.)

However, the point I was trying to make in the article is that where these headers are configured is divorced from the content itself lives. I can't look at a HTML file and easily say "when the browser will hit this resource these are the HTTP headers that will be sent in the reply"; I need to execute in my mind the web server configuration logic to get that.

Thus my proposal is to move back (some of) the headers where they belong: as meta-data right besides the actual resource.

> Building an origin server for a CDN is a different task to building a regular server. The focus for cached resources is getting the byte size down, not serving a billion requests at once. The CDN can do that.

I think this put perfectly in words what I've believed for some time, but failed to compile into words...

However, having once you've gotten your cached resources down to the smallest size, you can now also optimize for serving a lot of them at once. :)

[the author here] Indeed I mention Cloudflare quite a lot, and that is for two reasons:

(A) If you do want to have a performant website (be it static or dynamic) you do need a CDN with edge caching; else the physics with it's insistence on a cap for the light speed will put a minimum theoretical latency of 25ms say between Bucharest and Toronto, which in practical terms translates towards at least 100ms one way, or 300ms just to establish a TCP connection, and around 500 for a complete TLS handshake... And no amount of bandwidth can solve that.

(B) Cloudflare is the only free choice that allows you to use your own domain and that doesn't impose any (published) limits on your usage. If you know of other CDN providers that give you this for free please let me know and I'll add their link to the article.

You could just use GoatCounter <https://www.goatcounter.com/>; it's simple to deploy it yourself (it's open-source), but it's also free to use it hosted, and it seems to be quite privacy friendly (if one could call a web analytics solution as such).

If you are already using CloudFlare, they have a (free and) simple enough web analytics solution. (They say they are also privacy friendly, but given it's not open-source you can't check.)

As with static hosts that provide HTTP logs, perhaps they are, but certainly they won't be for free, as log shipping (from the edge where most hosted solutions cache things to the aggregator) and then storing those isn't quite that cheap...

> Worth noting that the incoming younger generations can't and don't into file systems. [...] We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer.

[the author here] The article is not about misunderstanding file-systems.

As I've commented earlier on a different thread, <https://news.ycombinator.com/item?id=32733825>, the problem is that when it comes to performance and jumping through the hoops the internet gatekeepers (i.e. the search engines) have set out, just dropping some files somewhere the web-server can pick up isn't enough; there are additional tasks that can't be easily performed with files-on-the-disk approach.

> Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect?

At least with regard the with/without slash redirects there is value in these: sometimes the user copy-pastes the URL but forgets the final slash, sometimes the application he is using for bookmarking, sharing, etc. drops the slash; sometimes even the site owner forgets be consistent. Thus having those redirects in place means not having dead links pointing to your site.

With regard the `.html`, with and without, it's a matter of taste... However, the same point applies, perhaps you've been inconsistent along the years, thus having redirects saves the dead links...

However you are right about the "canonical" URL: for search engine purposes, having a single page serving the content, and the rest being redirects, is kind of essential. (Or at least having a `<link rel="canonical" ...>` if not a redirect.)

> Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong.

It is when you don't want dead links. :)

[the author here] Indeed didn't mention anything about the shared webhosting solutions, just as I didn't mention anything about S3 + CloudFront, or Backblaze B2 + a CDN in front, or Cloudflare + WebWorkers, or AWS Lambda, or any other thousand ways to do it... (Like for example there is <https://redbean.dev/> which I find just so intriguing, and not far from my own <https://github.com/volution/kawipiko> proposal.)

Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.

It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.

The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:

* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like <https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)

* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;

The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.

[the author here] Well, the article does point in the last section "Putting it in practice" to my own implementation <https://github.com/volution/kawipiko>. :)

> fasthttp doesn't implement HTTP/1 correctly

Could you point to an issue describe such an improper behavior?

> doesn't implement HTTP/2 at all

Or HTTP/3; and most likely it won't implement HTTP/4 (after the HTTP/3 fashion dies out). There is an issue about this on `fasthttp`'s repository: <https://github.com/valyala/fasthttp/issues/144>

And I'll quote here what I've said there:

> Having experimented in my kawipiko static server based on fasthttp with both HTTP/2 (based on the Go's implementation) and HTTP/3 (based on an experimental available library), I continue to believe that perhaps HTTP/2 and HTTP/3 is a job for some other component of the infrastructure, be it a CDN or even a local HTTP router / load-balancer such as HAProxy.

Thus if one needs HTTP/2 or HTTP/3 in order to reap their performance benefits, then using a CDN that actually supports these is the best approach.