• 0 Posts
  • 147 Comments
Joined 1 year ago
cake
Cake day: July 9th, 2023

help-circle

  • Interestingly, whilst Wikipedia does say that, the language in RFC 1591 (Domain Name System Structure and Delegation) only says:

    There are a set of what are called “top-level domain names” (TLDs). These are the generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two letter country codes from ISO-3166.

    Likewise, in ICANN’s PRINCIPLES FOR THE DELEGATION AND ADMINISTRATION OF COUNTRY CODE TOP LEVEL DOMAINS, they say:

    ‘Country code top level domain’ or ‘ccTLD’ means a domain in the top level of the global domain name system assigned according to the two-letter codes in the ISO 3166-1 standard

    In neither case do they actually limit two letter TLDs to being country codes, they only state that all country codes in ISO 3166-1 are ccTLDs. In the RFC, the author does suggest it is unlikely that any other TLDs will be assigned, but this has obviously been superseded with the advent of gTLDs. Thus I still consider it likely that the .io TLD will simply transition to being a commercial one, rather than a country one.

    Having said all that, it’s entirely possible I’ve missed some more recent rule that tightens this up and only allows two letter domains from ISO 3166-1. If I have I’d be glad of a pointer to it.



  • It’ll get eliminated as a country code, yes, but that leaves it available as a generic TLD. Seen as it will be available and is obviously lucrative, someone will register it and, presumably allow domains to be registered under it. Off the top of my head, I think it costs $10,000 and you have to show you have the infrastructure to support the TLD you register, so an existing registrar is the most likely. That figure is probably out of date, it’s been many years since I checked it, but the infrastructure requirement is the more costly part anyway.




  • Oof, that sounds rough. Are these the kids got hit hardest by the pandemic lockdowns? If so, maybe there’s a glimmer of hope that this is an aberration and next year will be a bit more 'normal ', if you can get through this year with your sanity intact. It’s got to be rough on the kids too, the ones who aren’t causing trouble must still be struggling to deal with itm and the ones who are just sound desperate.

    I enjoy teaching, or at least, transferring knowledge and experience, I’ll do it to pretty much anyone who sits still long enough, and I’ve been told I’m good at it, but you couldn’t pay me enough to teach a classroom full of kids all day, so you have my respect for that.

    Good luck, and I hope things get better for the kids and teachers everywhere.




  • notabot@lemm.eetoLinux@lemmy.mlVPS encryption
    link
    fedilink
    arrow-up
    15
    ·
    2 months ago

    It depends what you want to do with it. If it’s just for storing files/backups then encrypt them before uploading and make sure the key never goes anywhere near the VPS. If it’s for serving up something like a simple website, you probably care more about data integrity than exfiltration, so make sure you have the security, including selinux or equivalent, locked down, and regularly run integrity checks. If it’s for running something interactive, or where data will be generated or downloaded to the machine, you’re out of luck, there’s no even theoretical way of securing that against an adversary with that much access.




  • 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.