4 ms·

IP, TCP, and QUIC are all IETF standards & in use here. The base of the pyramid, governing the internet as a whole, says the Internet is for end users. That doe

IP, TCP, and QUIC are all IETF standards & in use here. The base of the pyramid, governing the internet as a whole, says the Internet is for end users. That doesn't seem in the slightest bit hard to see. It's unclear that websites would be more secure by virtue of having a Google or Microsoft or Apple attested OS. What examples have we seen of users running their own OS contributing to a web host's security issues? Got anything? Probably not! WEI has always been of dubious use. Your original claim that extensions needed to be blocked was an explicit anti-goal of web. Users obviously have a right to extensions, which allows for accessibility affordances, for example. Would you also propose turning off view source and the debugged? What other nastygram blocks of shit do you propose smacking users in the face with? It feels like you are trying really hard to be obtuse negative & nasty to users, and throwing absurd ridiculous arguments out to anger people, who care about users.

charcircuit 3y ago
>IP, TCP, and QUIC are all IETF standards & in use here. The RFC is about the development of those standards. It is not talking about the usage of them. >What examples have we seen of users running their own OS contributing to a web host's security issues? For example there are scripts that take lists of email password combos and send network requests to attempt logging into these accounts. Then using these accounts the attackers do malicious actions. Platforms that make it harder or more expensive to automate things will have less people using them abuse services. >Your original claim that extensions needed to be blocked was an explicit anti-goal of web. If sites only want to allow input injection that comes from preapproved password manager extentions they should be able to get proof of if that's the case. The alternative to the browser blocking the extention is that the site could ask the user to disable the extention or just provide an error that the input came from an untrusted source. There are some different options in how this could be handled. >Users obviously have a right to extensions, which allows for accessibility affordances Yes, but my concern is mainly with the proof part on the server side. So the server can be sure that actions taken were not being done by an untrusted extention. Accessiblity also needs to be carefully considered as bad actors may use accessibility features to bypass security. >Would you also propose turning off view source and the debugged? No, I have not seen a big demand for keeping code a secret. For the relevant problems trying to hide the come is security by obscurity. >What other nastygram blocks of shit do you propose smacking users in the face with? I don't indented to smack any users. 99% of users will not even notice anything has changed, but attackers will realize that their job just got a lot harder. >It feels like you are trying really hard to be obtuse negative & nasty to users I feel if you had to deal with protecting a website from bad actors you would appreciate my viewpoint.

charcircuit 3y ago

>IP, TCP, and QUIC are all IETF standards & in use here. The RFC is about the development of those standards. It is not talking about the usage of them. >What examples have we seen of users running their own OS contributing to a web host's security issues? For example there are scripts that take lists of email password combos and send network requests to attempt logging into these accounts. Then using these accounts the attackers do malicious actions. Platforms that make it harder or more expensive to automate things will have less people using them abuse services. >Your original claim that extensions needed to be blocked was an explicit anti-goal of web. If sites only want to allow input injection that comes from preapproved password manager extentions they should be able to get proof of if that's the case. The alternative to the browser blocking the extention is that the site could ask the user to disable the extention or just provide an error that the input came from an untrusted source. There are some different options in how this could be handled. >Users obviously have a right to extensions, which allows for accessibility affordances Yes, but my concern is mainly with the proof part on the server side. So the server can be sure that actions taken were not being done by an untrusted extention. Accessiblity also needs to be carefully considered as bad actors may use accessibility features to bypass security. >Would you also propose turning off view source and the debugged? No, I have not seen a big demand for keeping code a secret. For the relevant problems trying to hide the come is security by obscurity. >What other nastygram blocks of shit do you propose smacking users in the face with? I don't indented to smack any users. 99% of users will not even notice anything has changed, but attackers will realize that their job just got a lot harder. >It feels like you are trying really hard to be obtuse negative & nasty to users I feel if you had to deal with protecting a website from bad actors you would appreciate my viewpoint.