You're just very opinionated. Other software engineers just give you space because they don't want to confront you and they don't want any conflict with you as it's just waste of time.
6 months is also average time it takes people like you to burn out on a project. Usually starting with relatively simple change/addition requested by customer that turns into 3 month long refactor - "because architecture is wrong". And we just let you do it, because we know fighting windmills is futile.
I don't see it having any better performance than integrated chrome pdf viewer. Furthermore, with it using wasm i'd expected it to have custom renderer, but it's just pdf to html converter.
And loading times are quite bad (10 times slower - compared to firefox or chrome pdf viewers).
Loading the mupdf.js bundle is slow right now. When I checked it out it was super fast. Guess it's a server/ratelimit/caching issue with the HN hug being top of front page.
Which is what I guess you mean about 10x slower -- so you're making an unfair comparison as you're counting the network at peak, whereas browser plugins load from disk or memory.
But I actually thought the load of the PDF (once the app was loaded) was, for MuPDF.js, slightly faster than the browser plugin. When I watched it, tho I have not benched it. Do you have any benchmarks?
The main issue is that you can port scan all those IPv4 addresses in minutes. It's impossible for v6 so the issue, even without a firewall, isn't a big issue.
I know you can do address harvesting like it was done with pool.ntp.org by shodan but if you don't use any public services your IoT devices are basically protected by the 128bit address space. So you need a address harvesting possibility, and people are watching for this as seen in the shodan case, and an exploitable issue at the same time. Not impossible and you should use a firewall but orders of magnitude less scary than a public routable IPv4 address.
Consumer routers typically have a firewall. Additionally all those IoT devices are able to obtain these publicly routable ipv6 addresses already in millions of homes, its just the numbers are lower
Possibly never, because security. NAT at least tries to hide insecure IoT device on your grandma's wifi.
shodan.io has support for ipv6. With ipv4 you're somewhat restricted to devices that get public ip (corporate networks) or devices that drill a hole (uPnP/port forward). IPv6 devices are publicly visible by default and you need to manually setup firewall to filter this out (not trivial - especially for UDP and ICMP)
Every firewall I’ve dealt with since forever has default deny on inbound traffic, state full allow for outbound connections. Regardless of NAT or not, and regardless of how cheap it is.
Name one vendor? I can name you 3 that don't. Zyxel, Ubiquiti, Mikrotik. Also anything wrt based (eg. dd-wrt).
In fact one of the warnings on dd-wrt official IPv6 tutorial:
""" Keep in mind it can be dangerous to enable IPv6 without also having a firewall on each client that handles IPv6 packets, or having ip6tables on your router to filter incoming connections. ip6tables is NOT included by default with DD-WRT, which means your clients will be directly exposed to the Internet once you have enabled IPv6. """
Ubiquiti do -- and it's very nice to be able to punch holes in it when I do want to let HTTPS traffic in to specific addresses, rather than need to try to shoehorn everything onto a single IPv4 address.
IPv6 support is sufficiently widespread that pretty much the only place I can't access IPv6-only services from is the office :P.
This is my concern too. NAT is nice because it's stupid and secure by default. No matter how you misconfigure it, the router simply doesn't know where to forward inbound packets to, unlike a firewall which has to actively block. My assumption for routers is that they won't handle firewalls right, especially the many cheapo ones.
It's not actually secure; your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN. This remains true whether or not you're applying NAT to your outbound connections.
If anything, NAT makes you less secure by tricking you into a false sense of security.
(It's also worse if you're deliberately running servers, because it catastrophically reduces the search space needed for a hostile actor to find those servers via network scanning. At least, it does on v6 -- on v4 the search space is already too small to be a relevant factor.)
The routers. My ISP can't route dst=192.168.1.2 to anywhere, and even if someone managed to splice the packet in between my router and the ISP, my router won't take that dst. That address doesn't exist on the WAN.
Okay, but since that's RFC1918 you'll need to give me access to your immediate upstream network in order to send the packet to your router. How do you want to do that?
My ISP supports ipv6 and i have it configured - however their software on the router/AP is bad and does not allow setting up a firewall for ipv6. This is inherent with ipv4 NAT (with uPnP disabled).
So it forced me to use my own router - still the interface for ipv6 firewall is non-existent, but at least i can write firewall rules manually.
Why do I need firewall on router? Because devices on my network have services open on all interfaces - For example "smart" weather station has web service open for all to see. This is absolutely non-issue when only using ipv4 behind NAT.
Another issue is revealing of internal network topology to outside world - this is something that NAT hides really well.
Probably goes to S2 instead of S3 deep sleep. Had the same issue on microsoft surface (running Linux on it) - i needed to tweak few kernel flags to force it into deep sleep.
6 months is also average time it takes people like you to burn out on a project. Usually starting with relatively simple change/addition requested by customer that turns into 3 month long refactor - "because architecture is wrong". And we just let you do it, because we know fighting windmills is futile.