271–280 of 282 posts
Earlier quoted context omitted.
How about putting the ISP supplied modem in a DMZ? Then the ISP could admin it all they want but still never touch the LAN.
So open it up to anyone? DMZ is an open target, not what you want to be doing.
Earlier quoted context omitted.
Can the ISP load firmware onto your modem? I'm on Cox in the US (same ISP as in TFA) and you can bring your own modem, but Cox will remotely update the firmware.
Not really as far as I know. Providers in Germany have more or less standardized on Fritz!Box from AVM and the router comes with the admin password available. Updates are then fetched from upstream AVM. But the key point here is device independence - by law, providers need to give you all information required to establish a connection to them. This allows you to run a Linux or BSD box as a router should you wish to.…
Earlier quoted context omitted.
Yes: ethics.
Some of us can get there without the organized principles simply with empathy. It's even deeply selfish in it's own way. Ethics is our answer for those that can't.
However of course in reality, empathy only gets you so far. Should you feel empathy for a CSA consumer because their feelings are important too? Do you empathise with their feelings?
Earlier quoted context omitted.
Discovered this in a vendor’s API. They registered the current user provider as singleton rather than per-request. So periodically you could ride on the coat-tails of an authenticated user.
This is ridiculously easy to do inside scripting languages like javascript function foo(token: string) {} function bar(token: string) {} function baz(token: string) {} // hmm, this is annoying let token; .get((req) => { token = req.data.headers.token } function foo() {} It is even possible to do it by "accident" with only subtly more complicated code! I constantly see secrets leak to the frontend because a company is…
Earlier quoted context omitted.
> The author's mistake was not posting somewhere like NANOG or Full-Disclosure with a detailed write-up. This is an organizational equivalent of a code smell. Something is off when support people aren't writing up the anomalies and escalating them. Some of the most serious security issues I've ever had to deal with started with either a sales rep getting a call or a very humble ticket with a level one escalating it u…
"Code smell" as a programming term is often a red herring that causes conflicts within development teams (I've seen this happen too many times), because anyone can call anything they don't like about a coworkers code as a "code smell". Your comment is a "code smell" . See how easy that was? And "code smell" doesn't apply in a similar or metaphorical way towards cable modem support personnel. Those people aren't suppo…
The support staff probably wouldn't get anything done with any given bad modem ticket, but the analyst looking at support data for the week/month might notice that we've had 82 reports of defective modems of a specific model in a short time frame, and this is a new problem... one that we should probably grab a defective modem, get the vendor and take a look to make sure we don't have a big problem (the assumption might be defective hardware, but that's why you gather evidence and investigate further).
Earlier quoted context omitted.
Some of us can get there without the organized principles simply with empathy. It's even deeply selfish in it's own way. Ethics is our answer for those that can't.
I haven't encountered people whose empathy is so perfectly aligned with ethics that they don't need to be taught anything, but I suppose these perfectly selfless people might exist. However of course in reality, empathy only gets you so far. Should you feel empathy for a CSA consumer because their feelings are important too? Do you empathise with their feelings?
> but I suppose these perfectly selfless people might exist
I don't suppose you read what I typed. Empathy is not the setting of self aside, but the experience of feeling what someone else would in a given scenario. It is deeply selfish.
I would also say it is a prerequisite for an organized system of ethics.
Great writeup. There's just one thing I don't get: the auth part. It seems the author managed to access protected endpoints without any auth, by just repeating the same request over and over until the endpoint randomly accepted it. The part that confuses me is, how could that possibly happen ? What possible architecture could this system have to enable this specific failure mode? I struggle to think of anything, shor…
> how could that possibly happen? Global singleton shared across requests, instead of request scoped. 1. [Client 1/You] Auth/write to variable (failed). 2. [Client 2/ISP] Auth/write to variable (success). 3. Verify what the result was (success) A race condition combined with a global singleton can easily explain such behavior.
Are you describing some kind of server-side global object that statefully says a session/api key is "authenticated" and will then allow the request during that time frame? That seems like a bug you could drive container ships through. Yes I know saas s/w sucks out there but this would seem to at least be something an audit could easily flag.
Earlier quoted context omitted.
"Code smell" as a programming term is often a red herring that causes conflicts within development teams (I've seen this happen too many times), because anyone can call anything they don't like about a coworkers code as a "code smell". Your comment is a "code smell" . See how easy that was? And "code smell" doesn't apply in a similar or metaphorical way towards cable modem support personnel. Those people aren't suppo…
If code smell is being weaponized to assault a coworkers code, then you are using the phrase incorrectly and have some cultural issues on your development team. The phrase came from Martin Fowler's book "Refactoring" https://martinfowler.com/bliki/CodeSmell.html and is intended to indicate that you might benefit greatly by refactoring that code. What I was saying is that the support organization needs to be worked on…
The description in the link you provided is pretty wishy-washy:
>"smells don't always indicate a problem."
Okay, so does it smell like flowers or does it smell like shit?? It's a stupid term, and yes, it's been abused by programmers that often think it makes them seem smarter than they are.
Maybe "code stink" would be a better designation for code that's actually a problem. But even that would be stupid and I'd never use it to describe code. Putting down someone else's code as "smelly" is a great way to make a team dysfunctional. And code is often messy for plenty of good reasons (PoC code is perfectly fine if it's messy, no reason to call it "smelly"), there's no reason to anthropomorphize it and assign it a "smell". It's just a rude way to talk about code.
Your second paragraph is more reasonable.
Earlier quoted context omitted.
it's good but the constant use of "super" was a little off-putting, "super curious", "super interesting", "super interested", etc.
There were 4 occurrences of the word "super" in an article with more than four thousand words in it, there is no need for "etc." you quoted all the occurrences since "super curious" was used twice.