6 ms·

In the past, browsers used an algorithm which only denied setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this did n

In the past, browsers used an algorithm which only denied setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this did not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites could set a cookie for .co.uk which would be passed onto every website registered under co.uk. Since there was and remains no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain (the policies differ with each registry), the only method is to create a list. This is the aim of the Public Suffix List. (https://publicsuffix.org/learn/) So, once they realized web browsers are all inherently flawed, their solution was to maintain a static list of websites. God I hate the web. The engineering equivalent of a car made of duct tape.

samlinnfer 1y ago
Wait until you learn about the HSTS preload list.
lukan 1y ago
"The engineering equivalent of a car made of duct tape" Kind of. But do you have a better proposition?
- gmueckl 1y ago
  A part of the issue is IMO that browsers have become ridiculously bloated everything-programs. You could take about 90% of that out and into dedicated tools and end up with something vastly saner and safer and not a lot less capable for all practical purposes. Instead, we collectively are OK with frosting this atrocious layer cake that is today's web with multiple flavors of security measures of sometimes questionable utility. End of random rant.
  - sefrost 1y ago
    You are right from a technical point, I think, but in reality - how would one begin to make that change?
  - lukan 1y ago
    "You could take about 90% of that out and into dedicated tools " But then you would loose plattform independency, the main selling point of this atrocity. Having all those APIs in a sandbox that mostly just work on billion devices is pretty powerful and a potential succesor to HTML would have to beat that, to be adopted. The best thing to happen, that I can see, is that a sane subset crystalizes, that people start to use dominantly, with the rest becoming legacy, only maintained to have it still working. But I do dream of a fresh rewrite of the web since university (and the web was way slimmer back then), but I got a bit more pragmatic and I think I understood now the massive problem of solving trusted human communication better. It ain't easy in the real world.
    - gmueckl 1y ago
      But do we need e.g serial port or raw USB access straight from a random website? Even WebRTC is a bit of a stretch. There is a lot of cruft in modern browsers that does little except increase attack surface. This all just drives a need to come up with ever more tacked-on protection schemes because browsers have big targets painted on them.
      - shadowgovt 1y ago
        How else am I going to make a game in the browser that be controlled with a controller?
        gmueckl 1y ago
        Every decent host OS already has a dedicated driver stack to provide game controller input to applications in a useful manner. Why the heck would you ship a reimplementation of that in JS in a website?
        shadowgovt 1y ago
        So that you can take input from countrollers that haven't been invented yet and won't fit the HID model.
  - nemothekid 1y ago
    >A part of the issue is IMO that browsers have become ridiculously bloated everything-programs. I don't see how that solves the issue that PSL tries to fix. I was a script kiddy hosting neopets phishing pages on free cpanel servers from <random>.ripway.com back in 2007. Browsers were way less capable then.
    - lukan 1y ago
      PSL and the way cookies work is just part of the mess. A new approach could solve that in a different way, taking into account all the experience we had with scriptkiddies and professional scammers and pishers since then. But I also don't really have an idea where and how to start.
      - shadowgovt 1y ago
        And of course, if the new solution completely invalidates old sites, it just won't get picked up. People prefer slightly broken but accessible to better designed but inaccessible.
        motorest 1y ago
        > People prefer slightly broken but accessible to better designed but inaccessible. It's not even broken as the edge cases are addressed by ad-hoc solutions. OP is complaining about global infrastructure not having a pristine design. At best it's a complain over a desirable trait. It's hardly a reason to pull the Jr developer card and mindlessly advocate for throwing everything out and starting over.
        friendzis 1y ago
        > People prefer slightly broken but accessible to better designed but inaccessible. We live in world where whatever faang adopts is de facto a standard. Accessible these days means google/gmail/facebook/instagram/tiktok works. Everything else is usually forced to follow along. People will adopt whatever gives them access to their daily dose of doomscrolling and then complain about rather crucial part of their lives like online banking not working. > And of course, if the new solution completely invalidates old sites, it just won't get picked up. Old sites don't matter, only high-traffic sites riddled with dark patterns matter. That's the reality, even if it is harsh.
  - Kim_Bruning 1y ago
    Are you saying we should make a <Unix Equivalent Of A Browser?> A large set of really simple tools that each do one thing really really really pedantically well? This might be what's needed to break out of the current local optimum.
    - gmueckl 1y ago
      I haven't thought of it that way, but that might be a solution.
      - magackame 1y ago
        There was an attempt in that direction. https://www.uzbl.org/ https://www.uzbl.org/
    - acka 1y ago
      Maybe it's time to revive something like the uzbl[1] project, or start something similar. [1] https://www.uzbl.org/ https://www.uzbl.org/
- jadengeller 1y ago
  I'd probably say we ought to use DNS.
  - asplake 1y ago
    And while we’re at it, 1) mark domains as https-only, and 2) when root domains map to a subdomain (eg www).
    - account42 1y ago
      I might amuse you to know hat we also already have a text file as a solution for https-only sites.
