7 ms·

Honestly I can't think of a much better system that can support a billion websites. What would you change/overhaul about the current system if you could ignore

Honestly I can't think of a much better system that can support a billion websites. What would you change/overhaul about the current system if you could ignore compatibility?

andy_ppp 7y ago
I still think it's a miracle that the browser was the solution to the client-server problem x-windows was trying to solve all along. How we ended up with billions of people able to interact with an app that we can all build at home seems insane...
- kick 7y ago
  I still think it's a miracle that the browser was the solution to the client-server problem x-windows was trying to solve all along. X was the solution to the problem MIT had, and as such, the problem X was trying to solve. It worked very, very well for what it was trying to solve. How we ended up with billions of people able to interact with an app that we can all build at home seems insane... Java. Java did this. On billions of devices! Everywhere from your smart card to the mainframe. Before Java, Dis! Before Dis, Forth! Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook.
  - owl57 7y ago
    Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook. Sufficiently young people probably suspect these were called netbooks as some joke. They run Emacs just fine and without constantly swapping, but a web browser?
    - hedora 7y ago
      They’re fine little web browsers if you manage to enable web browser acceleration for the integrated intel video card. If not, they can’t even run JavaScript ads, because apparently ads like to refresh the screen with a static image at 60fps. Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...) The web really sucks at everything other than network effects.
      - otabdeveloper4 7y ago
        > They’re fine little web browsers if you manage to enable web browser acceleration for the integrated intel video card. Hardware acceleration makes things slower, not faster. > Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...) You're nuts. Software rasterizers keep up with DOS games just fine, even on an old 386. It's the fact that they're trying to use Javascript and other garbage-collected or object-oriented languages to code these rasterizers.
- lazyier 7y ago
  If X-windows wasn't complete garbage at actually providing remote applications then it may have had a chance.
  - klodolph 7y ago
    Being complete garbage didn’t stop JavaScript either :/ At least JS had the excuse of being designed and implemented by a single developer in three weeks. X Windows was part of Project Athena, a $50 million project from MIT, DEC, and IBM with a five-year schedule.
    - kick 7y ago
      X worked great for what it was aiming to do. It's not even bad for really remote applications. It works really well, just don't use a dozen layers of poorly-designed abstraction. Write something with xcb or xlib, and you'll get instantaneous response from the other side of the planet. Here's a nice little article from 1989 telling just how great it was for the time: https://simson.net/clips/1989/1989.TechRev.Athena.pdf https://simson.net/clips/1989/1989.TechRev.Athena.pdf
      - klodolph 7y ago
        Eh, that’s a nice fluff piece but doesn’t match my understanding or experiences working with X. Once X had more widespread adoption in the 1990s you started to see a lot more hate. The layers of abstraction are there because X is such a godawful piece of shit. Sure, your application will be fast if you only use XCB or Xlib (and XCB is just a modern replacement for Xlib, made because of how deeply flawed Xlib is, and it can’t even fully replace Xlib). But few people are willing to put in the blood, sweat, and code to write something that is pure X. So if X worked great for what it was aiming to do, it was aiming to do the wrong thing.
        kick 7y ago
        X was hated when it got widespread adoption because people began using it for things it wasn't intended for. X was aiming to do the right thing. Sure, if you're using it to connect to a box in Canada over a satellite connection in Johannesburg during 1995 with countless abstractions, you're going to have a horrible time. Use the right tool for the job.
pwdisswordfish2 7y ago
If you honestly can’t think of one, that only demonstrates your lack of imagination. I, for one, would imagine something based on a DNS TXT records that either directly contain or point to a URL describing some kind of security domain policy: whether and which subdomains and subdirectories should be considered separate, isolated security domains, with pattern matching, of course. Or maybe put it under /.well-known/ instead of DNS. At the very least, this would solve the unregistration problem of PSL (i.e. when an entry becomes stale, you will not immediately know it, and old versions of your product will still treat it as present).
- wutwutwutwut 7y ago
  Using DNS TXT to solve a XSS issue? That's clearly another card added to the house.
