I remember that PIC project. I don't know if source was ever released, but I recall a lot of folks being very dubious about the claims made.
Quote:
The PIC has 1024 words (12-bits) of program ROM,
~256 bytes contain a hand-crafted RFC1122-compliant implementation of TCP/IP including.
HTTP/1.0 and i2c eeprom Filesystem, using 3 to 99 instructions.
TCP and UDP protocol stack, using 70 to 99 instructions.
ICMP [supports upto ping -s 11], using upto 14 instructions.
IP - Internet Protocol, v4, using 68 to 77 instructions.
SLIP - Serial Line IP packetisation, about 76 inst
Fully buffered UART, upto 115200 bps, using 38 to 56 instructions.
Operating system: RTOS with Rate Monotonic Analysis, using 3 to 15 instructions.
Well, given that the modern web has a lot more requirements for security to even permit most browsers to view a site, it makes sense that the base hardware needs have increased noticeably.
Exactly those PIC18 devices, still in production and on sale, w/o any changes during the years: http://utronix.se/
Of course, no https, but.. it is not a platform limitation, just an undemanded feature: how would you get a https cert for 192.168.0.1 or a similar intranet address where those device suppose to work? They are just not for cloud datacenters
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.
The problems here is not that hardness, and not even yearly certificate updates, or bothering with new certs on every IP address change, but (as the commentator above rightly pointed out)...
1. Planned obsolescence built into HTTPS: no HTTPS-aware server device from year 1999 would work with 2023 browsers. Just because "too old crypto". Plain HTTP works.
Being on a buy side I am against HTTPS in such devices, but I understand the sell side's position.
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.
And further, while edge cases around MitM do exist, the reality is really that it'd almost certainly just fine if someone's personal blog was just http in 99.99% of cases. But most of the web traffic isn't someone's blog and it really should be encrypted, and it's simple enough to set up for free nowadays, so it's going to be far easier to get most of the web to be encrypted if we increasingly work to phase out http.
Yes, small blogs are a 'casualty' of this progression towards expecting HTTPS in that they have to put a tiny bit more work in, but if we didn't do this we'd be back in the days of nitpicking about every single 'acceptable' case of http while vendors use the fact that it doesn't have widespread adoption to leave session cookies in plaintext requests for tools like fire sheep to grab.
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.
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""
I get that. I understand why viewing http is insecure, I dont understand why serving it is insecure.
Apparently this rubs people the wrong way. I get it, run Lets Encrypt and certbot blah blah, but if I am hosting an ESP32 in my house for a hobby project, I running HTTP on the LAN.
> I get that. I understand why viewing http is insecure, I dont understand why serving it is insecure.
Presumably you are serving that content so it can be consumed no? It's not like your consumers can consume https if you only serve http. But yeah I suppose if you are serving read-only content and don't give a shit about what happens client side, there's a lot less reason for https.
Serving data via http is insecure because that data can be intercepted, read and modified.
If it's entirely public data then there's no security risk to the server. The security benefit is for the clients, so unless you hate your users you should use encryption even for totally public static data.
> I understand why viewing http is insecure, I dont understand why serving it is insecure.
People are assuming you want others to be able to see want you are serving. In such case, the server is the only one who can secure the transmission to prevent MITM. The viewer cannot reach over and add in https into the request to prevent their ISP from injecting ads (or other kinds of MITM changes).
You can view pure HTTP website through VPN. It basically encrypted tunnel between you and VPN server through your ISP. So your ISP couldn't try to interject the encrypted connection.
However, your browser might prevent you from connecting to http due to strict https only policy. My browser will stop any connection to http page and throw up a warning.
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.
- 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.
Geocities was bought for $3.6 billion dollars by Yahoo in 1999. It lauched in 1994. The web is only three years older than that.
I had my first website on Angelfire in 1996 before my 10th birthday. WhoWhere purchased Angelfire a year later, and then they were bought by Lycos a year after that for $133 million.
Also, I don't remeber it being fantastic. To me, even with all faults considered, things are much nicer today.
That's bullshit when you're accessing my website, where I have some photos of some old science projects and that's it.
A much better middle ground would have been for websites to advertise certain features (login, user accounts) and for browsers to warn when not using SSL. Or to do it based on some heuristic, such as cookie use on a given domain.
The current implementation keeps everyone non-technical from using http, which is a loss for everyone.
Google unilaterally got to make this decision for everyone. Small websites don't matter to their bottom line anymore. They've already scraped and indexed the content, pulled the value away onto walled gardens, and left that web to rot.
I read that from recent magnolia commits, it falls back to {12,1}ft for some websites (apparently, some techniques cannot be done on client-side, perhaps, they require proxies in particular countries or google network to impersonate googlebot better)
This is not a country that lives off taxes from the little people, it lives off the sale of natural resources.
Moreover, many people are in a grey area of the economy, paying no taxes at all: for example software developers making software for the West.
Looking at the ridiculous "sanctions" of recent days, I cannot say who they are directed against. In long run, they benefit Russia, preventing leaking of brains and capital.
Lyon Feuchtwanger, a Jew and anti-fascist who fled Hitler's Germany, lost all his savings in banks in the US, Canada, Britain and France. Because of the sanctions imposed on him as a German citizen. The only bank he still had money in his account in 1945 was ...German.
We've always had a policy that almost anything goes excluding human rights abuses and especially war crimes and supporting violence. Nothing changed here.
Honestly, if Namecheap wants to earn my respect back after this their only option is to ban me and their other US customers for the crimes of the US government, but they won't because the US market is too lucrative for them to lose.
Well from their website they have 3 offices and 1700 employees in Ukraine so I'd guess this hits a lot more closer to home for them than your simulated conversation suggests.
I would have assumed that to mean, very specifically, that you wouldn't do business with, for example, a Private Military Contractor accused of human rights abuses. The specific business. Not brushing off the individual citizens of an entire country collectively, no matter their agreement with the war, for the issues you have with the country's governance. In some cases, they would have assumed themselves safe with you, in fact, because they were not seemingly aligned with their government and more aligned with Western values, and thought you would be more censorship-resistant. Far from them, I am certain, would be the idea that you would be the first to threaten their domains when they can't even pay for another registrar. (Which is another thing that would have been a good reason for, say, a Russian activist to renew with long 5+ year terms, which... Are you going to refund those? Or just tell them to figure it out?)
I mean, I can understand where you're coming from, but it's a stretch. I would not think that's what the language means in the terms. At all. It would make an activist's day 1000x worse. Imagine if they're right now being detained and can't renew or move their domain (and this is why they took a 5 year term with you!) and they can't even see this email or this discussion. You might make the worst week of their life into a much worse one. It seems bad for business. Just saying. Older netheads expect the net to be censorship resistant, not ban-happy, for what it's worth.
Net neutrality is a concept in American telecommunications law, not an international political or philosophical concept.
It has nothing to do with Russia, and even less to do with services running on the Internet: it solely concerns itself with the relationship between ISPs and the traffic they carry. Namecheap is not an ISP.
It is really hard to me to answer this. I was able to find a private Russian-based registar, which at least on the surface has no ties to the government or government-controlled entities and works with ICANN directly.
Other people are trying to move to Cloudflare -- but my banking cards are already not working, and I can't pay in USD for their services. Plus to that, even if somebody manages to move to Cloudflare or GoDaddy, there's no guarantee that they won't pull the plug as well.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
It is very possible that `gyrovague` is not `japatokal` but an impersonator.