- Groxx 1y ago
  I'm under the impression that CORS largely solves it? which is still much too new to be able to shut down the PSL of course. but maybe in 2050.
  - Groxx 1y ago
    Since this is being downvoted: no, I'm quite serious. CORS lets sites define their own security boundaries between subdomains, with mutual validation. If you're hosting user content in a subdomain, just don't allow-origin it: that is a clear statement that it's not "the same site". PSL plays absolutely no part in that logic, it seems clear to me that it's at least in part intended to replace the PSL. Do other sites (like google's safety checks) use CORS for this purpose? Dunno. Seems like they could though? Or am I missing something?
- 0xbadcafebee 1y ago
  Cookies shouldn't be tied to domains at all, it's a kludge. They should be tied to cryptographic keypairs (client + server). If the web server needs a cookie, it should request one (in its reply to the client's first request for a given url; the client can submit again to "reply" to this "request"). The client can decide whether it wants to hand over cookie data, and can withhold it from servers that use different or invalid keys. The client can also sign the response. This solves many different security concerns, privacy concerns, and also eliminates the dependency on specific domain names. I just came up with that in 2 minutes, so it might not be perfect, but you can see how with a little bit of work there's much better solutions than "I check for not-evil domain in list!"
  - progval 1y ago
    > They should be tied to cryptographic keypairs (client + server). So now, if a website leaks its private key, attackers can exfiltrate cookies from all of its users just by making them open an attacker-controlled link, for as long as the cookie lives (and users don't visit the website to get the rotated key). > If the web server needs a cookie, it should request one This adds a round-trip, which slows down the website on slow connections. > the client can submit again to "reply" to this "request" This requires significantly overhauling HTTP and load-balancers. The public-suffix list exists because it's an easy workaround that didn't take a decade to specify and implement.
    - 0xbadcafebee 1y ago
      > So now, if a website leaks its private key, attackers can exfiltrate cookies from all of its users just by making them open an attacker-controlled link This attack already exists in several forms (leaking a TLS private key, DNS hijack, CA validation attack, etc). You could tack a DNS name onto the crypto-cookies if you wanted to, but DNS is trivial to attack. > This adds a round-trip, which slows down the website on slow connections. Requests are already slowed down by the gigantic amount of cookies constantly being pushed by default. The server can send a reply-header once which will tell the client which URLs need cookies perpetually, and the client can store that and choose whether it sends the cookies repeatedly or just when requested. This gives the client much more control over when it leaks users' data. > This requires significantly overhauling HTTP and load-balancers No change is needed. Web applications already do all of this all the time. (example: the Location: header is frequently sent by web apps in response to specific requests, to say nothing of REST and its many different request and return methods/statuses/headers). > The public-suffix list exists because it's an easy workaround So the engine of modern commerce is just a collection of easy hacks. Fantastic.
modeless 1y ago
Show me a platform not made out of duct tape and I'll show you a platform nobody uses.
- vincnetas 1y ago
  regular cars?
  - MonaroVXR 1y ago
    The Honda issue where setting a certain radio station, would brick the infotainment? That good enough?
    - dgoldstein0 1y ago
      Never heard of this. Link please?
      - shakna 1y ago
        Don't know about Honda, but there is this Mazda one [0] (Would not be surprised if it affected multiple vendors!) [0] https://www.soundandvision.com/content/remembering-time-when-radio-station-bricked-your-car-s-radio https://www.soundandvision.com/content/remembering-time-when...
        dgoldstein0 1y ago
        Yikes. I missed that. Makes sense it wasn't just the station it was tuned to but the particular data they broadcasted; insane there was no way to power reset the system into a good state.
      - deleted 1y ago
        [deleted]
    - alias_neo 1y ago
      > That good enough? Not really. Does the car still drive? That sounds like a software bug; hardly indicative that the entire car is held together with duct tape, but a pretty bad bug non the less.
starfallg 1y ago
That's the nature of decentralised control. It's not just DNS, phone numbers work in the same way.
lucideer 1y ago
> God I hate the web This is mostly a browser security mistake but also partly a product of ICANN policy & the design of the domain system, so it's not just the web. Also, the list isn't really that long, compared to, say, certificate transparency logs; now that's a truly mad solution.
KronisLV 1y ago
> Since there was and remains no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain A centralized list like this not just for domains as a whole (e.g. co.uk) but also specific sites (e.g. s3-object-lambda.eu-west-1.amazonaws.com) is both kind of crazy in that the list will bloat a lot over the years, as well as a security risk for any platform that needs this functionality but would prefer not to leak any details publicly. We already have the concept of a .well-known directory that you can use, when talking to a specific site. Similarly, we know how you can nest subdomains, like c.b.a.x, and it's more or less certain that you can't create a subdomain b without the involvement of a, so it should be possible to walk the chain. Example: c --> https://b.a.x/.well-known/public-suffix b --> https://a.x/.well-known/public-suffix a --> https://x/.well-known/public-suffix Maybe ship the domains with the browsers and such and leave generic sites like AWS or whatever to describe things themselves. Hell, maybe that could also have been a TXT record in DNS as well.
- IshKebab 1y ago
  I presume it has to be a curated list otherwise spammers would use it to evade blocks. Otherwise why not just use DNS?
  - inopinatus 1y ago
    Whois would be the choice. DNS’s less glamourous sibling, purpose built for delegated publication of accountability records
    - IshKebab 1y ago
      Whois isn't curated either.
      - inopinatus 1y ago
        Neither is nominating a third party for your parking fine. The point is to get away from centralized gatekeepers, not establish more of them. A hierarchy of disavowal. It’s like cache invalidation for accountability. If you don’t wanna be held responsible for something, you’d better be prepared to point the finger at someone whois.
formerly_proven 1y ago
Why is it a centrally maintained list of domains, when there is a whole extensible system for attaching metadata to domain names?
jacquesm 1y ago
I think we lost the web somewhere between PageRank and JavaScript. Up to there it was just linked documents and it was mostly fine.
thomasjb 1y ago
What we need is a web made in a similar way to the wicker-bodied cars of yesteryear
vladms 1y ago
> God I hate the web. The engineering equivalent of a car made of duct tape. Most of the complex thing I have seen being made (or contributed to) needed duct tape sooner or later. Engineering is the art of trade-offs, of adapting to changing requirements (that can appear due to uncontrollable events external to the project), technology and costs. Related, this is how the first long distance automobile trip was done: https://en.wikipedia.org/wiki/Bertha_Benz#First_cross-country_automobile_journey,_1888 https://en.wikipedia.org/wiki/Bertha_Benz#First_cross-countr... . Seems to me it had quite some duct tape.
- szszrk 1y ago
  Why would you compare Web to that? A first fax message would be more appropriate comparison. Web is not a new thing and hardly a technical experiment of a few people any more. If you add the time since announcing the concept of Web to that trip date, you have a very decent established industry already. With many sport and mass production designs: https://en.wikipedia.org/wiki/Category:Cars_introduced_in_1924 https://en.wikipedia.org/wiki/Category:Cars_introduced_in_19...
  - vladms 1y ago
    For me the web is something along the lines at the definition of: https://en.wikipedia.org/wiki/World_Wide_Web https://en.wikipedia.org/wiki/World_Wide_Web to sum up "...universal linked information system...". I think the fax misses many aspects of the core definition to be a good comparison. Not sure what is your point about "decent established industry" if we relate to "duct tape". I see two possibilities: a) you imply that the web does not have a decent established industry (but I would guess not). b) you would claim that there was no "duct tape" in 1924 car industry. I am no expert but I would refer you to the article describing what was the procedure to start the car at https://www.quora.com/How-do-people-start-their-cars-in-the-1930s-I-read-that-people-have-to-turn-something-in-front-of-the-car-is-that-true https://www.quora.com/How-do-people-start-their-cars-in-the-..., to quote: > Typical cold-start routine (common 1930s workflow) > 1. Set hand choke (pull knob). > 2. Set throttle lever to slight fast‑idle. > 3. Retard spark if manual advance present. > 4. Engage starter (electric) or use hand crank. > 5. Once running, push choke in gradually, advance spark, reduce throttle. Not sure about your opinion but compared to what a car's objective is (move from point A to point B) to me that sounds rather involved. Not sure if it qualifies as "duct-tape" but definitely it is not a "nicely implemented system that just works". To resume my point: I think on average progress is slower and harder than people think. And that is mostly because people do not have exposure to the work people are doing to improve things until something can become more "widely available".
deleted 1y ago
[deleted]
jrochkind1 1y ago
I'm not sure I'm following what inherent flaw you are suggesting browsers had that the public suffix list originators knew they had.
a456463 1y ago
I love the web. It's the corporate capitalistic ad fueled and govt censorship web that is the problem.
ApolloFortyNine 1y ago
All web encryption is backed by static list of root certs each browser maintains. Idk any other way to solve it for the general public (ideally each user would probably pick what root certs they trust), but it does seem crazy.
- account42 1y ago
  We already have a solution to solve it: DNS-based Authentication of Named Entities (DANE) This solution is even more obvious today where most certificates are just DNS lookups with extra steps.

samlinnfer 1y ago

Wait until you learn about the HSTS preload list.

lukan 1y ago

"The engineering equivalent of a car made of duct tape" Kind of. But do you have a better proposition?

gmueckl 1y ago
A part of the issue is IMO that browsers have become ridiculously bloated everything-programs. You could take about 90% of that out and into dedicated tools and end up with something vastly saner and safer and not a lot less capable for all practical purposes. Instead, we collectively are OK with frosting this atrocious layer cake that is today's web with multiple flavors of security measures of sometimes questionable utility. End of random rant.
- sefrost 1y ago
  You are right from a technical point, I think, but in reality - how would one begin to make that change?
- lukan 1y ago
  "You could take about 90% of that out and into dedicated tools " But then you would loose plattform independency, the main selling point of this atrocity. Having all those APIs in a sandbox that mostly just work on billion devices is pretty powerful and a potential succesor to HTML would have to beat that, to be adopted. The best thing to happen, that I can see, is that a sane subset crystalizes, that people start to use dominantly, with the rest becoming legacy, only maintained to have it still working. But I do dream of a fresh rewrite of the web since university (and the web was way slimmer back then), but I got a bit more pragmatic and I think I understood now the massive problem of solving trusted human communication better. It ain't easy in the real world.
  - gmueckl 1y ago
    But do we need e.g serial port or raw USB access straight from a random website? Even WebRTC is a bit of a stretch. There is a lot of cruft in modern browsers that does little except increase attack surface. This all just drives a need to come up with ever more tacked-on protection schemes because browsers have big targets painted on them.
    - shadowgovt 1y ago
      How else am I going to make a game in the browser that be controlled with a controller?
      - gmueckl 1y ago
        Every decent host OS already has a dedicated driver stack to provide game controller input to applications in a useful manner. Why the heck would you ship a reimplementation of that in JS in a website?
        shadowgovt 1y ago
        So that you can take input from countrollers that haven't been invented yet and won't fit the HID model.
- nemothekid 1y ago
  >A part of the issue is IMO that browsers have become ridiculously bloated everything-programs. I don't see how that solves the issue that PSL tries to fix. I was a script kiddy hosting neopets phishing pages on free cpanel servers from <random>.ripway.com back in 2007. Browsers were way less capable then.
  - lukan 1y ago
    PSL and the way cookies work is just part of the mess. A new approach could solve that in a different way, taking into account all the experience we had with scriptkiddies and professional scammers and pishers since then. But I also don't really have an idea where and how to start.
    - shadowgovt 1y ago
      And of course, if the new solution completely invalidates old sites, it just won't get picked up. People prefer slightly broken but accessible to better designed but inaccessible.
      - motorest 1y ago
        > People prefer slightly broken but accessible to better designed but inaccessible. It's not even broken as the edge cases are addressed by ad-hoc solutions. OP is complaining about global infrastructure not having a pristine design. At best it's a complain over a desirable trait. It's hardly a reason to pull the Jr developer card and mindlessly advocate for throwing everything out and starting over.
      - friendzis 1y ago
        > People prefer slightly broken but accessible to better designed but inaccessible. We live in world where whatever faang adopts is de facto a standard. Accessible these days means google/gmail/facebook/instagram/tiktok works. Everything else is usually forced to follow along. People will adopt whatever gives them access to their daily dose of doomscrolling and then complain about rather crucial part of their lives like online banking not working. > And of course, if the new solution completely invalidates old sites, it just won't get picked up. Old sites don't matter, only high-traffic sites riddled with dark patterns matter. That's the reality, even if it is harsh.
- Kim_Bruning 1y ago
  Are you saying we should make a <Unix Equivalent Of A Browser?> A large set of really simple tools that each do one thing really really really pedantically well? This might be what's needed to break out of the current local optimum.
  - gmueckl 1y ago
    I haven't thought of it that way, but that might be a solution.
    - magackame 1y ago
      There was an attempt in that direction. https://www.uzbl.org/ https://www.uzbl.org/
  - acka 1y ago
    Maybe it's time to revive something like the uzbl[1] project, or start something similar. [1] https://www.uzbl.org/ https://www.uzbl.org/
jadengeller 1y ago
I'd probably say we ought to use DNS.
- asplake 1y ago
  And while we’re at it, 1) mark domains as https-only, and 2) when root domains map to a subdomain (eg www).
  - account42 1y ago
    I might amuse you to know hat we also already have a text file as a solution for https-only sites.