- yoloClin 7y ago
  IMO, using DNS for anything other than hostname lookups is a complete hack. I'm looking at you, SPF.
  - pbhjpbhj 7y ago
    It's a reasonable hack though. Where else do you put "how to interact with this domain" data, you can't serve that data (eg via http) because clients need to already know how to interact with that domain before they interact with that domain? How would you do it?
    - yoloClin 7y ago
      Transport encryption with PKI.
yoloClin 7y ago
Firstly, I'd fix the damn spelling of the referer header instead of everybody putting up with it for close to 30 years. I don't think it's that JavaScript and HTML are a bad choice, but there are some things that would have made life a lot easier if they were strongly enforced sooner, including secure cookies by default, SameSite=lax, removal of referer header and CSP - doing them sooner would have stopped bad developer practices while also removing a fair chunk of application security complexities, but at least we're moving towards a better world regarding those now. I don't know if it'd be technically possible to implement, but additional characters to mark unsafe strings would have a huge impact on webapp security. Reflection of untrusted data at the moment generally relies on one of: HTML encoding, URL encoding or JavaScript escaping and escaping a safe way is highly context-dependent (I've seen an unescaped "\n" cause injection within JavaScript contexts). A way of effectively storing the level of trust a chunk of data has across multiple transports when marking untrusted data including within HTML/JS, SQL statements and interpreted languages like BASH or PHP - this would eliminate a bunch of vulnerabilities and would probably have mitigated a bunch of notable historic vulnerabilities and/or hacks.
- squiggleblaz 7y ago
  > HTML encoding, URL encoding or JavaScript escaping and escaping a safe way is highly context-dependent (I've seen an unescaped "\n" cause injection within JavaScript contexts) I have had a hard time convincing co-workers that if you have php generating sql generating (! yes!) html generating javascript, you need to escape the string for javascript since it's embedded in javascript. Then you need the string escaped for html since it's embedded in html. Then you need the string escaped for sql since it's embedded in sql. Only then can you chuck it into the middle of the string. It is better to not do such craziness; but once you've decided to do such craziness, you must do it properly. The similarities between js and mysql escaping are irrelevant; it must be escaped properly each time it is embedded in another language.
  - benibela 7y ago
    Escape characters are one of the most stupid things in the computing world. The formats could be so simple: first the length of the data, then raw data of that length
6510 7y ago
Make applications into a single file that can pull aditional xml and json data, images and video by appending the session key. If the application desires to do something other than display the data the user must give permission. No more checking if the json has a key but map it to a dom element and make that [and all its parents] unreadable. (Keep all the legacy crap for when this is not enough)
chx 7y ago
> What would you change/overhaul about the current system if you could ignore compatibility? Say, you have some endpoints which can do a public key crypto signature verification. Part of the cookie data is such an endpoint URL. If a script loaded into a page wants to read a cookie, the endpoint defined by the cookie checks the signature of the script and the browser accordingly allows or not access to the cookie. As you'd sign the scripts during deployment, the private key is not even on the public servers. For performance reasons probably wouldn't send the entire script just a hash of it so it's like GET https://example.com/check?hash=1234567890&signature=abcdef https://example.com/check?hash=1234567890&signature=abcdef and there's a simple 200 or 403 response. You could make the API such that you can bundle multiple hashes and signatures together so the entire overhead over the network is a single request for every endpoint. If you want to be fancy, you can have a response body for the 403 response which tells the browser something like "this hash is of an outdated version, plz ignore cache and load a new one".
- cryptonector 7y ago
  Yes, the server signing its scripts would do it, provided the server doesn't blindly sign attacker-submitted code. Some servers might...
- yoloClin 7y ago
  Secrets stored in cookies really shouldn't be accessible, the Set-Cookie HttpOnly flag should stop all JS access to a cookie. The HttpOnly flag still submits a cookie when you do an ajax GET/POST, but you cannot access the cookie via document.cookie or similar. There's also external resource integrity checks which prevent modification of third party resources without breaking the local site. jQuery CDN code snippets do this by default: https://code.jquery.com/ https://code.jquery.com/ . You can't trust one script to access a cookie without trusting all scripts to access the same cookie though - while I can see some merit to the idea when it comes to hiding secrets from XSS/untrusted code, I'd say that in most (99.9%) situations effort would be better spent actually implementing CSP and good data sanitation rather than caring about implementing JavaScript level trust models.
twic 7y ago
For the same-origin problem, the web server could return an Origin header which defines the origin. So the server on example.org could serve https://example.org/~username https://example.org/~username for anything in that account. The defined origin would have to be under the scheme, domain, and port served by the server, of course.
- dwb 7y ago
  This is not true; a URL with anything past the port is not a valid "origin" https://tools.ietf.org/html/rfc6454#section-7 https://tools.ietf.org/html/rfc6454#section-7
  - joosters 7y ago
    I think their point was that the concept could be expanded as per their suggestion, as a simple way to fix the security issues. Having the server send a 'this is my site base' header would be helpful even without having path support. At the moment, browsers need to magically know about all multi-level domains, like example.co.uk, so that they don't lump together all *.co.uk domains as the same site.
    - twic 7y ago
      Yes, this was my meaning - apologies if i wasn't clear.
- couchand 7y ago
  This is brilliant and simple and backwards-compatible. Well done. If I knew anything about the standards process I would write an RFC for it today.
hamilyon2 7y ago
If website is non-trivial, i. e. user have to login to it, I would encrypt all urls with client-specific key. So that it is non-sharable and unforgable
- ergothus 7y ago
  Isnt that contrary to the point of urls?
jlgaddis 7y ago
Pretty much all modern web servers support per-user virtual hosts using wildcards that allow for URLs like http://username.users.example.org/ http://username.users.example.org/ (instead of http://users.example.org/~username/ http://users.example.org/~username/ when using mod_userdir). Unless I'm missing something, it seems that this would eliminate most of the issues raised in the article by using a separate subdomain for each user/site. Using lighttpd, you can do this with this very simple configuration [0]: $HTTP["host"] =~ "users\.example\.org" { evhost.path-pattern = "/home/%4/public_html/" } Add a "wildcard" record for "*.users.example.org" pointing to the proper host to your DNS zone and you're all set. --- [0]: https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModEVhost#Samples https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Mod...

Honestly I can't think of a much better system that can support a billion websites. What would you change/overhaul about the current system if you could ignore compatibility?

andy_ppp 7y ago

I still think it's a miracle that the browser was the solution to the client-server problem x-windows was trying to solve all along. How we ended up with billions of people able to interact with an app that we can all build at home seems insane...

kick 7y ago
I still think it's a miracle that the browser was the solution to the client-server problem x-windows was trying to solve all along. X was the solution to the problem MIT had, and as such, the problem X was trying to solve. It worked very, very well for what it was trying to solve. How we ended up with billions of people able to interact with an app that we can all build at home seems insane... Java. Java did this. On billions of devices! Everywhere from your smart card to the mainframe. Before Java, Dis! Before Dis, Forth! Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook.
- owl57 7y ago
  Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook. Sufficiently young people probably suspect these were called netbooks as some joke. They run Emacs just fine and without constantly swapping, but a web browser?
  - hedora 7y ago
    They’re fine little web browsers if you manage to enable web browser acceleration for the integrated intel video card. If not, they can’t even run JavaScript ads, because apparently ads like to refresh the screen with a static image at 60fps. Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...) The web really sucks at everything other than network effects.
    - otabdeveloper4 7y ago
      > They’re fine little web browsers if you manage to enable web browser acceleration for the integrated intel video card. Hardware acceleration makes things slower, not faster. > Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...) You're nuts. Software rasterizers keep up with DOS games just fine, even on an old 386. It's the fact that they're trying to use Javascript and other garbage-collected or object-oriented languages to code these rasterizers.
