Pup Biru

i’m certain all of us that haven’t bought into any of this will be fine and rich hedge funds won’t buy up property and stock from people with no options forced to sell at prices far less than what they paid

that’s correct. they want modern business video conferencing, which is a very different prospect than 1:1 messaging, or even personal group messaging. i’d argue that there are more of these available than there are business conferencing!

please don’t lump signal in with whatsapp 🤮 that kinda talk makes people think they’re largely the same (especially with the bullshit muddy water of whatsapp using signals encryption), and we have enough trouble trying to convince people to use secure alternatives already… between the open client, reproducible builds, and local key integrity they are truly not even remotely in the same league

these are different problems now though… sure you can make calls to existing VOIP endpoints and PSTN devices, but that’s not what they’re trying to implement: they’re trying to implement group video conferencing, which WebRTC was built for

i’ve already linked the docs that state that native windows containers exist. whether or not specific images exist is not relevant

WSL, Hyper-V and Windows Containers are all options

they have to be built specifically for windows (of course the kernels are different, so the binaries are going to be different) but you can run Windows native applications on Windows kernel with a different implementation of containers using the standard Docker CLI and interfaces

Cgroups are just 1 (by far the most common) implementation of the container backend

to use SIP, in a web browser, you need to use wrapper of some kind (probably WebRTC-based)… you can not directly use SIP in a web browser. given that web browsers are likely a hard requirement, it makes no sense to use 2 separate standards

SIP is the wrong choice for this project, and any greenfield project wishing to integrate web browsers with no hard requirement to support SIP devices

yes but you need a server in the middle which is just a huge waste of resources when you could just use webrtc with basically no down side

it is not. meta controls the keys. that’s how they’re accessing the messages

the article says they can access any message, from any user, from any time period, even deleted, instantly

to make this a client-side exploit would mean that messages would need to be constantly sent in the clear (not targeted per user) for years now… and someone would have noticed that

we know meta holds the encryption keys: that’s a known fact… it’s much much easier for them to simply decrypt everything they store

simpler than that in most likelihood… meta is the key holder so login and password recovery is simpler (or at least that’s the excuse they give): you login, they send you your key, which they can also access (and decrypt your messages) whenever they like

this isn’t a client-side exploit. this is the fact that meta controls the encryption keys. the mention “widget”, but that’s not a widget on your device; they say it’s a widget on their workstation - whatever that means. i’m thinking it’s something akin to raising a ticket which triggers a workflow to remote install an app on a work device (a process common at large enterprises)

worker need only send a ‘task’ (i.e., request via Meta’s internal system) to a Meta engineer … the worker’s workstation will then have a new window or widget available that can pull up any WhatsApp user’s messages based on the user’s User ID number … Once the Meta worker has this access, they can read users’ messages by opening the widget; no separate decryption step is required

that’s incorrect. with whatsapp, your keys are stored on meta servers (the same as things like imessage). they can simply decrypt them whenever they like, just like being signed in as you. it’s completely invisible to your client

it’s not even that: they just hold the keys so can simply decrypt your messages with out your clients intervention any time they like

SIP uses different signalling protocols amongst other things than WebRTC, and i imagine browser support is a hard requirement

plain text is probably the wrong phrasing, but apple does control all your keys

no matter who it is, the key holder can always read your data

sentiment yes but there are FOSS tools to store things in google/microsoft/apple drives or the various object stores (s3, backblaze, etc) that work just like the various drives, but with end to end encryption where you control the keys

in general just don’t let anyone else control your encryption keys… where you store things is almost beside the point

bonus: encryption means they can’t dedupe/compress so you get to waste their money

what kind of monster writes a script without a shebang?

i thought this too, and i just started actually working with it and DAMN is it fast… i agree that it’s kinda a technical “what the fuck are you doing?!?” but… yeah… i can’t even really explain why

absolutely! similar is true of node in v8 (though python imo is far more mature in this regard) and probably most other languages

exactly why things like numpy are so popular: yeah python is slow, but python is just the orchestrator

further to that, “demonstrably worse for the planet” i’d like to debate: considering a huge amount of climate science is done with python-based tools because they’re far easier for researchers to pick up and run with - ie just get shit done rather than write good/clean code - i’d argue the benefit of python to the planet is in the outputs it enables for significantly reduced (or in many cases, perhaps outright enabled) input costs

yeah we have a “supply charge” that’s ~$1/day on top of that base rate too, so roughly the same situation :(

we’ve got this crap because of privatisation so it’s not likely to change any time soon.

i hope your energy prices come down when energy things stabilise in europe!