cultural reviewer and dabbler in stylistic premonitions

  • 67 Posts
  • 302 Comments
Joined 3 years ago
cake
Cake day: January 17th, 2022

help-circle














  • If copyright holders want to take action, their complaints will go to the ISP subscriber.

    So, that would either be the entity operating the public wifi, or yourself (if your mobile data plan is associated with your name).

    If you’re in a country where downloading copyrighted material can have legal consequences (eg, the USA and many EU countries), in my opinion doing it on public wifi can be rather anti-social: if it’s a small business offering you free wifi, you risk causing them actual harm, and if it is a big business with open wifi you could be contributing to them deciding to stop having open wifi in the future.

    So, use a VPN, or use wifi provided by a large entity you don’t mind causing potential legal hassles for.

    Note that if your name is somehow associated with your use of a wifi network, that can come back to haunt you: for example, at big hotels it is common that each customer gets a unique password; in cases like that your copyright-infringing network activity could potentially be linked to you even months or years later.

    Note also that for more serious privacy threat models than copyright enforcement, your other network activities on even a completely open network can also be linked to identify you, but for the copyright case you probably don’t need to worry about that (currently).








  • Regarding your browser-based thing: what are the specific capabilities of the “threat agents” (in your threat model’s terminology) which your e2ee is intended to protect against?

    It seems like the e2ee is not needed against an attacker who (a) cannot circumvent HTTPS and (b) cannot compromise the server; HTTPS and an honest server will prevent them from seeing plaintext. But, if an attacker can do one of those things, does your e2ee actually stop them?

    The purpose of e2ee is to protect against a malicious server, but, re-fetching JavaScript from the server each time they use the thing means that users must actually rely on the server’s honesty (and HTTPS) completely. There is no way (in a normal web browser) for users to verify that the JavaScript they’re executing is the correct JavaScript.

    If you run a browser-based e2ee service like this and it becomes popular, you should be prepared that somebody might eventually try to compel you to serve malicious JavaScript to specific users. Search “lavabit” or “hushmail” for some well-documented cases where this has happened.