I got a gateway error. Perhaps it "works on your machine" only. :-D

Perhaps it would work better on a cluster of these.

we didn't stop hosting websites on hardware like this because it's impossible. we stopped because spammers made it impractical.

well not sure what i expected but it seems to be down lol

Looks burnt out now

...but not for long

Sure seems like it!

Sat sri akal

How the heck did you get a kubernetes cluster to run on a esp32?!

Sorry, where's the assumption it's using kubernetes coming from? All I see in the response is nginx which doesn't imply anything k8s. The blog linked from the page doesn't mention k8s either (nor nginx).

That said, you can run an ingress for a service that's just an externalname reference with the right annotations depending on your ingress controller and I'm pretty sure it'd just work.

Its still a single esp32 s2 mini. Its Nginx that is saving this little mcu !!

I didn't do any breadboarding at all, I just jumped off the cliff with this. I started by designing a 1"x1" PCB in EasyEDA with just the MCU and pin headers, and had five manufactured/assembled by JLCPCB to test the core of it. The first time I'd ever touched an ESP32 was when I got those PCBs in the mail and started trying to program them! It was really fun.

Once I'd proved it worked, I pasted that 1"x1" layout into a larger footprint, and added the sensor, power supplies, and batteries. Again, I had no real way to test any of the new stuff: I just iterated until I stopped finding problems to fix, then had them manufactured. A big part of the fun of this has been having to commit to a design without the ability to test: it really makes you think. I also enjoy the exercise of writing as much of the firmware as I can while the hardware is in the mail, then seeing how much actually works when it shows up.

In terms of bad decisions... I used builtin gpio pull-up resistors for I2C: it works, but the margin is very tight, it's just not worth it (and also means I can't put the ESP32 in sleep mode in some cases...). Wifi uses phase to encode information, so having no RF matching will impact its performance beyond the -6dB I mentioned in the README. The inductor/capacitor values are much larger than necessary. The routing of the I2C lines taking a huge bite out of the ground plane under the switcher IC is dubious. Using 1.5V alkaline batteries is nice because I don't have to worry about burning my house down... but I've gone through 200+ AAA batteries over the last year, and it feels very wasteful.

I learned most of what little I know about PCB design from this youtube channel, I can't recommend it enough: https://www.youtube.com/@PhilsLab

Next step is a system integrator like m5stack.com, either build a nice unit from their library of components and let them worry about the minor issues (power regulation etc). If you're prototyping at home just put them in your own enclosure, if you want to go industrial you can 3d print something that integrates with their stuff (eg user-friendly modules like Core) or use the stamp components.

If you have done all the circuitry want to just print/assemble your own PCBs, sites like PCB unlimited will make up short runs or Digikey will handle larger scales.

I usually use https://oshpark.com/ or https://jlcpcb.com/ with EasyEDA or Kicad depending on what you're comfortable with. A good 3D printer wouldn't hurt either.

There was no real goal beyond the experience of building the thing and making it work. I use them to monitor stuff like fridge/freezer and HVAC intake/output, and as leak detectors in my crawlspace.

As you'd probably guess, the fixed cost of the manufacturing was extremely high. Unfortunately I didn't write the numbers down... but going from memory, ordering 5 instead of 30 would have only reduced the total cost by ~20%. I remember a weird valley in cost-per-unit at a quantity of 30: my understanding is that JLC combines small orders, so my guess is that 30 of that board was the largest order they were willing to squeeze onto the same panel as another one.

Just did it !! Enabling 10m caching on nginx now (It is good atleast now the link will open from HN homepage). Thanks for suggesting this, I should have done it before

Its good idea, I never tried or probably didn't know much about nginx caching. Will Nginx cache webpage and serve directly without hitting much the esp32 server. I am going to read on it now

You can make an HTTPs certificate with that in the SAN section, and it should work fine. You can't get one from a publicly trusted provider, of course, but that's fine; you don't own the IP.

In other words, make your own certificate authority for your own machines. It isn't that hard.

Well yeah, anything is easy if your server isn't doing the work.

Likely possible to handle HN load just fine... if the page was static.

edit: page loaded. It's apparently Microdot, a micro web framework running on micropython.

My website runs on baling twine and duct tape (...and CloudFlare).

Just DDNS

You can get around the issues of CG-NAT by setting up a reverse tunnel to an external server you control.

Everything should be served securely these days. Prior to HTTPS being absolutely king, ISPs here used to inject EXEs with malware and do all sorts of nasty stuff. With HTTPS dominating they don't do that sort of thing anymore as the share of HTTP traffic is so low making ROI very low.

Anyway I'll give you one reason based on the above on why you should serve your content over HTTPS, it shields you from potentially having your visitors be victims of something like this and in all likelihood they will blame you for whatever malware their ISP sent their way... they did get infected from your website, after all.

People can be really tedious when it comes to this subject. Like, for the authenticity use-case, the server could present its certificate followed by a signed but unencrypted page, in a standard way so the browser could check the signature. Then the signature for static resources can be cached on the server (or middle boxes) and no key exchange or encryption is needed, greatly reducing computational needs to serve a page while still keeping it essentially secure. There's also fewer hops in this scenario (so better user experience), and it's easier to do things like filtering with a simpler proxy without needing to install CAs. But no one wants to have a productive conversation about actual trade-offs here.

Edit: in fact, if we used client certs for user identity[0], signed requests could also be used for form submission for e.g. public forums or youtube uploads where you might not care about privacy of the submission itself.

