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.
For point 1 I recall the creator of Age, Filippo Valsorda suggesting something similar:
>The .age-recipients files also include the public key for an offline disaster recovery key. I generated the key with age-keygen, encrypted it with age -p, printed the ciphertext as a QR code, and wrote the random passphrase in pen. This is a bit convoluted, but I don’t trust printers. All this was done in a tmpfs, so nothing reached storage. Only had to do this once, and have been using that key as the anchor for all my disaster recovery data.
https://words.filippo.io/dispatches/passage/
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).
[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...
What do you think about Decentralized Identity (DIDs - https://www.w3.org/TR/did-core/)? With it, you can have several identities and easily generate new ones when needed (but you probably need to have a single, government-recognized identity for the real world).
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...)
I am sorry to be blunt but you seem to be misinformed.
> We need to support the case when a person wakes but-naked in a corn field
DIDs can have a controller, and the controller can be your "real-world" identity... If that is government-issued, you can recover it the same way you recover your identity today in case you lose all your documents. After that, you regain control of all your other DIDs (which you keep to ensure anonimity, e.g. you can have a different DID for each service you sign up with).
> 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.
That's plain wrong. It's already possible to use DIDs to sign up with any business you want, though admidetly as the specs are still in flow, there's no much out there other than lots of PoCs - but those already show it's absolutely possible and desirable to use DIDs instead of email addresses... private accounts are an actual liability for most businesses (except those selling your data for marketing purposes, of course).
> Also, because most such ID initiatives are actually X.509 tokens
Where did you get that impression?? There are several DID methods and the most popular so far have nothing to do with X.509 certificates (I think that's what you meant by "token"?). Many are using JWKs (JSON Web Keys) as most alternative solutions do. Check the current registry of DIDs here: https://www.w3.org/TR/did-spec-registries/#did-methods
FWIW, ironically and counter intuitively, "the right to be forgotten" achievement is unlocked with the combo of RealID (or equiv) and "translucent database" techniques.
(Over simplifying: just like properly salted and hashed password files. Lose the password and you cannot retrieve the encrypted data.)
Using your essay as a starting point, I'll start pondering what a future "right to be remembered" system might look like. Both technically and legally.
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.)
AFAIK, overlong encodings are not valid UTF-8 [0] which means the canonical encoding of each unicode code point is clearly defined as there is only one valid encoding. That still leaves higher level Unicode shenanigans, but every Unicode encoding is going to have those. And of course, what applications accept in practice is an entirely different issue.
While the point on overlong encodings is true... there are multiple ways to do composition[1]. brown-skin + high-five or high-five + brown skin... etc.
Part of why it's a good idea to normalize input before password hashing, as an example... It will likely become more common over time to use emoji as passphrase input.
Yes, composing characters are what I was referencing with "higher level Unicode shenanigans". This doesn't stop there though - many people would say that "а" and "a" are encodings of the same character even if Unicode thinks otherwise. All that is above the concerns of UTF-8 though, which only cares about encoding code points into byte sequences.
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.
> [...] 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.
But do you really need different headers for different resources for a static site? I can imagine a distinct "downloads" folder maybe, but not much more.
> 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. :)
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.