Most active commenters
  • cluckindan(6)
  • zelphirkalt(4)
  • sfn42(3)

←back to thread

1208 points jamesberthoty | 25 comments | | HN request time: 0.097s | source | bottom
Show context
kelnos ◴[] No.45266878[source]
As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embedded malware.

One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago. As a maintainer, I could decide that a package that's been out in the wild for at least 6 weeks is less likely to have unnoticed malware in it than one that was released just yesterday.

Obviously this is not a perfect fix, as there's no guarantee that the delay time I specify is enough for any particular package. And I'd want the tool to present me with options sometimes: e.g. if my current version of a dep has a vulnerability, and the fix for it came out a few days ago, I might choose to update to it (better eliminate the known vulnerability than refuse to update for fear of an unknown one) rather than wait until it's older than my threshold.

replies(35): >>45266995 #>>45267024 #>>45267360 #>>45267489 #>>45267600 #>>45267697 #>>45267722 #>>45267967 #>>45268218 #>>45268503 #>>45268654 #>>45268764 #>>45269143 #>>45269397 #>>45269398 #>>45269524 #>>45269799 #>>45269945 #>>45270082 #>>45270083 #>>45270420 #>>45270708 #>>45270917 #>>45270938 #>>45272063 #>>45272548 #>>45273074 #>>45273291 #>>45273321 #>>45273387 #>>45273513 #>>45273935 #>>45274324 #>>45275452 #>>45277692 #
gameman144 ◴[] No.45267024[source]
> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies

I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators.

"Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually pretty sensible.

replies(8): >>45267054 #>>45267101 #>>45267444 #>>45268170 #>>45268880 #>>45270337 #>>45273381 #>>45273796 #
2muchcoffeeman ◴[] No.45267444[source]
Have we all forgotten the left-pad incident?

This is an eco system that has taken code reuse to the (unreasonable) extreme.

When JS was becoming popular, I’m pretty sure every dev cocked an eyebrow at the dependency system and wondered how it’d be attacked.

replies(4): >>45267564 #>>45270790 #>>45274137 #>>45274653 #
zelphirkalt ◴[] No.45267564[source]
> This is an eco system that has taken code reuse to the (unreasonable) extreme.

Not even that actually. Actually the wheel is reinvented over and over again in this exact ecosystem. Many packages are low quality, and not even suitable to be reused much.

replies(1): >>45270066 #
wongarsu ◴[] No.45270066[source]
The perfect storm of on the one side junior developers who are afraid of writing even trivial code and are glad if there's a package implementing functionality that can be done in a one-liner, and on the other side (often junior) developers who want to prove themselves and think the best way to do that is to publish a successful npm package
replies(2): >>45270499 #>>45272644 #
bobthepanda ◴[] No.45270499[source]
The blessing and curse of frontend development is that there basically isn't a barrier to entry given that you can make some basic CSS/JS/HTML and have your browser render it immediately.

There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"

replies(2): >>45271721 #>>45274085 #
pxc ◴[] No.45271721[source]
> There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"

What kind of code does this developer write?

replies(3): >>45271929 #>>45272283 #>>45278523 #
1. garbagepatch ◴[] No.45271929[source]
As little code as possible to get the job done without enormous dependencies. Avoiding js and using css and html as much as possible.
replies(1): >>45272213 #
2. sfn42 ◴[] No.45272213[source]
Sounds like the perfect frontend dev to me.
replies(1): >>45272303 #
3. cluckindan ◴[] No.45272303[source]
The designer, the customer, and US/EU accessibility laws heavily disagree.
replies(6): >>45272642 #>>45272704 #>>45272774 #>>45272992 #>>45274092 #>>45280222 #
4. Philadelphia ◴[] No.45272642{3}[source]
How is javascript required for accessibility? I wasn’t aware of that.
replies(1): >>45272968 #
5. NackerHughes ◴[] No.45272704{3}[source]
The designer wants huge amounts of screen space wasted on unnnecessary padding, massive Fisher-Price rounded corners, and fancy fading and sliding animations that get in the way and slow things down. (Moreover, the designer just happens to want to completely re-design everything a few months later.)

