Hacker has to compromise the server Or the connection in between, unless SSL is satisfying that part of our threat model. then, for each connecting user, serv

Hacker has to compromise the server Or the connection in between, unless SSL is satisfying that part of our threat model. then, for each connecting user, serve malware javascript. No problem there, that's a core function of a server. It's a feature of MitM tools as well. What's more difficult is an attacker who wants to target only a few specific users. Meanwhile, external network of monitors, masquerading as real users, A nice idea, let me know when you get that implemented. detect that server is compromised and alert the admins who can take appropriate actions. That's always a fun conversation to have. Be prepared for denial, anger, bargaining, and depression before getting to acceptance. Monitor network: "We've found sometimes users are receiving the old version of the Javascript, you know, the buggy one? Particularly when certain key words like 'democracy' occur in the text." Site operator: "Oh, must be an old file on one of the servers." Monitor network: "We think it might be a targeted attack" Site operator: "Well, what are the chances of that" Monitor network: "This is not a random phenomenon like earthquakes" Site operator: "But, you can't prove it, and not all users are affected, right?" ...and so on Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected. This scheme should not be confused with actual security. How does this not add to security? More moving parts to break and make things worse. Every bit of script and supplemental page content is another weakest link. And they will break, because they're being developed by those who are ether don't understand or are not willing to admit that they're pushing snake oil, even after the systemic flaws in their scheme have been pointed out repeatedly.