Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Web Is Broken – Botnet Part 2

jan.wildeboer.net

Post reply on HN
Print view View original

61–70 of 301 posts

Re: The Web Is Broken – Botnet Part 2

#61

Post by baumy »

ryandrake wrote: post #55
ClumsyPilot wrote: post #52

Earlier quoted context omitted.

> Have you audited this code? Wrong question. “Are you paid to audit this code?” And “if you fail to audit this code, who’se problem is it?”

I think developers are paid to competently deliver software to their employer, and part of that competence is properly vetting the code you are delivering. If I wrote code that ended up having serious bugs like crashing, I’d expect to have at least a minimum consequence, like root causing it and/or writing a postmortem to help avoid it in the future. Same as I’d expect if I pulled in a bad dependency.

Your expectations do not match the employment market as I have ever experienced it.

Have you ever worked anywhere that said "go ahead and slow down on delivering product features that drive business value so you can audit the code of your dependencies, that's fine, we'll wait"?

I haven't.

Re: The Web Is Broken – Botnet Part 2

#62

Post by jt2190 »

desertmonad wrote: post #38
jt2190 wrote: post #33

I’m really struggling to understand how this is different than malware we’ve had forever. Can someone explain what’s novel about this?

That its not being treated like malware.

In the sense that people are voluntarily installing and running this malware on their computers, rather than being tricked into running it? Is that the only difference?

Re: The Web Is Broken – Botnet Part 2

#64

Post by downrightmike »

jt2190 wrote: post #33

I’m really struggling to understand how this is different than malware we’ve had forever. Can someone explain what’s novel about this?

I think it is funny that the mobile OS is trying to be as secure as possible, but then they allow this to run on top

Re: The Web Is Broken – Botnet Part 2

#65

Post by CharlesW »

aucisson_masque wrote: post #60

It's interesting but so far there is no definitive proof it's happening. People are jumping to conclusions a bit fast over here, yes technically it's possible but this kind of behavior would be relatively easy to spot because the app would have to make direct connections to the website it wants to scrap. Your calculator app for instance connecting to CNN.com ... iOS have app privacy report where one can check what co…

Botnets as a Service are absolutely happening, but as you allude to, the scope of the abuse is very different on iOS than, say, Windows.

Re: The Web Is Broken – Botnet Part 2

#66

Post by luckylion »

proxy_err wrote: post #54

Its a fair point but very dynamic to sort out. This needs a full research team to figure out. Or you know.. all of us combined!! It is definitely a problem. TINFOIL: Sometimes I always wondered if Azure or AWS used bots to push site traffic hits to generate money... they know you are hosted with them.. They have your info.. Send out bots to drive micro accumulation. Slow boil..

I think that's mostly that they don't care about having malicious bots on their networks as long as they pay.

GCE is rare in my experience. Most bots I see are on AWS. The DDOS-adjacent hyper aggressive bots that try random URLs and scan for exploits tend to be on Azure or use VPNs.

AWS is bad when you report malicious traffic. Azure has been completely unresponsive and didn't react, even for C&C servers.

Re: The Web Is Broken – Botnet Part 2

#67

Post by int_19h »

jt2190 wrote: post #62
desertmonad wrote: post #38

Earlier quoted context omitted.

That its not being treated like malware.

In the sense that people are voluntarily installing and running this malware on their computers, rather than being tricked into running it? Is that the only difference?

They are still tricked into running it, since it's normally not an advertised "feature" of any app that uses such SDKs.

Re: The Web Is Broken – Botnet Part 2

#68

Post by rjbwork »

layer8 wrote: post #45
rjbwork wrote: post #32

Earlier quoted context omitted.

Elaborate on this please. It seems a great boon in having pushed the OO world towards more functional principles, but I'm willing to hear dissent.

How is dependency injection more functional? My personal beef is that most of the time it acts like hidden global dependencies, and the configuration of those dependencies, along with their lifetimes, becomes harder to understand by not being traceable in the source code.

Dependency injection is just passing your dependencies in as constructor arguments rather than as hidden dependencies that the class itself creates and manages.

It's equivalent to partial application.

An uninstantiated class that follows the dependency injection pattern is equivalent to a family of functions with N+Mk arguments, where Mk is the number of parameters in method k.

Upon instantiation by passing constructor arguments, you've created a family of functions each with a distinct sets of Mk parameters, and N arguments in common.

Re: The Web Is Broken – Botnet Part 2

#69

Post by squeaky-clean »

layer8 wrote: post #53
kortilla wrote: post #49

Earlier quoted context omitted.

Because you’re passing functions to call.

??? What functions? To me it‘s rather anti-functional. Normally, when you instantiate a class, the resulting object’s behavior only depends on the constructor arguments you pass it (= the behavior is purely a function of the arguments). With dependency injection, the object’s behavior may depend on some hidden configuration, and not even inspecting the class’ source code will be able to tell you the source of that be…

> because there’s only an @Inject annotation without any further information

It sounds like you have a gripe with a particular DI framework and not the idea of Dependency Injection. Because

> Normally, when you instantiate a class, the resulting object’s behavior only depends on the constructor arguments you pass it (= the behavior is purely a function of the arguments)

With Dependency Injection this is generally still true, even more so than normal because you're making the constructor's dependencies explicit in the arguments. If you have a class CriticalErrorLogger(), you can't directly tell where it logs to, is it using a flat file or stdout or a network logger? If you instead have a class CriticalErrorLogger(logger *io.writer), then when you create it you know exactly what it's using to log because you had to instantiate it and pass it in.

Or like Kortilla said, instead of passing in a class or struct you can pass in a function, so using the same example, something like CriticalErrorLogger(fn write)

Post reply on HN