The customer “ooh”s and “aah”s at said fancy animations running on the salesman’s top of the line macbook pro and is lured in, only realising too late that they’ve been bitten in the ass by the enormous amount of bloat that makes it run like a potato on any computer that costs less than four thousand dollars.

And US/EU laws are written by clueless bureaucrats whose most recent experience with technology is not even an electric typewriter.

What’s your point?

replies(3): >>45273543 #>>45273548 #>>45275705 #
6. whstl ◴[] No.45272774{3}[source]
The designer already disagrees with accessibility laws. Contrast is near zero.
7. boesboes ◴[] No.45272968{4}[source]
It is not. In fact, it is all the modern design sensibilities and front-end frameworks that make it nearly impossible to make accessible things.

We once had the rule HTML should be purely semantic and all styling should be in CSS. It was brilliant, even though not everything looked as fancy as today.

replies(1): >>45273553 #
8. sfn42 ◴[] No.45272992{3}[source]
A11y is mostly handled by just using semantic html.

The designer, in my experience, is totally fine with just using a normal select element, they don't demand that I reinvent the drop-down with divs just to put rounded corners on the options.

Nobody cares about that stuff. These are minor details, we can change it later if someone really wants it. As long as we're not just sitting on our hands for lack of work I'm not putting effort into reinventing things the browser has already solved.

replies(2): >>45273573 #>>45274188 #
9. cluckindan ◴[] No.45273543{4}[source]
Wow, those are some jaded and cynical views.
10. wvh ◴[] No.45273548{4}[source]
I think their point is that you might not have much of a choice, taking laws and modern aesthetic and economic concerns into consideration.

We "in the know" might agree, but we're not going to get it sold.

11. cluckindan ◴[] No.45273553{5}[source]
JS is in fact required for AA level compliance in some cases, usually to retain/move focus appropriately, or to provide expected keyboard controls.

https://www.w3.org/WAI/WCAG22/Techniques/#client-side-script

Also, when was that semantic HTML rule? You make it sound like ancient history, but semantic HTML has only been a thing since HTML5 (2008).

replies(4): >>45273635 #>>45273779 #>>45273867 #>>45273885 #
12. cluckindan ◴[] No.45273573{4}[source]
The word ”mostly” is the crux of the issue.
13. lexicality ◴[] No.45273635{6}[source]
You only need to use scripts to move focus and provide keyboard controls if you have done something to mess with the focus and break the standard browser keyboard controls.

If you're using HTML/CSS sensibly then it's accessible from the get-go by dint of the browser being accessible.

> Also, when was that semantic HTML rule? You make it sound like ancient history, but semantic HTML has only been a thing since HTML5 (2008).

HTML5 added a million new tags, but HTML4 had plenty of semantic tags that people regularly ignored and replaced with <div>, for example <p>, <em>, <blockquote>...

replies(2): >>45276989 #>>45277224 #
14. sfn42 ◴[] No.45273779{6}[source]
In some cases, sure.

I'm not saying the ideal frontend dev writes no JS. I'm saying they write as little as possible. Some times you need JS, nothing wrong with that. The vast majority of the time you don't. And if you do I'd say it's a self-imposed requirement (or a direct/indirect result of a self imposed requirement) most of the time.

replies(1): >>45274152 #
15. skipchris ◴[] No.45273867{6}[source]
The web standards project was founded in 1998.

https://www.webstandards.org/about/index.html

16. GoblinSlayer ◴[] No.45273885{6}[source]
Some of those are fixes for misbehaving javascript like disabling nonessential alerts, stopping blinking, reducing animation; some are antipatterns like opening new windows, changing link text, colors, scrolling.
17. zelphirkalt ◴[] No.45274092{3}[source]
The designer might only disagree, if they know a lot about frontend technology, and are not merely clicking together a figma castle.

But the middle management might actually praise the developer, because they "get the job done" with the minimal effort (so "efficient"!).