lazyier 7y ago
If X-windows wasn't complete garbage at actually providing remote applications then it may have had a chance.
- klodolph 7y ago
  Being complete garbage didn’t stop JavaScript either :/ At least JS had the excuse of being designed and implemented by a single developer in three weeks. X Windows was part of Project Athena, a $50 million project from MIT, DEC, and IBM with a five-year schedule.
  - kick 7y ago
    X worked great for what it was aiming to do. It's not even bad for really remote applications. It works really well, just don't use a dozen layers of poorly-designed abstraction. Write something with xcb or xlib, and you'll get instantaneous response from the other side of the planet. Here's a nice little article from 1989 telling just how great it was for the time: https://simson.net/clips/1989/1989.TechRev.Athena.pdf https://simson.net/clips/1989/1989.TechRev.Athena.pdf
    - klodolph 7y ago
      Eh, that’s a nice fluff piece but doesn’t match my understanding or experiences working with X. Once X had more widespread adoption in the 1990s you started to see a lot more hate. The layers of abstraction are there because X is such a godawful piece of shit. Sure, your application will be fast if you only use XCB or Xlib (and XCB is just a modern replacement for Xlib, made because of how deeply flawed Xlib is, and it can’t even fully replace Xlib). But few people are willing to put in the blood, sweat, and code to write something that is pure X. So if X worked great for what it was aiming to do, it was aiming to do the wrong thing.
      - kick 7y ago
        X was hated when it got widespread adoption because people began using it for things it wasn't intended for. X was aiming to do the right thing. Sure, if you're using it to connect to a box in Canada over a satellite connection in Johannesburg during 1995 with countless abstractions, you're going to have a horrible time. Use the right tool for the job.

pwdisswordfish2 7y ago

If you honestly can’t think of one, that only demonstrates your lack of imagination. I, for one, would imagine something based on a DNS TXT records that either directly contain or point to a URL describing some kind of security domain policy: whether and which subdomains and subdirectories should be considered separate, isolated security domains, with pattern matching, of course. Or maybe put it under /.well-known/ instead of DNS. At the very least, this would solve the unregistration problem of PSL (i.e. when an entry becomes stale, you will not immediately know it, and old versions of your product will still treat it as present).

wutwutwutwut 7y ago
Using DNS TXT to solve a XSS issue? That's clearly another card added to the house.
yoloClin 7y ago
IMO, using DNS for anything other than hostname lookups is a complete hack. I'm looking at you, SPF.
- pbhjpbhj 7y ago
  It's a reasonable hack though. Where else do you put "how to interact with this domain" data, you can't serve that data (eg via http) because clients need to already know how to interact with that domain before they interact with that domain? How would you do it?
  - yoloClin 7y ago
    Transport encryption with PKI.

yoloClin 7y ago

Firstly, I'd fix the damn spelling of the referer header instead of everybody putting up with it for close to 30 years. I don't think it's that JavaScript and HTML are a bad choice, but there are some things that would have made life a lot easier if they were strongly enforced sooner, including secure cookies by default, SameSite=lax, removal of referer header and CSP - doing them sooner would have stopped bad developer practices while also removing a fair chunk of application security complexities, but at least we're moving towards a better world regarding those now. I don't know if it'd be technically possible to implement, but additional characters to mark unsafe strings would have a huge impact on webapp security. Reflection of untrusted data at the moment generally relies on one of: HTML encoding, URL encoding or JavaScript escaping and escaping a safe way is highly context-dependent (I've seen an unescaped "\n" cause injection within JavaScript contexts). A way of effectively storing the level of trust a chunk of data has across multiple transports when marking untrusted data including within HTML/JS, SQL statements and interpreted languages like BASH or PHP - this would eliminate a bunch of vulnerabilities and would probably have mitigated a bunch of notable historic vulnerabilities and/or hacks.

squiggleblaz 7y ago
> HTML encoding, URL encoding or JavaScript escaping and escaping a safe way is highly context-dependent (I've seen an unescaped "\n" cause injection within JavaScript contexts) I have had a hard time convincing co-workers that if you have php generating sql generating (! yes!) html generating javascript, you need to escape the string for javascript since it's embedded in javascript. Then you need the string escaped for html since it's embedded in html. Then you need the string escaped for sql since it's embedded in sql. Only then can you chuck it into the middle of the string. It is better to not do such craziness; but once you've decided to do such craziness, you must do it properly. The similarities between js and mysql escaping are irrelevant; it must be escaped properly each time it is embedded in another language.
- benibela 7y ago
  Escape characters are one of the most stupid things in the computing world. The formats could be so simple: first the length of the data, then raw data of that length

6510 7y ago

Make applications into a single file that can pull aditional xml and json data, images and video by appending the session key. If the application desires to do something other than display the data the user must give permission. No more checking if the json has a key but map it to a dom element and make that [and all its parents] unreadable. (Keep all the legacy crap for when this is not enough)

chx 7y ago

> What would you change/overhaul about the current system if you could ignore compatibility? Say, you have some endpoints which can do a public key crypto signature verification. Part of the cookie data is such an endpoint URL. If a script loaded into a page wants to read a cookie, the endpoint defined by the cookie checks the signature of the script and the browser accordingly allows or not access to the cookie. As you'd sign the scripts during deployment, the private key is not even on the public servers. For performance reasons probably wouldn't send the entire script just a hash of it so it's like GET https://example.com/check?hash=1234567890&signature=abcdef https://example.com/check?hash=1234567890&signature=abcdef and there's a simple 200 or 403 response. You could make the API such that you can bundle multiple hashes and signatures together so the entire overhead over the network is a single request for every endpoint. If you want to be fancy, you can have a response body for the 403 response which tells the browser something like "this hash is of an outdated version, plz ignore cache and load a new one".

cryptonector 7y ago
Yes, the server signing its scripts would do it, provided the server doesn't blindly sign attacker-submitted code. Some servers might...
yoloClin 7y ago
Secrets stored in cookies really shouldn't be accessible, the Set-Cookie HttpOnly flag should stop all JS access to a cookie. The HttpOnly flag still submits a cookie when you do an ajax GET/POST, but you cannot access the cookie via document.cookie or similar. There's also external resource integrity checks which prevent modification of third party resources without breaking the local site. jQuery CDN code snippets do this by default: https://code.jquery.com/ https://code.jquery.com/ . You can't trust one script to access a cookie without trusting all scripts to access the same cookie though - while I can see some merit to the idea when it comes to hiding secrets from XSS/untrusted code, I'd say that in most (99.9%) situations effort would be better spent actually implementing CSP and good data sanitation rather than caring about implementing JavaScript level trust models.

twic 7y ago

For the same-origin problem, the web server could return an Origin header which defines the origin. So the server on example.org could serve https://example.org/~username https://example.org/~username for anything in that account. The defined origin would have to be under the scheme, domain, and port served by the server, of course.

dwb 7y ago
This is not true; a URL with anything past the port is not a valid "origin" https://tools.ietf.org/html/rfc6454#section-7 https://tools.ietf.org/html/rfc6454#section-7
- joosters 7y ago
  I think their point was that the concept could be expanded as per their suggestion, as a simple way to fix the security issues. Having the server send a 'this is my site base' header would be helpful even without having path support. At the moment, browsers need to magically know about all multi-level domains, like example.co.uk, so that they don't lump together all *.co.uk domains as the same site.
  - twic 7y ago
    Yes, this was my meaning - apologies if i wasn't clear.
couchand 7y ago
This is brilliant and simple and backwards-compatible. Well done. If I knew anything about the standards process I would write an RFC for it today.

hamilyon2 7y ago

If website is non-trivial, i. e. user have to login to it, I would encrypt all urls with client-specific key. So that it is non-sharable and unforgable

ergothus 7y ago
Isnt that contrary to the point of urls?

jlgaddis 7y ago

Pretty much all modern web servers support per-user virtual hosts using wildcards that allow for URLs like http://username.users.example.org/ http://username.users.example.org/ (instead of http://users.example.org/~username/ http://users.example.org/~username/ when using mod_userdir). Unless I'm missing something, it seems that this would eliminate most of the issues raised in the article by using a separate subdomain for each user/site. Using lighttpd, you can do this with this very simple configuration [0]: $HTTP["host"] =~ "users\.example\.org" { evhost.path-pattern = "/home/%4/public_html/" } Add a "wildcard" record for "*.users.example.org" pointing to the proper host to your DNS zone and you're all set. --- [0]: https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModEVhost#Samples https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Mod...