This is where I disconnect. The internet is not broken. Maybe arguably the _web_ is broken, and specifically, web pages are broken (the HTTP protocol is still a wonderful thing).
I wish technical authors would stop making the internet-is-broken meme when they really mean the web is broken. Sure, there's plenty broken with the internet in other ways (DNS, encryption, governments, ddos's, etc.), but let's not make the mistake that the internet equals the web.
First class netizens are publicly routable nodes with statically allocated IP addresses. These have real, honest Internet connections, they get to participate in the global community of humans and their beloved machined.
The second class is like the first but the service provider has imposed restrictions on their ability to communicate freely with other machines, such as blocking any packets they may send on specific protocols and ports, notably, TCP port 25, meaning these people cannot send their own email.
The third class is like the second, but they do not have statically allocated IP addresses, they therefore cannot reliably and consistently participate in the global community and must jump some amount of hoops to even participate in a limited way.
There is a hidden fourth class too, these cannot be considered as having a connection to the Internet, they cannot participate, only passively consume existing services, their machines are not connected to the internet, but another network, and their service-provider will just barely allow them to make requests to services on the real Internet, but it will not route any new connections to them, they are cut off and isolated, the silent majority. And this is where the brokenness of the Internet truly shines. This mode of connection should be illegal, and hiding yourself in this way should be an active choice on the part of the individual, not imposed by their "service provider".
They cannot run a mail server, you mean. For sending mails, you have port 587 plus authentication, which also solves the reputation issue with dynamic pools.
The reputation issues with dynamic pools likely stem from malware-infected user machines sending spam.
> (the HTTP protocol is still a wonderful thing).
But almost all websites are requiring an HTTPS and you know what? I have a dozen of dumbphones who can not access webpages because HTTPS is no longer supported by vendor of device or absolutely can not access https because handshake process takes too long time for gprs (if no edge). If HTTP is so wonderful than why I can not use it without all the stupid security?
The issue that the world has switched to HTTPS might be an interesting discussion. But the HTTP protocol itself still drives what's going on to send/receive data between client and server.
With BGP it's just about limping along with trust
https://www.bleepingcomputer.com/news/security/major-bgp-lea...
(It might be a bit tricky to find an HTTPS configuration that supports for both modern and extremely old browsers, but it should be possible)
For the majority of users, man-in-the-middle attacks (by someone other than your ISP) will never be an issue. It's mostly a theoretical problem. Your connection at home (and your laptop) is as safe as your Wifi connection. Your mobile connection is probably more secure. And there is no hacker sitting in your coffee shop waiting to p0wn your connection to Facebook or send you a 0day. HTTPS is necessary for the whole world to trust e-commerce, but saying everything has to be encrypted is ridiculous.
The most likely MitM anyone will ever experience is DNS cache poisoning, and that's pretty rare.
And I don't believe it is possible to have an HTTPS configuration that suits both old and new browsers since new browsers regularly deprecate older versions of SSL/TLS. I think that anything less than TLS 1.2 is deprecated in many browsers now. and TLS 1.2 is from 2008, way too modern for a website focused on compatibility.
For compatibility, HTTP is your only choice, secure protocols are likely to deprecate regularly as new vulnerabilities are found and stronger protocols are made.
There are applications where you want maximum security (e.g. banking) and there are others where it is not only not necessary, but also a hindrance (ART, for example)
It's always necessary. We've learned that with http connections, middlemen can inject adware or other crap into the page. https://www.infoworld.com/article/2925839/code-injection-new...
Last year I traveled to my parents house and booted up my old computer which I haven't used from 2014. It was using Ubuntu 12.04, I think.
I could barely browse any websites in Firefox, because of TLS issues.
> That said, browsers that predate CSS do not know what to do with <style> tags, and as a result simply print the styles out at the top of the page. It's pretty ugly and, depending on how much CSS you have, borderline unusable.
> […]
> Forgotten Link Tags
I know external vs inline CSS is pretty much never going to be an answered question, but I feel like there’s a missed opportunity here. In particular because
- External CSS by link element addresses this much better for the backwards-compatible extremes: why even serve the contents of the CSS at all if the browser will just treat it as a comment? That’s just precious bandwidth wasted.
- Taken to extremes, external CSS relaxes the use CSS sparingly principle if you strategically break up the link tags to align well with likelihood of support/value ratio. Using media attributes to split CSS payloads can improve UX for old/underpowered mobile devices and even desktops/laptops with lower resolution screens. Detecting support for (ahem) @supports can open all kinds of CSS minimization doors for newer but lower power devices. Segmenting stylesheets by capabilities and preferences allows compatibility improvements regardless of point in time!
And a minor nit: if you’re dithering images for file size it’s worth comparing against a non-dithered version with a small color palette. The latter might actually be better for everyone!
Oof and that prompted a larger one: you can improve UX for ~every real visitor with <picture> tag and more efficient formats, and you could also sorta skirt the no-JS rule and upgrade pre-picture browsers to PNG with a simple inline onerror.
I’ve been living in backend-land for so long I’ve never actually used the <picture> tag. I will have to take a stab at it and see how the legacy browsers treat it, because if I don’t have to use GIFs, I won’t.
As for the @media tags, I do utilize them to a degree, just to make everything render nicely on mobile and to support dark-mode. But (to put it cheekily) I’m more concerned with backwards compatibility than forwards compatibility :p
I definitely recognized that! My thought was take that backcompat focus further and relegate whatever forward compat you do choose to support not to @media queries, but the media attribute on link tags[1]. Why should HTML 4 browser users download dark mode CSS they can’t use? ;)
1: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li...
(Since any extensions had this problem, when they were introduced, they all support enclosing HTML comments. Otherwise, there wouldn't have been any chance for becoming broadly adopted.)
Regarding dithering: I recall a few sites with duotone dithering, which was a nice effect. And, of course, to bring down file sizes and optimize results, you could always manually compose from dithered and undithered images using the same palette.
That was part of the reason for inlining the CSS. The other part (which I didn’t explain in the post) actually came about because of Mosaic.
Even though it didn’t support CSS, it was aware of link tags and added a button to the top of the window for each one (literally linking to the referenced file). I couldn’t dig up a way to disable that within the code, so I went with the commented-out inline method to get the experience I was looking for.
The TFA failed to mention websafe colors. I still have that poster hanging on the wall: http://www.visibone.com/color/poster4x.html
set $need_http_upgrade "$https$http_upgrade_insecure_requests";
location / {
if ($need_http_upgrade = "1") {
add_header Vary Upgrade-Insecure-Requests;
return 301 https://$host$request_uri;
}
index index.php index.html;
try_files $uri $uri/ /index.php?$query_string;
}
Thanks for the tip!
Again and again: It's not the internet broken, its only HTML plus the required interplay of a bazillion of specs.
Almost all "other" protocols, have been replaced by HTML over HTTP. (from chat applications, web interfaces for mail, forums instead of newsgroups, etc.)
1. When I say "as backwards compatible as possible," I mean that this website will be usable on as many browsers, connections, and hardware as I can reasonably support
2. Raw HTML is Your Friend Remember the <FONT> tag? And <TABLE> based layouts? What about <CENTER>? I do
3. I won't go into the technical details here (Low Tech Magazine does a far better job explaining it than I can), but the thing to know is that dithering allows you to reduce the filesize of your images by reducing the amount of information it takes to render them
4. OldWeb.Today The most frequently used tool in my arsenal, oldweb.today is a website that allows you to emulate a number of different retro browsers (from NCSA Mosaic to Netscape Navigator) from directly within your own browser
I practice a lot of these things on my website locserendipity.com, and the associated search engine, which is the only one that you can download with a working index, albeit it is limited to only around a million entries.
This experimental search engine indexes all of the .edu pages on DMOZ circa 2010. It also has a local index: https://locserendipity.com/edu.html?q=amateur%20radio
So far it's pretty much usable in IE6 and Mosaic 2 (1993).
I used to love Caddy. Not so after the move to 2.0 when they got the json formatted config thing going on. Of course there is still Caddyfile but most of the time I'm bashing my head on their json focused documentation page to find out how can I do that same thing from a config file. I'm pretty sure there might be somewhere but I don't want to read a book I just need a nice quick web server that runs from a single binary like v1 did.
> My daily driver is a mid-2012 MacBook Pro that will stop receiving all updates (security included) from Apple by the end of this year. While I personally intend to keep it alive with Linux, this isn't a path that is readily available to most people. What are most people supposed to do in this situation to save some money and avoid adding more junk to our landfills?
I’m in the same boat with the same machine. Have you heard of Open Core Legacy patcher? The 2012 machine is apparently the cut-off for ‘everything works’ but I’m really curious about the definition of ‘works’. Also, the security implications of using it, of course.
(I’m assuming OP is the author)
If someone is using a screen reader, low-contrast/high-contrast setting, translator - plain txt simply works. For more intricate content like schematics, equations, offer a link to PDF.
I am not sure if the lack of mention of Lynx was an oversight.