Keyoxide: aspe:keyoxide.org:KI5WYVI3WGWSIGMOKOOOGF4JAE (think PGP key but modern and easier to use)

  • 0 Posts
  • 138 Comments
Joined 2 years ago
cake
Cake day: June 18th, 2023

help-circle








  • You want a truly multinational organization responsible for it, nothing that can be controlled by a single nation, even one as (ex)influential as the us.
    Something based on the UN perhaps.

    Combine that with making internet access a human right, to stop denying connectivity outright.

    Ideally then you could’t enforce meaningful censorship, but more realistically you would route regions to their respective governments servers so they could censor as before on their territory.
    That would not guarantee free access to the internet to everyone, but should be an acceptable compromise to basically all nations.

    After that, other doubting nations could still pull their own constellation, nothing is stopping that.

    I would love if the internet program was uncensored, but that probably needs personal circumvention same as now, if such a program wants any degree of success.


  • Starlink should not just be nationalized but internationalized.
    It is internet for everyone on earth, not everyone in the USA.

    Every larger nation deploying their own constellation would be a pointless waste of resources, and every smaller nation having to find reliable partner-nations to tap into for that internet access would inevitably lead to people ending up without access due to political games.

    Low orbit satellite constellations are the perfect candidate for sharing, they would literally sit unused over most of their orbits otherwise.


  • Can’t you always attempt uploads until they bypass arbitrary filters and then report-snipe on that?
    How would a content-based filter prevent this if the malicious actor simply needs to upload correspondingly more images?

    I think the sad reality is that the only escape here is scale. Once you have been hit by this attack and been cleared by the 3rd parties, you’d have precedent for when this happens again and should hopefully be placed in a special bin for better treatment.
    Scale means you will be fire-tested, and are more likely to receive sane treatment instead of the ai-support special.


  • Was about to say this.

    I saw a small-time project using hashed phone numbers and emails a while ago, where assume stupidity instead of malice was a viable explanation.

    In this case however, Plex is large enough and has to care about securiry enough that they either
    did this on purpose to make it sound better, as a marketing move,
    did not show this to their security experts,
    or chose to ignore concerns by those experts and likely others (turning it into the first option basically)

    There is no option where someone did not either knowingly do or provoke this.


  • It isn’t usually. If it was, the server-side function wouldn’t need a constant runtime at different-length inputs since the inputs would not have differing lengths.

    The problem with client-side hashing is that it is very slow (client-side code is javascript (for the forseeable future unless compatibility is sacrificed)), unpredictable (many different browsers with differing feature-sets and bugs), and timing-based attacks could also be performed in the client by say a compromised browser-addon.

    For transit a lot of packaging steps will round off transfer-sizes anyhow, you typically generate constant physical activity up to around 1kB. Ethernet MTU sits at ~1500 bytes for example, so a packet of 200 bytes with a 64 char password or a packet of 1400 bytes with a 1024 char password containing some emoji will time exactly identically in your local network.


  • You can easily get the hash of whole files, there is no input size constraint with most hashing functions.
    Special password hashing implementations do have a limit to guarantee constant runtime, as there the algorithm always takes as long as the worst-case longest input. The standard modern password hashing function (bcrypt) only considers the first 72 characters for that reason, though that cutoff is arbitrary and could easily be increased, and in some implementations is. Having differences past the 72nd character makes passwords receive the same hash there, so you could arbitrarily change the password on every login until the page updates their hashes to a longer password hashing function, at which point the password used at next login after the change will be locked in.