Groxx 1y ago
I'm under the impression that CORS largely solves it? which is still much too new to be able to shut down the PSL of course. but maybe in 2050.
- Groxx 1y ago
  Since this is being downvoted: no, I'm quite serious. CORS lets sites define their own security boundaries between subdomains, with mutual validation. If you're hosting user content in a subdomain, just don't allow-origin it: that is a clear statement that it's not "the same site". PSL plays absolutely no part in that logic, it seems clear to me that it's at least in part intended to replace the PSL. Do other sites (like google's safety checks) use CORS for this purpose? Dunno. Seems like they could though? Or am I missing something?
0xbadcafebee 1y ago
Cookies shouldn't be tied to domains at all, it's a kludge. They should be tied to cryptographic keypairs (client + server). If the web server needs a cookie, it should request one (in its reply to the client's first request for a given url; the client can submit again to "reply" to this "request"). The client can decide whether it wants to hand over cookie data, and can withhold it from servers that use different or invalid keys. The client can also sign the response. This solves many different security concerns, privacy concerns, and also eliminates the dependency on specific domain names. I just came up with that in 2 minutes, so it might not be perfect, but you can see how with a little bit of work there's much better solutions than "I check for not-evil domain in list!"
- progval 1y ago
  > They should be tied to cryptographic keypairs (client + server). So now, if a website leaks its private key, attackers can exfiltrate cookies from all of its users just by making them open an attacker-controlled link, for as long as the cookie lives (and users don't visit the website to get the rotated key). > If the web server needs a cookie, it should request one This adds a round-trip, which slows down the website on slow connections. > the client can submit again to "reply" to this "request" This requires significantly overhauling HTTP and load-balancers. The public-suffix list exists because it's an easy workaround that didn't take a decade to specify and implement.
  - 0xbadcafebee 1y ago
    > So now, if a website leaks its private key, attackers can exfiltrate cookies from all of its users just by making them open an attacker-controlled link This attack already exists in several forms (leaking a TLS private key, DNS hijack, CA validation attack, etc). You could tack a DNS name onto the crypto-cookies if you wanted to, but DNS is trivial to attack. > This adds a round-trip, which slows down the website on slow connections. Requests are already slowed down by the gigantic amount of cookies constantly being pushed by default. The server can send a reply-header once which will tell the client which URLs need cookies perpetually, and the client can store that and choose whether it sends the cookies repeatedly or just when requested. This gives the client much more control over when it leaks users' data. > This requires significantly overhauling HTTP and load-balancers No change is needed. Web applications already do all of this all the time. (example: the Location: header is frequently sent by web apps in response to specific requests, to say nothing of REST and its many different request and return methods/statuses/headers). > The public-suffix list exists because it's an easy workaround So the engine of modern commerce is just a collection of easy hacks. Fantastic.

modeless 1y ago

Show me a platform not made out of duct tape and I'll show you a platform nobody uses.

vincnetas 1y ago
regular cars?
- MonaroVXR 1y ago
  The Honda issue where setting a certain radio station, would brick the infotainment? That good enough?
  - dgoldstein0 1y ago
    Never heard of this. Link please?
    - shakna 1y ago
      Don't know about Honda, but there is this Mazda one [0] (Would not be surprised if it affected multiple vendors!) [0] https://www.soundandvision.com/content/remembering-time-when-radio-station-bricked-your-car-s-radio https://www.soundandvision.com/content/remembering-time-when...
      - dgoldstein0 1y ago
        Yikes. I missed that. Makes sense it wasn't just the station it was tuned to but the particular data they broadcasted; insane there was no way to power reset the system into a good state.
    - deleted 1y ago
      [deleted]
  - alias_neo 1y ago
    > That good enough? Not really. Does the car still drive? That sounds like a software bug; hardly indicative that the entire car is held together with duct tape, but a pretty bad bug non the less.

starfallg 1y ago

That's the nature of decentralised control. It's not just DNS, phone numbers work in the same way.

lucideer 1y ago

> God I hate the web This is mostly a browser security mistake but also partly a product of ICANN policy & the design of the domain system, so it's not just the web. Also, the list isn't really that long, compared to, say, certificate transparency logs; now that's a truly mad solution.

KronisLV 1y ago

> Since there was and remains no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain A centralized list like this not just for domains as a whole (e.g. co.uk) but also specific sites (e.g. s3-object-lambda.eu-west-1.amazonaws.com) is both kind of crazy in that the list will bloat a lot over the years, as well as a security risk for any platform that needs this functionality but would prefer not to leak any details publicly. We already have the concept of a .well-known directory that you can use, when talking to a specific site. Similarly, we know how you can nest subdomains, like c.b.a.x, and it's more or less certain that you can't create a subdomain b without the involvement of a, so it should be possible to walk the chain. Example: c --> https://b.a.x/.well-known/public-suffix b --> https://a.x/.well-known/public-suffix a --> https://x/.well-known/public-suffix Maybe ship the domains with the browsers and such and leave generic sites like AWS or whatever to describe things themselves. Hell, maybe that could also have been a TXT record in DNS as well.

IshKebab 1y ago
I presume it has to be a curated list otherwise spammers would use it to evade blocks. Otherwise why not just use DNS?
- inopinatus 1y ago
  Whois would be the choice. DNS’s less glamourous sibling, purpose built for delegated publication of accountability records
  - IshKebab 1y ago
    Whois isn't curated either.
    - inopinatus 1y ago
      Neither is nominating a third party for your parking fine. The point is to get away from centralized gatekeepers, not establish more of them. A hierarchy of disavowal. It’s like cache invalidation for accountability. If you don’t wanna be held responsible for something, you’d better be prepared to point the finger at someone whois.

formerly_proven 1y ago

Why is it a centrally maintained list of domains, when there is a whole extensible system for attaching metadata to domain names?

jacquesm 1y ago

I think we lost the web somewhere between PageRank and JavaScript. Up to there it was just linked documents and it was mostly fine.

thomasjb 1y ago

What we need is a web made in a similar way to the wicker-bodied cars of yesteryear

vladms 1y ago

> God I hate the web. The engineering equivalent of a car made of duct tape. Most of the complex thing I have seen being made (or contributed to) needed duct tape sooner or later. Engineering is the art of trade-offs, of adapting to changing requirements (that can appear due to uncontrollable events external to the project), technology and costs. Related, this is how the first long distance automobile trip was done: https://en.wikipedia.org/wiki/Bertha_Benz#First_cross-country_automobile_journey,_1888 https://en.wikipedia.org/wiki/Bertha_Benz#First_cross-countr... . Seems to me it had quite some duct tape.

szszrk 1y ago
Why would you compare Web to that? A first fax message would be more appropriate comparison. Web is not a new thing and hardly a technical experiment of a few people any more. If you add the time since announcing the concept of Web to that trip date, you have a very decent established industry already. With many sport and mass production designs: https://en.wikipedia.org/wiki/Category:Cars_introduced_in_1924 https://en.wikipedia.org/wiki/Category:Cars_introduced_in_19...
- vladms 1y ago
  For me the web is something along the lines at the definition of: https://en.wikipedia.org/wiki/World_Wide_Web https://en.wikipedia.org/wiki/World_Wide_Web to sum up "...universal linked information system...". I think the fax misses many aspects of the core definition to be a good comparison. Not sure what is your point about "decent established industry" if we relate to "duct tape". I see two possibilities: a) you imply that the web does not have a decent established industry (but I would guess not). b) you would claim that there was no "duct tape" in 1924 car industry. I am no expert but I would refer you to the article describing what was the procedure to start the car at https://www.quora.com/How-do-people-start-their-cars-in-the-1930s-I-read-that-people-have-to-turn-something-in-front-of-the-car-is-that-true https://www.quora.com/How-do-people-start-their-cars-in-the-..., to quote: > Typical cold-start routine (common 1930s workflow) > 1. Set hand choke (pull knob). > 2. Set throttle lever to slight fast‑idle. > 3. Retard spark if manual advance present. > 4. Engage starter (electric) or use hand crank. > 5. Once running, push choke in gradually, advance spark, reduce throttle. Not sure about your opinion but compared to what a car's objective is (move from point A to point B) to me that sounds rather involved. Not sure if it qualifies as "duct-tape" but definitely it is not a "nicely implemented system that just works". To resume my point: I think on average progress is slower and harder than people think. And that is mostly because people do not have exposure to the work people are doing to improve things until something can become more "widely available".

deleted 1y ago

[deleted]

jrochkind1 1y ago

I'm not sure I'm following what inherent flaw you are suggesting browsers had that the public suffix list originators knew they had.

a456463 1y ago

I love the web. It's the corporate capitalistic ad fueled and govt censorship web that is the problem.

ApolloFortyNine 1y ago

All web encryption is backed by static list of root certs each browser maintains. Idk any other way to solve it for the general public (ideally each user would probably pick what root certs they trust), but it does seem crazy.

account42 1y ago
We already have a solution to solve it: DNS-based Authentication of Named Entities (DANE) This solution is even more obvious today where most certificates are just DNS lookups with extra steps.