• 0 Posts
  • 72 Comments
Joined 2 years ago
cake
Cake day: July 9th, 2023

help-circle
  • For media to endure, whether we’re talking years or millenia, you need to answer three questions:

    • What to record it on.
    • Where to store it.
    • How to encode it.

    The first is, perhaps, the easiest to answer, we have cave paintings from the stone age, velum and parchment that have lasted thousands of years, clay tablets that have similarly endured and various other historical artifacts that could be considered ‘media’. Alternatively, there are more modern techniques, such as etching into plates of non-coroding metal or other substances, or encoding in stable chemical structures such as DNA. Each approach has different benefits, but largely depends on the second question, where to store it?

    Storing the media is the next question, and the answer is going to depend on both what media you’ve chosen and how long you want it to last. Somewhere dry, solid and geologically stable probably makes the most sense, but it also needs to be accessible to those you hope will find the information later. The Voyager disks are a good example of long term storage that will probably outlast the human race, but they’re not exactly handy to retrieve. The same goes for the various efforts to send archives to the moon; they’re more for posterity than use. Finding, or digging, a tunnel in a bedrock type mountain, far above current, or expected, sea levels is probably a good bet. Don’t forget to record how to find the repository, and find a way to keep that knowledge available. That could be a record in another repository, or maybe engineered into the landscape such that signs point to it.

    The last question is how to encode the information. If you’re aiming to store the information for an extreme duration, you have to assume the entity finding it will have little or no cultural, technological or language connection with you. Pictures may work, we’ve learnt a lot from stone-age cave paintings and Egyptian tomb paintings, but they can only convey so much. For textual information you’re probably going to need multiple layers, the first being illustrated and readable without special equipment or techniques, and showing how to access the latter layers. The next layer should include information about how to read the rest of the layers (do you need magnification? If so, how do you do that? Have you included a lens that could be used? Do you need special illumination, or other techniques? How should the reader do that?), information about the language(s) used (perhaps a Rosetta Stone type artifact to help translate if they know any of the languages) and information about things like the units used (how long actually is a metre? What is a second?). The next layer would explain any envoding used for the rest of the information. If it’s binary stored as pits engraved in stone, or DNA base pairs, or holographically stored in metal plates, how do you extract the data, and how do you convert the naughts and ones to text for example. You must assume the entity processing this has no common base with you to work from, so everythis must be explained in detail. Finally you can store the information you actually wanted to store in the final layer.

    These concerns hold whether you’re trying to store information for millenia or just a few decades. For instance, if I handed you an 8" floppy disk containing a Wordstar file, could you read it without more information? Even once you’ve found an appropriate drive (very rare now-a-days) and a machine that can use it (likewise) you need to hope the disk has been stored appropriately.

    If you’re trying to store information to be accessible to humans over a timespan of no more than a few lifetimes you’ll probably be better served by arranging for it to be reencoded and tranferred to new, modern, media every few years.



  • The problem with releasing them on day one is that you then can’t gather more. If you’ve only just exposed the edges of the malfeasance you need time to get the rest before exposing it. Go too early and the rest of the evidence can be destroyed, covered up or those holding it coearsed into silence.

    Having a dead man’s switch is a way to ensure whatever you’ve gathered gets released if you’re no longer in a position to gather more. As such I disagree with the poster about making it public knowledge before release. Keep it secret until you have everything, then release it.


  • Trying to avoid using any arithmetic operators, and sticking just to binary (extending beyond 16 bit unsigned ints is left as an exercise for the interested reader):

    #!/usr/bin/perl
    
    # This increments $i
    
    my $i=1;
    print "Start: $i ";
    
    if (($i & 0b1111111111111111) == 0b1111111111111111) {die "Overflow";}
    if (($i & 0b0000000000000001) == 0b0000000000000000) {$i=(($i & 0b1111111111111110) | 0b0000000000000001);}
    else
    {
            if (($i & 0b0111111111111111) == 0b0111111111111111) {$i=(($i & 0b0000000000000000) | 0b1000000000000000);}
            if (($i & 0b0011111111111111) == 0b0011111111111111) {$i=(($i & 0b1000000000000000) | 0b0100000000000000);}
            if (($i & 0b0001111111111111) == 0b0001111111111111) {$i=(($i & 0b1100000000000000) | 0b0010000000000000);}
            if (($i & 0b0000111111111111) == 0b0000111111111111) {$i=(($i & 0b1110000000000000) | 0b0001000000000000);}
            if (($i & 0b0000011111111111) == 0b0000011111111111) {$i=(($i & 0b1111000000000000) | 0b0000100000000000);}
            if (($i & 0b0000001111111111) == 0b0000001111111111) {$i=(($i & 0b1111100000000000) | 0b0000010000000000);}
            if (($i & 0b0000000111111111) == 0b0000000111111111) {$i=(($i & 0b1111110000000000) | 0b0000001000000000);}
            if (($i & 0b0000000011111111) == 0b0000000011111111) {$i=(($i & 0b1111111000000000) | 0b0000000100000000);}
            if (($i & 0b0000000001111111) == 0b0000000001111111) {$i=(($i & 0b1111111100000000) | 0b0000000010000000);}
            if (($i & 0b0000000000111111) == 0b0000000000111111) {$i=(($i & 0b1111111110000000) | 0b0000000001000000);}
            if (($i & 0b0000000000011111) == 0b0000000000011111) {$i=(($i & 0b1111111111000000) | 0b0000000000100000);}
            if (($i & 0b0000000000001111) == 0b0000000000001111) {$i=(($i & 0b1111111111100000) | 0b0000000000010000);}
            if (($i & 0b0000000000000111) == 0b0000000000000111) {$i=(($i & 0b1111111111110000) | 0b0000000000001000);}
            if (($i & 0b0000000000000011) == 0b0000000000000011) {$i=(($i & 0b1111111111111000) | 0b0000000000000100);}
            if (($i & 0b0000000000000001) == 0b0000000000000001) {$i=(($i & 0b1111111111111100) | 0b0000000000000010);}
    }
    print "End: $i\n";
    








  • A really rough calculation (and I acknowledge I could be somewhat off here) suggests that if you contribute for 40 years, and get around 5% interest per year, you’d need to put in an average of €10,000 per year to reach €1,250,000. Working out average salary progression through a working life is left as an exercise for the interested reader, but assuming you’re putting 10% of your salary into your pension, you’d need to be earning six figures to make that pension pot, so a drop to around €73,000 including the public pension could be hard to manage.

    As I said, not so much can’t retire, as can’t retire at the same standard of living, especially as annuity payments wouldn’t increase with inflation.


  • I agree that them having users’ phone numbers isn’t ideal. There are other identifiers they could use that would work just as well. However, both the client and server are open source, so you can build, at least the client, yourself. If you can content yourself that it does not leak your ID when sending messages, then you don’t need to trust the server as it does not have the information to build a graph of your contacts. Sealed sender seems to have been announced in 2018, so it’s had time to be tested.

    Don’t get me wrong, the fact they require a phone number at all is a huge concern, and the reason I don’t really use it much, but the concern you initially stated was addressed years ago and you can build the client yourself to validate that.


  • You’re correct that if you use the system the way it used to work they can trivially build that connection, but (and I know this is a big assumption) if it does now work the way they say it does, they do not have the information to do that any more as the client doesn’t actually authenticate to the server to send a message. Yes, with some network tracing they could probably still work out that you’re the same client that did login to read messages, and that’s a certainly a concern. I would prefer to see a messaging app that uses cryptographic keys as the only identifiers, and uses different keys for different contact pairs, but given their general architecture it seems they’ve tried to deal with the issue.

    Assuming that you want to use a publicly accessible messaging app, do you have any ideas about how it should be architected? The biggest issue I see is that the client runs on your phone, and unless you’ve compiled it yourself, you can’t know what it’s actually doing.




  • Whilst I absolutely agree it’s correct to be skeptical about it, the ‘sealed sender’ process means they don’t actually know which account sent the message, just which account it should be delivered to. Your client doesn’t even authenticate to send the message.

    Now, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address the very issue you’ve been pointing out. Obviously it’d be better if they didn’t have your phone number at all, but this does seem to decouple it in a way that means they can’t build a connection graph.



  • notabot@lemm.eetoYUROP@lemm.eeTax The Rich EU-Petition Update
    link
    fedilink
    arrow-up
    3
    arrow-down
    2
    ·
    6 months ago

    It’s probably not so much you can’t retire, but you can’t retire with an income that you’ll be comfortable on.

    A brief look suggests the average pre-tax wage in Belgium is around €3800, or about €45000 per year. Assuming you already own your home, or continue to pay mortgage payments at the same rate as before retirement, your pension needs to roughly match your income to not have a drop in living standards. A €1250000 pension pot will buy an annuity that pays a bit more than that, probably around €55000 a year, but assuming you amassed that in your pension pot you would probably have been on a higher than average salary, so it’s going to be close, and an annuity at that level wont increase with inflation, so your buying power drops over time, just when you’re more likely to need a care home or nursing support.


  • Look, I’m not attacking them over this, as you rightly said, it has plenty of other drawbacks and concerns, I’m just emphasising that Google do have a large degree of influence over them. For instance, Chromium is dropping manifest v2 support, so Brave pretty much has to do the same. They’ve said that, as Chromium has a switch to keep it enabled until June (iirc) they’ve enabled that, but after Chromium drops manifest v2 the most they can do is try to support a subset of it as best they can. The Brave devs may not want to drop support, but Google have decreed it will be dropped, so they end up dropping it and having to put in extra work to keep even a subset working for some period of time.

    If Brave gets even a moderate market share, Google will continue to mess them around like this as they really don’t like people not seeing their adverts.

    Ultimately it’s software, so the Brave devs can do pretty much whatever they want, limited by the available time and money. Google’s influence extends to making that either easier or harder, it much the same way as they influence the Android ecosystem.