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

91–100 of 301 posts

Re: The Web Is Broken – Botnet Part 2

#91

Post by musicale »

whstl wrote: post #21
pton_xd wrote: post #14

I thought the closed-garden app stores were supposed to protect us from this sort of thing?

Once again this demonstrate that closed gardens only benefit the owners of the garden, and not the users. What good is all the app vetting and sandbox protection in iOS (dunno about Android) if it doesn't really protect me from those crappy apps...

Sandboxing means you can limit network access. For example, on Android you can disallow wi-fi and cellular access (not sure about bluetooth) on a per-app basis.

Network access settings should really be more granular for apps that have a legitimate need.

App store disclosure labels should also add network usage disclosure.

Re: The Web Is Broken – Botnet Part 2

#92

Post by layer8 »

squeaky-clean wrote: post #69
layer8 wrote: post #53

Earlier quoted context omitted.

??? 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 sti…

I don't quite understand your example, but I don't think the particulars make much of a difference. We can go with the most general description: With dependency injection, you define points in your code where dependencies are injected. The injection point is usually a variable (this includes the case of constructor parameters), whose value (the dependency) will be set by the dependency injection framework. The behavior of the code that reads the variable and hence the injected value will then depend on the specific value that was injected.

My issue with that is this: From the point of view of the code accessing the injected value (and from the point of view of that code's callers), the value appears like out of thin air. There is no way to trace back from that code where the value came from. Similarly, when defining which value will be injected, it can be difficult to trace all the places where it will be injected.

In addition, there are often lifetime issues involved, when the injected value is itself a stateful object, or may indirectly depend on mutable, cached, or lazy-initialized, possibly external state. The time when the value's internal state is initialized or modified, or whether or not it is shared between separate injection points, is something that can't be deduced from the source code containing the injection points, but is often relevant for behavior, error handling, and general reasoning about the code.

All of this makes it more difficult to reason about the injected values, and about the code whose behavior will depend on those values, from looking at the source code.

Re: The Web Is Broken – Botnet Part 2

#93

Post by __MatrixMan__ »

The broken thing about the web is that in order for data to remain readable, a unique sysadmin somewhere has to keep a server running in the face of an increasingly hostile environment.

If instead we had a content addressed model, we could drop the uniqueness constraint. Then these AI scrapers could be gossiping the data to one another (and incidentally serving it to the rest of us) without placing any burden on the original source.

Having other parties interested in your data should make your life easier (because other parties will host it for you), not harder (because now you need to work extra hard to host it for them).

Re: The Web Is Broken – Botnet Part 2

#94

Post by layer8 »

rjbwork wrote: post #68
layer8 wrote: post #45

Earlier quoted context omitted.

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 construct…

I don't understand what you're describing has to do with dependency injection. See https://news.ycombinator.com/item?id=43740196.

Re: The Web Is Broken – Botnet Part 2

#96

Post by djeastm »

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.

Due diligence is a sliding scale. Work at a webdev agency is "get it done as fast as possible for this MVP we need". Work at NASA or a biomedical device company? Every line of code is triple-checked. It's entirely dependent on the cost/benefit analysis.

Re: The Web Is Broken – Botnet Part 2

#98

Post by jay_kyburz »

philippta wrote: post #79
Pesthuf wrote: post #51

We need a list of apps that include these libraries and any malware scanner - including Windows Defender, Play Protect and whatever Apple calls theirs - need to put infected applications into quarantine immediately. Just because it's not directly causing damage to the device running the malware is running on, that doesn't mean it's not malware.

Apps should be required to ask for permission to access specific domains. Similar to the tracking protection, Apple introduced a while ago. Not sure how this could work for browsers, but the other 99% of apps I have on my phone should work fine with just a single permitted domain.

Oh, that's an interesting idea. A local DNS where I have to add every entry. A white list rather than Australia's national blacklist.

Re: The Web Is Broken – Botnet Part 2

#99

Post by squeaky-clean »

layer8 wrote: post #92
squeaky-clean wrote: post #69

Earlier quoted context omitted.

> 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 sti…

I don't quite understand your example, but I don't think the particulars make much of a difference. We can go with the most general description: With dependency injection, you define points in your code where dependencies are injected. The injection point is usually a variable (this includes the case of constructor parameters), whose value (the dependency) will be set by the dependency injection framework. The behavi…

> whose value (the dependency) will be set by the dependency injection framework

I agree with your definition except for this part, you don't need any framework to do dependency injection. It's simply the idea that instead of having an abstract base class CriticalErrorLogger, with the concrete implementations of StdOutCriticalErrorLogger, FileCriticalErrorLogger, AwsCloudwatchCriticalErrorLogger which bake their dependency into the class design; you instead have a concrete class CriticalErrorLogger(dep *dependency) and create dependency objects externally that implement identical interfaces in different ways. You do text formatting, generating a traceback, etc, and then call dep.write(myFormattedLogString), and the dependency handles whatever that means.

I agree with you that most DI frameworks are too clever and hide too much, and some forms of DI like setter injection and reflection based injection are instant spaghetti code generators. But things like Constructor Injection or Method Injection are so simple they often feel obvious and not like Dependency Injection even though they are. I love DI, but I hate DI frameworks; I've never seen a benefit except for retrofitting legacy code with DI.

And yeah it does add the issue or lifetime management. That's an easy place to F things up in your code using DI and requires careful thought in some circumstances. I can't argue against that.

But DI doesn't need frameworks or magic methods or attributes to work. And there's a lot of situations where DI reduces code duplication, makes refactoring and testing easier, and actually makes code feel less magical than using internal dependencies.

The basic principle is much simpler than most DI frameworks make it seem. Instead of initializing a dependency internally, receive the dependency in some way. It can be through overly abstracted layers or magic methods, but it can also be as simple as adding an argument to the constructor or a given method that takes a reference to the dependency and uses that.

edit: made some examples less ambiguous

Re: The Web Is Broken – Botnet Part 2

#100

Post by Funes- »

ClumsyPilot wrote: post #52
ryandrake wrote: post #46

Earlier quoted context omitted.

I’m constantly amazed at how careless developers are with pulling 3rd party libraries into their code. Have you audited this code? Do you know everything it does? Do you know what security vulnerabilities exist in it? On what basis do you trust it to do what it says it is doing and nothing else? But nobody seems to do this diligence. It’s just “we are in a rush. we need X. dependency does X. let’s use X.” and that’s…

> 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?”

"who'se" is wild.
Post reply on HN