321–327 of 327 posts
Here is an academic discussion [0]. It was published in 2005. It may not cover more recent problems, but the proposed design principles are still valid. [0] Tussle in Cyberspace: Defining Tomorrow’s Internet https://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle...
Earlier quoted context omitted.
>Doesn't it? I guess it's a matter of age and class and nationality. If you're too young to earn money, it's a barrier. If you're in the lower classes of your country, 20$/month can be a lot I was comparing the payment to buying or operating a server (even a free old server has costs, e.g. for electricity). In truth, a proper modern comparison should be to a free plan from one of the cloud providers which is likely t…
> I was comparing the payment to buying or operating a server (even a free old server has costs, e.g. for electricity) Sure, but if the machine is already running, it's free. Or if you can stick it in a cupboard at work/university, it's free. > 0/month is there actually free cloud hosting? don't they ask for your credit card first before they offer you "credits"?
It still has costs for admin and electricity (via extra CPU load), though I grant these could be marginal.
>Or if you can stick it in a cupboard at work/university, it's free.
This is using someone else's resources, rather dubiously ethical. I suspect IT is going to have a fit when they find out - assuming they didn't block the relevant ports in the first place.
>is there actually free cloud hosting? don't they ask for your credit card first before they offer you "credits"?
There are free plans on Azure/AWS/GCP. Asking for credit card data does not mean you are being charged, I suspect it's really more about identifying users.
It's possible to set up free plans without credit card if one has some other id (e.g. Azure's free plans via MSDN). A prepaid card should work as well.
Earlier quoted context omitted.
I'm not sure how having a single code base would help anything. Sure, interopable standards are needed, but what benefit does a single code base get us? > Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). So the scenario here is we add encryptio…
An email provider would need a "to" code from you when you registered with them. Then with each request to download your mail, they send you a randomly generated number encoded with your "to" code, and you respond by decoding it and sending the number back encrypted with another number they give you. They don't have to know where the mail is actually going, or what is in it. Just that they are getting a request from…
I agree you could do schemes like this (although some of the details here would need finessing), i just don't really think it fits the description of at a low enough protocol level its transparent. Like this is custom application logic - it doesn't get much higher level than that. How could an application forget its there if it has to keep track of storing numbers and finding/sending/decoding the right ones. If this generalized to something that fit every application, i'd say fair enough, but it seems incredibly specialized to the example at hand.
If all we're imagining is a standardized set of primitives, we already have that. AES, SHA-256, HMAC are all very well studied and well supported (the public key world doesn't quite have as much of a clear "winner", but there are still very standardized well studied options).
All of these things are very secure when used correctly. People however invariably use them incorrectly. Composing primitives (incorrectly) is one of the big ways people get into trouble with crypto.
I guess what you're suggesting is an opinionated library that has a bunch of safe options to make it less likely to shoot yourself in the foot? I mean, i certainly agree we could do better when it comes to usability of crypto libraries. Ultimately though, no library is going to prevent a programmer from (for example) giving the secret key to the attacker. By extension, we're never going to have a library that takes the thinking out of using crypto. A big portion of computer security problems are simply the programmer accidentally telling the computer to do something silly, and the computer blindly following orders. I don't think its possible to get rid of that if the programmer is the one calling the shots. Which is why i find the idea of automatic encryption on the tcp or ip layer so enticing - your average programmer would have no influence over it - but the idea also seems to have severe technical limitations (or at least it needs someone smarter than me to figure it out)
Earlier quoted context omitted.
I disagree, incentives would be very different imo. > Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning. in WebPKI: - CA's have struct rules (CAB and individual browser vendors) and h…
WebPKI doesn't really solve these problems. CA Audits are mostly about ensuring they're following the rules. However, the rules cannot stop an ISP or hosting provider just issuing themselves a cert and a fully audit compliant CA is not expected to stop this. Cert transparency is mostly unused. For it to work people have to proactively search the logs to find certs they didn't issue, but in reality nobody does this ou…
Earlier quoted context omitted.
People were willing to set exceptions for sites they thought were important. Not important AND requires JS => bye.
I'm not sure the likes of YouTube and Netflix need further privileges compared to the rest of the web.
I've thought about this a lot. I'd throw away HTML/CSS and start over with a client centric rendering protocol that is based on presentation first and semantics second. The language would be run-time compiled to describe exactly what needs to be rendered on the page and would be streamable to prevent rendering locks. Typical page size would go from 1M typical to 64K-128K being typical. Images would stream in after in…
How would this handle accessibility? 64-128K page size is perfectly doable in HTML today if anybody actually cares enough to do it. How much of the bloat in say an Amazon page is the JavaScript? Is there something about your protocol that would prevent the big players from re-normalizing 1M page size with it?
In my tests it would be very difficult to create a 1Mb page. You would need 10,000 text/image/nodes of actual content (not tags or containers). This just doesn't happen.
Presentation is strictly separated from code execution so first load is never blocked by code. Code can dynamically change the page but does so by directly changing the DOM using limited server side-commands. In other words it's truly a thin client browser. You can bloat up the server with as much code as you want but the client side stays lean.
I've thought about this a lot. I'd throw away HTML/CSS and start over with a client centric rendering protocol that is based on presentation first and semantics second. The language would be run-time compiled to describe exactly what needs to be rendered on the page and would be streamable to prevent rendering locks. Typical page size would go from 1M typical to 64K-128K being typical. Images would stream in after in…
Would this really change page sizes significantly? Take amazon landing as an example: * HTML/CSS: 80 KB and 88 KB * Images: 3.2 MB * Font: 180 KB * JavaScript: 260 KB Reducing HTML/CSS to 1 Byte each, would make nearly no difference, because huge parts of pages are in images.
In the developing world they are using the Internet at dial-up speed, only on mobile, and often charged per KB.