[0] https://news.ycombinator.com/item?id=38129870

One of the reasons is to prevent ISP and other to intercept the page and interject the codes before it arrives to the users. It a common method to put the payload in the http. I believe it called middle-in-the-man method. With https, it reduced a lot of attacks.

There was a news about Comcast interjected a Steam storefront page with a data cap warning on it to a Comcast subscriber. And this happened inside Steam app which was using http at the time.

HTTPS doesn't really have to do with whether the page content is sensitive. It's more about protecting visitors from MitM attacks, traffic analysis, and their browser screaming at them and refusing to load your site because it's ""insecure""

Some ISPs modify the content and inject ads in HTTP web sites.

Having HTTPS as the only option for a site is an excellent default, both for protecting the confidentiality and integrity content, as well as validating the identity of the site for the client. Maybe a good way to put it is that the vast majority of the site's uses and data needs no protection, but protecting all of it well is probably much easier to do correctly than just selectively encrypting the important parts.

My humble little personal site has largely unauthenticated, static blog stuff. It also has personal apps that nobody else uses, but I want to protect the authentication bits.

You can serve to yourself whatever you want, but please don't make other people leak what you've served them.

You obviously don't need to serve your static blog over HTTPS, but I think it would be nice of you to serve it over HTTPS anyway!

> Some people are super sensitive about what ports I serve text on

If I thought the key difference between http and https was which port it is served on, I’d probably be confused by people’s reaction too.

You're being downvoted, but you're right.

I'm fine serving my personal website under http.

- If someone is worried they'll be found out using my site, then fine, don't use it. This advice is just for my site, and it's fine to desire security elsewhere and in other contexts.

- If an ISP or MITM want to inject some content in my website, then fine. We'll all know not to use those providers. I promise I'm not important enough for this to be a vector someone would want to exploit.

None of the information I have to offer you requires HTTPS. I assure you.

I think it's fine that https is becoming the default, especially for web services. But we shouldn't enforce it. It's an undue burden to have to support all the certificate machinery just to serve some basic info.

We really need to get back to the basic, easy to hack web. Where it took nothing to spin up services on your home machines and serve them as demos to others. That ethos was great.

> Not everything needs to be encrypted. If I'm serving static webpages the only thing I might want to log is the which IPs visited at what time of day.

As a frequent user of public WiFi (mostly at coffee shops, airports, etc.), I prefer that every page is encrypted so that nobody can MITM me/tamper with what I see in my browser, even on plain text pages.

Where does logging enter into it? To my understanding, serving traffic over HTTPS doesn't require you to do any additional logging (or any logging at all).

The point about static webpages would be a potentially good one in a world where ISPs and other Internet middlemen are honest and transparent actors, but this has so far proven not to be the case. I think it's in everyone's interest for your static content to reach my browser without ads or tracking mechanisms being injected by a third party.

I agree that not everything needs to be encrypted, but unfortunately a lot of people who browse the web are concerned when the browser complains that something is not secure.

From the browser maker's side, how does a browser know whether something should or should not be secured? They have clearly taken a more aggressive approach to inform users what is going on within the underlying protocol. While I do agree that not everything needs to be encrypted, I also agree that the user should know what is or is not happening under the hood.

Isn't HTTPS needed to stop injection by ISPs?

If everything that didn't _need_ encryption wasn't, then the use of encryption could be suspicious in itself. For my part I'm glad that we've moved to a mostly working system of encryption most things

How can you reliably know that you're not being MITM without HSTS?

I don't remember that being the reasoning:

https://www.youtube.com/watch?v=cBhZ6S0PFCY

Google I/O 2014 - HTTPS Everywhere

https://developers.google.com/search/blog/2014/08/https-as-r...

you're still not getting it

it doesn't matter what content is being served

the point is if your site is on HTTP a third party may silently inject malicious code into the response.

any visitor that views your site now becomes subject to this threat vector.

you may argue nothing will come of it, sure, but then you should make that your argument.

Weelll they could use a vpn

Not everywhere though. The idea of an ISP in France injecting content is insane (and wild be completely illegal as well)

Then leave whatever tech backwater you live in and move to the first world.

> At the registrar level: the .tk registrar was (in)famous for injecting both ads and random JS into websites that were hosted on domains registered against it.

I did a google search for domain hijacking, ad injection, javascript and while it does look like .tk domains had/have this issue it doesn't necessarily point to the registrar. After all they are offering free domain registration which is going to get abused. Its also not surprising when their own website doesn't use HTTPS, however their mission statement isn't about security on the Internet.

> The goal is always more (and more precise) data points. Being able to run JS on the same origin as the request is more valuable than just the rough GeoIP data the ISP already has.

But isn't this what Google, Bing, Amazon, Alibaba, already do when they fingerprint your device? They can't use just an IP addresses due to NAT so they collect unique characteristics to your specific device. My question was more so if advertisers can already get down to the device level when you visit their site, what is the ISP's motivation if their data won't be as unique or specific? or maybe a better question is what organizations would be buying the "less" specific data that an ISP could get from your session data?

I'm sure there is some nuance to what someones static site is serving but someones blog doesn't need to be HTTPS. If they are offering downloads you can provide checksums or verify their data through other sources or contacting them out-of-band.

Anything that needs some form of validation from any site should be verifiable in multiple ways. Just because they have HTTPS doesn't mean the provided information or data is automatically correct.