Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that.
But one step at a time I guess :)
Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that.
But one step at a time I guess :)
Typically a client-side bridge would run on your current device, so if it can't connect to the server, then you're probably out of connectivity anyway so it's not a disaster.
> or that the hypothetical API of that proprietary service must be ready to be accessed from multiple clients at once
I'd expect that the gatekeeper's API would allow access from multiple clients, just as the normal clients would.
> Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that.
The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target. Hence looking for safer places to run it - e.g. buried inside your phone, where if the phone is compromised, you're already toast.
I'm just cynical enough to believe those gatekeepers would totally accidentally make their API as cumbersome to use as possible while still technically meeting the requirements. ;)
> The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target.
The usual cautionary disclaimers when self-hosting apply. But probably still a less juicy target than the hypothetical bridge provider TFA outlines. Someone offering Whatsapp bridging as a service is quite a nice attack target.