Live data from Hacker News

Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

twitter.com

231–240 of 322 posts

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#231
post #90

Earlier quoted context omitted.

I will never stoop so low as to telegraph my own joke.

I couldn't agree more. The joke construction was a bit weak though, when you miss a good part of the audience. Add something like, "I mean, could you imagine the chaos it would cause if IE told websites it was really Mozilla?" and you demonstrate mastery of the subject matter, which should be enough to let other experts know you were facetious rather than ignorant. Unless you have timing issues... or need the comedia…

Sir, your assessment of this particular joke is excellent. We should start a joke approval committee to avoid further confusion.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#233
post #173

This "fix" seriously hurts Cisco's credibility. How can you trust their products? Perhaps they are thinking that noone gives a damn anyway after no less than five backdoors² were found in their products in 2018 alone? Just incredible. ² https://www.tomshardware.com/news/cisco-backdoor-hardcoded-a...

Cisco is in the business of selling big, black, expensive boxes that have a lot of security badges and fancy icons. People who buy such boxes don't care if they actually work, they want a big box so that they can claim they "invested in security".

Actually, they want the Cisco box because it has those 'badges' and that then allows them to check off all the check-boxes on the semi-annual security compliance report paperwork they have to file with some other department.

But you are right, they don't care if the box is secure, they just care that they have a CYA that allows them to "check off their own boxes" on their reports.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#235

Earlier quoted context omitted.

It's easy to opine and judge from on high when it's not your nuts in the vice.

Doesn't mean the point isn't valid though.

It's a problem of someone coming from a very incomplete view of the situation, and then issuing judgments and advice without doing any research into the actual situation on the ground (armchair warriors), which is irresponsible.

Yes, there is a possibility that they are in fact right, but they'll probably be right for the wrong reasons. It's far more likely that they'll just be plain wrong (and arrogantly so). Even a stopped clock is right twice a day.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#236

Earlier quoted context omitted.

You suggest it was just one lone engineer being incompetent. Then you respond to downvotes with the non-sequitur "take some pride in your work" - are you suggesting pride is a fix for incompetence? What?

There are two points. 1) Any engineer involved in implementing this "fix" is incompetent. 2) If you are not incompetent and management tries to force you to implement this "fix" then you should take pride in your work and refuse to do it, even if it means quitting your job (or forcing the company to fire you).

Let me know when pride is accepted as currency to pay bills or when insubordination due to personal pride is seen as a desirable quality in a candidate. At the very least, how much are you willing to pay a person for not implementing the fix you disagree with (including engaging in a legal contract to pay them if they lose their employment due to not implementing the fix). From my past experiences with others, moral high grounds rarely survive personal stake.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#237

Earlier quoted context omitted.

You can always quit. Or force them to fire you for refusing to implement a non fix. In reality though I doubt this narrative even occurred. Some incompetent engineer likely proposed this fix thinking that it was actually a fix. Edit: I see I've been downvoted for this comment. If we were real engineers working on things like cars and bridges we'd actually be held accountable. Take some pride in your work people, this…

I like your spirit, but there's another conclusion we can draw: very few of us outside of a few special areas in embedded are "engineers". We tinker with bits and bytes to make business systems. Sometimes we bump up against some general engineering fundamentals. But we're just technicians meeting business goals.

Yep, and the same can be said for “real engineers”. Most EEs, civil engineers, etc work on boring stuff as well with negligible risk of doing any harm.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#238
post #79

Earlier quoted context omitted.

edit: sorry, accidentally submitted early So what. Removing one of the largest sources entropy available for fingerprinting users is important. We shouldn't maintain the terrible long-term effects[1] of tracking everything just to help you have an easier time debugging. [1] http://nymag.com/intelligencer/2019/02/shoshana-zuboff-q-and...

Does it really provide that much entropy? Maybe back in the days when browsers didn’t auto-update, but intuitively it should only provide about four bits at most (os: Android iOS macOS windows, browser: chrome safari edge ie ff) except for a few rare users who don’t stay up to date or choose a weird browser (and those folks probably are a little confused about how privacy works).

ohhhhh you betcha.

https://amiunique.org/

i ran this on my work laptop (windows 10 / firefox - mostly default settings). the "details" tab shows a full breakdown of each fingerprinting component with a "similarity ratio" (percentage of fingerprints that share the same value).

every entry is 20% or greater, most of them around 50% except for timezone (4%), canvas (1%), and user agent (0.12%).

so, yeah, user agents are still the largest source of entropy by a wide margin for fingerprinting scripts.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#239

Earlier quoted context omitted.

There is presumably some way, at least hypothetically, to fix the mess that User-Agent has become. (Everybody is 'Mozilla' now! And yet somehow a unique snowflake 'Mozilla' that lets you be tracked...) But it's not quite that. It's not that a device is "mobile" instead of "stationary" that matters. It's maybe that it's a touch screen. It's maybe that it's a small screen. (With an especially uneven aspect ratio?) Mayb…

All of those small differences of mobile devices are better served by media queries I personally think. You could replace "mobile" in my example by "small-screen" if you prefer.

Agreed. Media queries need to be improved though. There are no good media queries to detect "touch screen" and/or "no keyboard or mouse/pointer, only touch screen", only JS hacks that attempt it. This can matter. But yes, improving media query (or input method query?) APIs for both CSS and JS is, I agree, the correct solution to User-Agent madness. It's just not entirely straightforward or obvious or easy, and as always getting all browsers on the same page is an issue.
Post reply on HN