3 ms·

I don't think that there is much of a TA benefit -- you make a request (and let's assume it's just a packet count/timing analyzer) and 10 packets burst out of y

I don't think that there is much of a TA benefit -- you make a request (and let's assume it's just a packet count/timing analyzer) and 10 packets burst out of your device to Mighty, then 10 packets burst out from Mighty to the destination. How is that not equally analyzable? > Both of these scenarios place equal amount of trust in service operator - the difference is in security is against other adversaries. This is where I would strongly disagree. With a VPN they can analyze your endpoints, but assuming E2E encryption, they cannot see your actual packets. Whereas Mighty is definitionally a MITM browser, they can see everything. Therefore you are trusting Mighty incredibly more than a VPN provider.

fulafel 5y ago
> you make a request (and let's assume it's just a packet count/timing analyzer) and 10 packets burst out of your device to Mighty, then 10 packets burst out from Mighty to the destination By my understanding, the web browser runs at the Mighty server farm and it's streaming it to you using a RDP or Stadia style system. So, it's more like you send 10-ish packets containing input events (like mouse motion and click) using the Mighty client protocol, and as a result the Mighty service does 150 web requests that happen due to loading the new web page (probably around 10k packets). While the page is loading, the Mighty service sends you screen updates that are again much different than the packets the Mighty service is receiving in response to the web requests. Yes, these can still be temporally correlated, even though the correspondence is much more distant than in the VPN case (where you can just observe the similar sized packets). But there's potential to fix it rather easily, by eg using chaff traffic to the client in idle periods, and/or by pulsing updates out to all users to the service in sync, etc.

fulafel 5y ago

> you make a request (and let's assume it's just a packet count/timing analyzer) and 10 packets burst out of your device to Mighty, then 10 packets burst out from Mighty to the destination By my understanding, the web browser runs at the Mighty server farm and it's streaming it to you using a RDP or Stadia style system. So, it's more like you send 10-ish packets containing input events (like mouse motion and click) using the Mighty client protocol, and as a result the Mighty service does 150 web requests that happen due to loading the new web page (probably around 10k packets). While the page is loading, the Mighty service sends you screen updates that are again much different than the packets the Mighty service is receiving in response to the web requests. Yes, these can still be temporally correlated, even though the correspondence is much more distant than in the VPN case (where you can just observe the similar sized packets). But there's potential to fix it rather easily, by eg using chaff traffic to the client in idle periods, and/or by pulsing updates out to all users to the service in sync, etc.