• 0 Posts
  • 121 Comments
Joined 3 years ago
cake
Cake day: August 6th, 2023

help-circle
  • For UDP you’d also usually reencode packets as http3 warp ones […]

    Is this similar to when you mask it as webrtc?

    Sorry I probably meant QUIC not warp. It is related, I think webrtc now usually uses quic, so masking as quic or webrtc are probably synonymous, but honestly I don’t know enough about the details to say for sure.

    Something other than DAITA?

    I know people in Russia are reporting Mullvad gets fully blocked, so I don’t think DAITA is enough. As @chimp@lemmy.dbzer0.com mentioned, Hysteria is more in the right direction, though in more modern iterations/forks and together with another layer of obfuscation.
    I don’t generally like to shout out names too much, since popularity among those that don’t need the tools makes them more cracked down upon for people that do need them. So I’ll just say that for the less obfuscated but more responsive route via rtc you use an updated hysteria as the outer layer, containing a fully homogeneous encrypted stream from a tool named after a reptile.

    As per the GDPR or something else?

    Mainly Net neutrality rules. Net neutrality just barely allows basic DPI, though it already heavily restricts what ISPs can actually do with that inspection. Wikipedia: EU net neutrality violations. Note that the 2007 case there happened well before regulations were strictened.


  • Size and timing of packets. Protocols generally have consistent patterns, so say always 6 packets with the last 3/4ths filled. Then some keepalive at regular intervals (i.e. tracker updates), establising new peer connections, …
    Luckily this deep inspection is illegal for isps in the eu.

    Russia, China, and Iran are using the patterns to effectively block all normal VPN and proxy protocols. There, people need special tools that send fake packets, randomize timing, and split and group packets into different sizes. All of course decreasing speed and increasing latency.
    For UDP you’d also usually reencode packets as http3 warp ones so it looks like a video call.
    Then the other end needs the same tooling to restore the normal packets.

    Obfuscating it would be possible if necessary, but it’s better when you aren’t forced to maintain such an obfuscation stack.




  • There’s no way that’s a german accent. There may be some human some ai parts, but that does still call into question if they made sure everything came out correct. Just a human translation from someone not familiar with every detail can already imply something wrong due to slight changes in wording if you are unlucky.

    And the main original issue was “if they used ai for the writing, what else did they use it for?”. AI is a sign of low quality, and with lots of 100% slop creations posted on this com I wouldn’t read that sort of thing without someone vouching for the quality of the source (Which I take it you do?).

    tldr Because of the ai slopocalypse I just don’t like being hit in the face by ai text from opening a random post.

    PS: would a human let this graphical issue slip through?

    I noticed that together with the presumed-ai text earlier, but chocked it up to mobile layouting. But it’s the exact same on desktop.








  • Understand on what level?

    The basic idea is that dbus is a type of communication layer and api.
    Services can register there and programs see their registrations. dbus can in theory then launch a service too, so things don’t have to run all the time.
    The idea is similar to having some known config file, that programs write to and that a service listens on or uses later. But dbus has more granularity.

    It also often runs the other way, with system components presenting info in dbus and programs using it, to adapt to user configuration.

    And let’s not even get into udev.

    Point here is that dbus could be implemented via a command and an sqlite database for example. The command checks the database and constructs the dbus state from it.
    But for likely performance reasons it isn’t, so this info is simply hidden in dbus, in ram, instead of being a file.

    You can access dbus via a socket file ofc, but it’s not like you can mount it.

    Even more confusingly, the internal ephemeral dbus structure with its apis and endpoints resembles a filesystem. In that way it is similar to the w!ndows registry, though not nearly as bad.

    so yeah dbus is most definitely not files

    edit: also there’s multiple dbusses, usually one per user and one for the system. Those two hold different apis and info. It’s just the same thing twice tho.








  • It’s android version dependent. Only 14 and up support 3rd party providers.

    Passkeys are supported on devices that run Android 9 (API level 28) or higher.

    On many devices, Credential Manager stores passkeys to Google Password Manager by default. Users can choose other password managers as its passkey providers in the System Settings on Android 14 or higher.

    Given the slowness of android version rollouts, this will be an issue for a long time.

    I also think supporting older androids is pushing apps to do it the “wrong” way and making it google specific.