18. zelphirkalt ◴[] No.45274152{7}[source]
Recently I took a little dive into making some pages, that have fallback for when the user doesn't run JS. Those pages are polling an API and displaying updated status. I made sure the pages can be reloaded and show updated status information, and telling the user, that they can simply refresh the page to get that updated information, but only showing that hint about reloading, when they do not run JS. Thus I built a workflow, that people can use whether or not they run JS. I did that, because I think it is the right thing, and because I often preach, that most sites should work without JS.

For me as a mostly backend dev, this was actually quite easy to achieve. Tiny modification of the backend API, some work in the frontend using JS to remove hints that should not show when JS is running, and voila, it works. Of course my pages are very simple in nature, but the same principles can be applied to larger pages. One could even link/direct to different pages, depending on the user running JS or not, and then have a workflow without JS and one with JS. It is all possible and only a matter of wanting to make an effort. Of course, modern JS frameworks do not really encourage this kind of design. Though server side rendering becomes more popular these days, I don't think we are quite there yet.

A page that is blank when not running JS has exactly zero accessibility.

19. zelphirkalt ◴[] No.45274188{4}[source]
I hope in the future I can work with that kind of designer. Maybe it is just my limited experience, but in that limited experience, web designers care way too much about details and design features/ideas/concepts, that are not part of HTML or CSS and then frontend developers would have to push back and tell the web designer, that form follows function and that the medium they design for is important. Basic design principles actually, that the designers should know themselves, just like they should know the medium they are targeting (semandic HTML, CSS, capabilities of them both, a tiny bit about JS too), to keep things reasonable. But most frontend devs are happy to build fancy things with JS instead of pushing back when it matters. And not so many frontend devs want to get into CSS deeply and do everything they can to avoid JS. So needless things do get implemented all the time.
20. wbl ◴[] No.45275705{4}[source]
I think blind people should be able to use websites.
21. kbolino ◴[] No.45276989{7}[source]
IMO <em> is a terrible example.

For ca. ten years, the advice was to pointlessly "replace <i> with <em> and <b> with <strong>" and it utterly screwed over most new web developers' understanding of semantic tags. There are many reasons to use italics (and they vary between languages) but "emphasis" is just one of them, and none of the others ever materialized as tags.

It would have been far better to have recommended <i class="emphasis"> and <i class="media-title"> and <i class="snarky-aside"> etc. than to have added the <em> tag and said "just use it instead of <i>".

22. cluckindan ◴[] No.45277224{7}[source]
”You only need to use scripts to move focus and provide keyboard controls if you have done something to mess with the focus and break the standard browser keyboard controls.”

That is straight up untrue. Some ARIA patterns require developers to implement focus management and keyboard access from scratch.

For example, ”Correct implementation of the tree role requires implementation of complex functionality that is not needed for typical site navigation that is styled to look like a tree with expandable sections.”

But sometimes you do need that kind of widget for something else.

https://www.w3.org/WAI/ARIA/apg/patterns/treeview/

replies(1): >>45278320 #
23. lexicality ◴[] No.45278320{8}[source]
Sorry, I completely forgot about the existing semantic tree view element that exists and can be interacted with visually but doesn't provide any accessibility or keyboard support because the browser manufacturers decided to skip that one.

Or are you talking about a situation where the developer has implemented a custom component (aka "done something") which doesn't use the native focus system and therefore requires additional work to make accessible?

replies(1): >>45280687 #
24. bigstrat2003 ◴[] No.45280222{3}[source]
As the customer, I think that's the perfect frontend dev. Fuck the JS monstrosities that people build, they are so much harder to use than plain HTML.
25. cluckindan ◴[] No.45280687{9}[source]
If by ”done something” you mean the devs made custom widgets have the proper ARIA roles so they’re usable for people who use a keyboard to navigate, or who need screen readers and their plethora of different navigation modes. This is usually the case when a suitable standard component does not exist or is not well supported across browsers. Hierarchical tri-state checkboxes come to mind.

The native focus system typically works just fine, but JS is needed for keyboard interactions and to set things like aria-activedescendant.