• 0 Posts
  • 421 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

















  • No need to get aggravated, I completely grasp it, you’ve possibly misunderstood or not entirely read my comment if that’s your takeaway.

    I’m not talking about server code specifically, I’m going through the stages between the source code repo(s) and what your browser ends up receiving when you request a site.

    NodeJS is relevant here because it’s what runs nearly all major JS bundlers (webpack, vite, etc), which are what produces the code that ultimately runs in the browser for most websites you use. Essentially in a mathematical sense, the full set of dependencies for that process are a part of the input to the function that outputs the JS bundle(s).

    I’m not really sure what you mean with that last part, really, anyone hosting something on the internet has to care about that stuff, not just businesses. GDPR can target individuals just as easily as for-profit companies, it’s about the safety of the data, not who has it—I’m assuming you would not want to go personally bankrupt due to a deliberate neglect of security? Similarly, if you have a website that doesn’t hit the performance NFRs that search engines set, no one will ever find it in search results because it’ll be down on page 100. You will not be visiting websites which don’t care about this stuff.

    Either way, all of that is wider reasoning for the main point which we’re getting away from a bit, so I’ll try to summarise as best I can:

    Basically unless you intend your idea to only work on entirely open source websites (which comprise a tiny percentage of the web), you’re going to have to contend with these JS bundles, which as I’ve gone into, is basically an insurmountable task due to not having the complete set of inputs.

    If you do only intend it to work with those completely open source websites, then crack on, I guess. There’s still what looks to me like a crazy amount of things to figure out in order to create a filter that won’t be able to work with nearly all web traffic, but if that’s still worth it to you, then don’t let me convince you otherwise.

    Edit: typo


  • My view on this is that Ofcom fucked it on this long ago really and the horse has already bolted

    We should have gone with an openreach style model for the infrastructure rather than doling out exclusive rights to chunks of spectrum in an entirely uneven manner.

    This model can’t really sustain more than a few companies because, using this as an example: three has a fantastic 3G network and the best 5G network, however they have no 2G network and got shafted on 4G spectrum. Vodafone has almost a polar opposite of the best 2G coverage (still useful for very remote customers) and 4G coverage comparable to EE.

    The only way for these two companies to cover the patches in their service and complete with the market leader effectively is a merger, which is how EE came to exist in the first place.

    I’m not sure I buy the pricing-people-out angle either tbh, we have a pretty rich market of MVNOs who act as an anchor on the MNO pricing, and it would look like anti-competitive market collision if suddenly the operating costs for these companies went up after a merger.


  • First I don’t even grasp what a “service owner” is.

    The people who build & run the software & servers that serve the website, who amongst other things have an interest in keeping the service available, secure, performant, etc.

    Particularly with laws like GDPR, these services owners are motivated to be as secure as practically possible otherwise they could receive a bankrupting fine should they end up leaking someone’s data. You’ll never be able to convince anyone to lower the security of their threat model for that reason alone, before anything else.

    there are already a bunch of app (web, android) that are open-source and secured.

    The code published and the code running on a server cannot be treated as equivalent for several reasons, but here’s two big ones:

    Firstly, there’s the similar issue as with compiled binaries in other languages: it’s tough (or impossible) to verify that the code published is the same code that’s running. Secondly the bundled and minified versions of websites are rarely published anyway, at most you get the constituent code and a dependency list for something completely open source. This is the bit I referred to before as trying to untoast bread, the browser gets a bundle that can’t practically be reversed back into that list of parts and dependencies in a general purpose way. You’d need the whole picture to be able to do any kind of filtering here.

    who is the attacker here?

    The only possible attacker is not the website itself (though it’s a lot more limited if the site implements CSP & SRI, as mentioned in my other comment). XSS is a whole category of attacks which leverage an otherwise trusted site to do something malicious, this is one of the main reasons you would run something like noscript.

    There have also been several instances in recent years of people contributing to (or outright taking over) previously trusted open source projects and sneaking in something malicious. This then gets executed and/or bundled during development in anything that uses it and updates to the compromised version before people find the vulnerability.

    Finally there are network level attacks which thankfully are a lot less common these days due to HTTPS adoption (and to be a broken record, CSP & SRI), but if you happen to use public WiFi, there’s a whole heap of ways a malicious actor can mess with what your browser ultimately loads.