Hacker News new | past | comments | ask | show | jobs | submit | aadhavans's comments login

While I heartily agree with nearly all of the suggestions here - particularly ToC and Code Blocks With Origin (which I really should implement on my own website) - FWIW, I disagree on the need for Progress Bars and Dialogues.

Progress Bars seem like an eyesore to me, a distracting visual feature that's trying to goad me into finishing the article. As other commenters mentioned, the browser already has a scroll bar, which indicates the amount of content I have read. A progress bar just seems unnecessary.

As for dialogues - while they can be cute and interesting if done well, it usually just gets in the way of the content I'm trying to read. The problem that it solves - "ask[ing] questions from a less-experienced point of view" - can often be accomplished with regular prose instead eg. "But you might be asking..."

A feature that I'd like to see in more blogs is a 'Tech Stack' page[0]. I've often stumbled on websites that look very appealing, but have no description of how they were created. This page would describe the technologies and tools you use to write your website. Things like static site generators, CSS, JS framework (if any) could go in here.

I'd also like to add 'Site Maps'[1] to this, which I've implemented as a list of all articles on my website.

[0]: I have such a page at https://twomorecents.org/tech-stack.html

[1]: Looks like this has already been mentioned: https://news.ycombinator.com/item?id=40778888


From the Twitter thread, their github appears to be https://github.com/linux-on-droid. I don't see APKs in any of the repos, though.

Note that this is limited to Birds, Grasshoppers, Bats and Frogs.

Still an incredibly exciting project, and I had a ton of fun listening to bird sounds from my home country. But if you came in expecting to listen to lions and elephants, you will be disappointed.


Out of curiosity, what are the ramifications of exposing ports 80 and 443? Can these ports even be 'hacked'?

It doesn't seem terribly unsafe to me, especially if you're serving static pages.


In my experience, most of the noise on my web server are bots with spoofed iPhone or Google Chrome user-agents. I see three kinds of traffic patterns.

1. bogus /wp-login.php requests, or endpoints of presumably insecure wordpress plugins. These bots are pretty dumb and do it non-stop, even if the server constantly responds with a 404

2. testing recent Apache vulnerabilities by POST-ing to something like /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh . Even if your web server clearly communicates that it's not Apache, the bots still insist on testing Apache vulnerabilities. They also occasionally test vulnerabilities that exist in ancient Nginx versions.

3. less common, but bots that exist to scrape something from the internet. I remember two years ago seeing a bot whose sole purpose was to document as many registered, valid domain names as possible (I found out about this since they linked a website explaining who they were in their user-agent string)

Overall, I would say the background noise of HTTP servers is tame compared to what you see for SMTP servers and, to some extent, SSH servers. I happen to also self-host e-mail; logs record failed login attempts about every second. They always pick a username like "admin" or "adm". There's also people who try using your SMTP server as a relay for spam.


For me the biggest source of noise in logs for a small site is the referrer spam. At some point like 12 years ago I enabled webalizer stats with a public link to the stats page. Soon I had to deal with massive amount of bot requests with http referrer pointing to porn and farmacy ads. That has not stopped after the public link was removed and the stats has started to use a public spam database. And the spam is still there after 12 years.


Matomo (self-hosted analytics, used to be called Piwik) maintain a list of referrer spam domains. I use it as a filter list with GoAccess and haven't seen referrer spam for a long time. Worth a look. https://github.com/matomo-org/referrer-spam-list


> testing recent Apache vulnerabilities by POST-ing to something like /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh .

Are they really recent vulns though?


Gotcha, thanks for the detailed response. I've seen the WordPress login attempts in my own web server logs, and that seems to be corroborated in your comment.


I've added a /wp-login.php and friends that firewall-blocks the IP of the requester for a week. It greatly cuts down the bot noise.


My competing site can have <img src="https://yourdomain/wp-login.php"> and customers won't be able to view your site after that. Thanks for the free customers!


Yep :) The real trick is to not be vulnerable to known issues, and then mitigate post-compromise like crazy on the off chance you get patch gapped or (very unlikely) zero dayed.

Blocking IP addresses is extremely silly, especially in an IPv6 world where attacker can easily get access to gigantic numbers of addresses in hard to identify ways (there's no source of truth for what IPv6 range corresponds to one blockable "customer". Some get /56s, others get /48s, etc.). It's security theater which may well just break your service for real users.


Can you post the script?

Obviously I assume you don't run wp. I think wordfence does something similiar.


It's probably just an nginx fail2ban jail or something that looks for the wp pattern.



99.9999% of issues on 80/443 are apps run on the server not webserver itself.

It is applications that you run on web server that are exploited.

So serving static pages is safest thing you can do.


> Out of curiosity, what are the ramifications of exposing ports 80 and 443? Can these ports even be 'hacked'?

These are the ports usually employed to serve HTTP and HTTPS traffic, which mean public-facing servers.

Having a server listening to those ports is the precondition to have web servers running specific types of services, some of which have known vulnerabilities that can be and are exploited.


Ports can't be hacked but the application listening on them can ;)

You can have vulnerabilities on the server software and its configuration even if you are serving only static content. This should be unlikely if you use up-to-date battle-tested software like nginx without making crazy config changes.

If you serve dynamic content, that may also have vulnerabilities that hackers can exploit.


Agreed, especially with regards to Stellarium, although this seems more of a researcher's tool than a hobbyist's tool.

There's an excellent web version of Stellarium, if anyone's interested: https://stellarium-web.org/


Wow, so many Starlink satellites overhead!


I think bullet points capture the worst of both worlds. You have text (which people focus on, rather than on the presenter), but you don't have enough that one could learn from them outside the presentation.

There's a saying that bullet points are called so because they 'kill' a presentation, and I think there's some truth to that.


I think short bullet points are great. That way the audience can take them in quickly (I highlight one at a time to prevent them from reading ahead/behind) without being distracted for more than a fraction of a second. It also helps people to see how many items are being discussed (e.g., "there are three reasons that language X is better than language Y"). For me at least, that makes it easier to remember the reasons, since it functions as a checksum.


Do you mean that full paragraph is better? Strong disagree if so.


Perhaps not full paragraphs, but the phrase-style nature of bullet points has never really helped me understand the material. If there must be text, I would rather see complete sentences on a presentation.

I've used the assertion-evidence framework[0] for presentations[1] before, where the idea is to have a complete sentence at the top of your slide, with images below that illustrate your point.

[0] https://www.assertion-evidence.com/ [1] While these presentations _were_ about engineering, they were more educational than technical in nature.


Not OP, but I think the same concerns are present here as well. If anything, I would argue that they're magnified, since fingerprints are unique.

IMO, the issues surrounding biometrics stem from the fact that they define you, in a way that nothing else - not a name, not an address - can.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: