6 ms·

Do you want to reinforce established monopolies? Because I can't think of a better way of doing that than having a technical difference between "trusted" and "u

Do you want to reinforce established monopolies? Because I can't think of a better way of doing that than having a technical difference between "trusted" and "untrusted" sites.

yoz-y 8y ago
What about differentiating applications and web sites? The line between the two is blurry, I know, but I would be happy if the document metaphor were divorced from the application one.
- dec0dedab0de 8y ago
  Absolutely, there should be a different port for web pages than applications. Even if we started by disabling js on port 80
  - krapp 8y ago
    But what about applications that link to web pages or web pages that link to applications? What valid reason is there to have an "application" and any documentation or related HTML material from the same site on different ports? Or, as some have pointed out elsewhere when this has come up, to have "applications" and "documents" use completely different protocols, languages and native clients, when both are often used together?
    - Retric 8y ago
      'Application' can be backward compatible with documents just fine. That does not mean a new category 'Document' that has reduced capability is useless. Banking websites for example don't need to be Applications and added protection for cross-site scripting etc. would be beneficial. Restrict things further and you default to supporting screen readers etc.
      - krapp 8y ago
        What definitions of "application" and "document" are being used here? Banking websites are applications in terms of their functionality - they're certainly not documents. At least not the parts where I can access and modify my account.
        Retric 8y ago
        Client side code including third party media players etc. IMO it's a simple question 'can you do the same thing with a sheet of printed paper.' I can fill out paper forms and hand them to someone just fine. Don't forget a Check is really just a piece of paper with a form on it.
        krapp 8y ago
        So a spreadsheet running in the client with javascript or WASM would be an application, but a spreadsheet running on the backend wouldn't? I'm not trying to be overly pedantic or combative here but making a distinction between client-side and server-side code seems arbitrary. I understand it in terms of managing privilege - you can't control what someone does on a remote server, and that code isn't running on your machine, but it seems like the meaningful distinction here isn't between documents and applications but between local and remote applications.
        Retric 8y ago
        The entire point is managing privileges. Just because I type in yourdomain.com does not mean I want you to be able to start playing death metal from my speakers. What about typing yourdomain.com means I want you to break my back button? Show a popup rather than close the browser? Churn CPU cycles crypto mining or do just about anything beyond hand me a document? Display a flashing GIF? The current model is basically handing complete control over my machine to a third party that may be compromised by anyone any time I click a random link. The single greatest web innovation in the last 30 years was readability mode.
  - skolemtotem 8y ago
    I agree, but it would be much easier if we had a new document-only port instead, since it wouldn't break most of the Internet.
  - workinthehead 8y ago
    That's a complete non-starter as long as advertising pays for the web pages. Or even longer, if the replacement compensation methods require JS as well.
    - yoz-y 8y ago
      Maybe there would be less money in it, but it is possible to do advertising completely on the backend as well. You send the advertiser some targeting info, e.g.: what does the article(s) on the page talk about, what is your site about, what is an estimated profile of your readers, and the ad network gives you the ad images and text in some nice format. Yes, it does require confidence that the publisher will actually show your ad, but it was the same thing for the journals. On the web you can still track outgoing links and have the referer, so you can know the actual impact of your ads anyways.
  - collinmanderson 8y ago
    how about 80 vs 443? :)
    - yoz-y 8y ago
      Well, one would like to have their document safe from snooping and modification too.
obl 8y ago
Well, I personally would be fine with the fair policy of disabling js everywhere but I'm sure most would not agree, so what's the alternative ? If anything, Spectre class attacks really showed how hard it is to properly sandbox arbitrary programs. Yes, the CPUs are complex, but the attacks happen on a high conceptual level, level at which the CPU is fairly simple. It's not like they rely on an obscure detail or bug. No one (publicly) figured those out for 2 decades when the involved ideas (speculation, cache timings) are well known, common and did not change. This indicates that for something with such a large surface as the various web standards, where both the spec and the implementations are changing all the time, there is very little hope.
- etatoby 8y ago
  I now use Brave browser exclusively, with JavaScript and other things turned off by default. Turning it on for trusted websites is one click away, once per domain, and it could save me in the future.
joshschreuder 8y ago
Aren't we sort of starting down that path already? IIRC Chrome only allows certain operations on HTTPS domains as of late such as webcam or microphone access. It seems like this sort of iterative securing of different things over time could be a good way to secure the web while also giving time for older sites to upgrade.
- cbr 8y ago
  Anyone can get an HTTPS cert, and with Let's Encrypt it's free. Restricting dangerous features to only websites that can demonstrate their traffic hasn't been man-in-the-middled is very different from giving established sites more expansive permissions. (Disclosure: I work at Google, though not on browsers)

Do you want to reinforce established monopolies? Because I can't think of a better way of doing that than having a technical difference between "trusted" and "untrusted" sites.

yoz-y 8y ago

What about differentiating applications and web sites? The line between the two is blurry, I know, but I would be happy if the document metaphor were divorced from the application one.

dec0dedab0de 8y ago
Absolutely, there should be a different port for web pages than applications. Even if we started by disabling js on port 80
- krapp 8y ago
  But what about applications that link to web pages or web pages that link to applications? What valid reason is there to have an "application" and any documentation or related HTML material from the same site on different ports? Or, as some have pointed out elsewhere when this has come up, to have "applications" and "documents" use completely different protocols, languages and native clients, when both are often used together?
  - Retric 8y ago
    'Application' can be backward compatible with documents just fine. That does not mean a new category 'Document' that has reduced capability is useless. Banking websites for example don't need to be Applications and added protection for cross-site scripting etc. would be beneficial. Restrict things further and you default to supporting screen readers etc.
    - krapp 8y ago
      What definitions of "application" and "document" are being used here? Banking websites are applications in terms of their functionality - they're certainly not documents. At least not the parts where I can access and modify my account.
      - Retric 8y ago
        Client side code including third party media players etc. IMO it's a simple question 'can you do the same thing with a sheet of printed paper.' I can fill out paper forms and hand them to someone just fine. Don't forget a Check is really just a piece of paper with a form on it.
        krapp 8y ago
        So a spreadsheet running in the client with javascript or WASM would be an application, but a spreadsheet running on the backend wouldn't? I'm not trying to be overly pedantic or combative here but making a distinction between client-side and server-side code seems arbitrary. I understand it in terms of managing privilege - you can't control what someone does on a remote server, and that code isn't running on your machine, but it seems like the meaningful distinction here isn't between documents and applications but between local and remote applications.
        Retric 8y ago
        The entire point is managing privileges. Just because I type in yourdomain.com does not mean I want you to be able to start playing death metal from my speakers. What about typing yourdomain.com means I want you to break my back button? Show a popup rather than close the browser? Churn CPU cycles crypto mining or do just about anything beyond hand me a document? Display a flashing GIF? The current model is basically handing complete control over my machine to a third party that may be compromised by anyone any time I click a random link. The single greatest web innovation in the last 30 years was readability mode.
- skolemtotem 8y ago
  I agree, but it would be much easier if we had a new document-only port instead, since it wouldn't break most of the Internet.
- workinthehead 8y ago
  That's a complete non-starter as long as advertising pays for the web pages. Or even longer, if the replacement compensation methods require JS as well.
  - yoz-y 8y ago
    Maybe there would be less money in it, but it is possible to do advertising completely on the backend as well. You send the advertiser some targeting info, e.g.: what does the article(s) on the page talk about, what is your site about, what is an estimated profile of your readers, and the ad network gives you the ad images and text in some nice format. Yes, it does require confidence that the publisher will actually show your ad, but it was the same thing for the journals. On the web you can still track outgoing links and have the referer, so you can know the actual impact of your ads anyways.
- collinmanderson 8y ago
  how about 80 vs 443? :)
  - yoz-y 8y ago
    Well, one would like to have their document safe from snooping and modification too.

obl 8y ago

Well, I personally would be fine with the fair policy of disabling js everywhere but I'm sure most would not agree, so what's the alternative ? If anything, Spectre class attacks really showed how hard it is to properly sandbox arbitrary programs. Yes, the CPUs are complex, but the attacks happen on a high conceptual level, level at which the CPU is fairly simple. It's not like they rely on an obscure detail or bug. No one (publicly) figured those out for 2 decades when the involved ideas (speculation, cache timings) are well known, common and did not change. This indicates that for something with such a large surface as the various web standards, where both the spec and the implementations are changing all the time, there is very little hope.

etatoby 8y ago
I now use Brave browser exclusively, with JavaScript and other things turned off by default. Turning it on for trusted websites is one click away, once per domain, and it could save me in the future.

joshschreuder 8y ago

Aren't we sort of starting down that path already? IIRC Chrome only allows certain operations on HTTPS domains as of late such as webcam or microphone access. It seems like this sort of iterative securing of different things over time could be a good way to secure the web while also giving time for older sites to upgrade.

cbr 8y ago
Anyone can get an HTTPS cert, and with Let's Encrypt it's free. Restricting dangerous features to only websites that can demonstrate their traffic hasn't been man-in-the-middled is very different from giving established sites more expansive permissions. (Disclosure: I work at Google, though not on browsers)