8 ms·

If someone launches a new HTML-based Web with crippled javascript (no network comm access, for one, including ability to trigger links or forms), some small, re

by ashark 9y ago

If someone launches a new HTML-based Web with crippled javascript (no network comm access, for one, including ability to trigger links or forms), some small, restricted subset of CSS, and much better built-in dynamic table and form elements, I'm there. This Web's about to be eaten by DRM and WebAssembly anyway. Pretty soon it'll just be a way to deliver QT apps (or some other framework that runs in WebAssembly and renders to OpenGL or similar) and video. A web where the only thing you'll find when you follow a link is more documents (or a download) and pages can't try to make your computer do a bunch of stuff you don't want it to would be nice to have again, and it's clear now that the system itself has to ban the capabilities that enable all the garbage, or it'll take over.

EGreg 9y ago
Wait, what? Perhaps you are right, but how do you make the leap from "W3C standardizes DRM" and "the Web is about to be eaten by DRM?" The Web is used for so many things these days. It is a publishing platform that allows anyone to host their own content to the entire internet, thanks to Web Browsers just loading it. I can see IPFS being an improvement over the Web but besides the web server being a single point of failure, why is a DRM standard specifically going to destroy the Web? Wordpress is used to power 20% of new sites. My own company is developing an open source platform for communities to run their own social networks (https://qbix.com https://qbix.com) so what is this "eating" you speak of? EDIT: This has been one of my most downvoted comments ever. Can someone explain the rationale? (Is it super obvious that the Web will be killed by DRM that asking the question should be punished?)
- ashark 9y ago
  DRM and webassembly. The end of openness in both cases—though at least WebAssembly means we eventually won't have to write Javascript anymore, which is nice as far as that goes. Sure, Javascript uglifiers and frameworks mucking with HTML standards and the DOM had already made "view source" nigh-worthless, and there were DRM'd plugins of course, and browsers had supported some schemes for a while as a de facto standard, but this still feels like a last-straw kind of situation to me. > My own company is developing an open source platform for communities to run their own social networks (https://qbix.com https://qbix.com) so what is this "eating" you speak of? Sure, it's already the world's premiere delivery mechanism for "apps", advertisements, and mass surveillance software. I know. That's exactly the kind of thing that I don't mind living somewhere, but I'd like it not to be all mixed up in my networked hypertext document reader. This Web's over. Anyone hosting an After-Web? I could do with a little more Webbing. [EDIT] Though actually your thing seems fine. I saw "social network" and glossed over the rest. Sorry.
  - sp4ke 9y ago
    Bookmarking this page in hope of having some alternatives. I'm even ready to throw some money/programming hours to any serious projects
mabynogy 9y ago
> If someone launches a new HTML-based Web Few alternatives already exist (like gopher, the protocol). I found a new interesting one recently (ala markdown but tab-based and parseable with regexps): https://contnet.org/ https://contnet.org/ There is also a new browser that is being developped (not related to ContNet): https://netrunner.cc/ https://netrunner.cc/
anonacct37 9y ago
> If someone launches a new HTML-based Web with crippled javascript (no network comm access, for one, including ability to trigger links or forms), some small, restricted subset of CSS, and much better built-in dynamic table and form elements, I'm there. Me too. There will be dozens of us.
- mozumder 9y ago
  getting a little optimistic there...
  - glitcher 9y ago
    Dozens compared to the many millions who wouldn't make such a switch doesn't feel all that optimistic.
    - shallot_router 9y ago
      I believe they were being sarcastic.
- leggomylibro 9y ago
  I already use noscript, but most people won't like having to hit 'temporarily allow' and reloading the page 1-3 times before most sites will function. Also, sites that lean heavily on trendy frameworks like fucking React often just white-screen because of their extreme reliance on JS. I'm hugely against its adoption for that reason, but I understand that I'm in the minority there. I dunno, it just seems like common sense at this point. Javascript is a powerful attack vector, like ads. And many people already use adblockers in some capacity, for that kind of reason. It'll definitely suck as HTML5's various peripheral features become strong and widely-used attack vectors.
  - jdmichal 9y ago
    I mean, if a site legitimately needs a large amount of dynamic communication back to the server... Fine, whitewall me until I enable your JavaScript. I understand that server-side rendering is basically dead. But it's really frustrating when it's things that could be easily served statically, like blogs.
woodrowbarlow 9y ago
I think you're too quick to put DRM and WebAssembly in the same bucket. Yes, WebAssembly could lead to a future of closed-source proprietary technology on the web (and in that sense is similar to DRM), but the difference is that WebAssembly offers technical value. WebAssembly is a tradeoff for the public, whereas DRM exists strictly to restrict the public.
- baddox 9y ago
  I don't really see any new threat from WebAssembly. Isn't the only threat that the same malicious code can run with better performance than JavaScript? As far as I can tell, WebAssembly doesn't provide any additional access to native system features like this DRM spec does.
  - gsnedders 9y ago
    WASM is strictly less powerful than JS.
    - baddox 9y ago
      Indeed, from what I'm reading it looks like most of the usual JS tasks (like DOM manipulation, listening to input, and network requests) still need to happen by your WebAssembly module calling out to normal JS.
kerkeslager 9y ago
Ultimately, I think the failure of the open web runs deeper than that. When I visit, for example, a cookbook website, when I view a recipe, the problem isn't just that the site can run arbitrary scripts on my computer. It's also that I have no control over how that recipe displays because so much of that display is in HTML. I can't pull it into a useful format and store it with all my other recipes because it's in HTML. And contrary to its goals, HTML isn't a semantic markup language. I can't automatically convert imperial into metric units, because they aren't represented as measurements at all. I can't configure the display of the recipes for my nearsighted grandmother because that configuration happens when the recipe is rendered from a recipe document into an HTML document. The failure of the open web is that we need JavaScript to reasonably render the various kinds of documents which are being stripped of their metadata so they can be shoehorned into a non-semantic document format. Removing JavaScript prevents malware and adware vendors from running their programs on our machines, but it doesn't empower users. We can control or data but we still can't analyze data websites give us. The way forward, I think, is to create more standardized document types and let people build renderers for them. If I go to a cookbook website, I should be able to download recipe documents. If I don't like how my cookbook program renders the recipe, I should be able to download another program can render it. This breaks the power that websites have as the sole entities with the capability to render their documents, and gives the power back to users.
- jdmichal 9y ago
  I'll repost a comment by mcphage on why this doesn't work, in general. TL;DR is that common ontologies sound great but don't work in reality, because it leaves no room for value-added services from individual providers. (Recipes would probably be OK, because there's just not a lot of value-add you can really provide. Or, alternatively, I'm just completely ignorant about how value could be added.) https://news.ycombinator.com/item?id=13214134 https://news.ycombinator.com/item?id=13214134 """ I'm not sure this goal is very practical, even in the toy example you used (being able to swap data sources for weather forecasts). If you can use a common vocabulary to access multiple APIs, that requires that all APIs implement the same feature set. Which means getting the API sources to agree on the features to implement, and how to describe them, and stop them from adding any features on that the others don't have. But of course, they'll all be motivated to add their own features, to distinguish themselves from their competition. And once a API consumer is using a feature that other API producers don't support, then the consumer is locked into that producer, and the whole shared vocabulary is for naught. And of course the API consumers will be looking for additional features, because those translate into features that they can offer to their customers. Basically, this requires API producers to work together to hobble their ability to meet their customers' needs, all to make it easier for their customers to drop them for a competing endpoint. So it looks like a net negative for everybody. """
tannhaeuser 9y ago
Upvoted you, so count me in. Hard to believe in 2017, but as recently as five years ago Google (of all people) published the Caja compiler [1] for sandboxed/statically verified JavaScript subsets, and there was AdSafe aiming for safe JavaScript as well. [1]: https://developers.google.com/caja/ https://developers.google.com/caja/ [2]: http://www.adsafe.org http://www.adsafe.org
- qwepoiru 9y ago
  adsafe, and all static lint of ads, was dead from the beginning. If companies serve whatever comes from the ad networks, specially dynamic URLS, there is absolutely no way to enforce anything. You can check, but you can't enforce. the only sane solution on ads is SafeFrames [1]. Which does not do much, but at least it prevents ads from scrapping the page and stealing your cookies from the main domain you are visiting. That is already a win, considering the mess it is now without it. [1] https://www.iab.com/guidelines/safeframe/ https://www.iab.com/guidelines/safeframe/
- abecedarius 9y ago
  I don't know its current status with the committee, but https://github.com/tc39/proposal-frozen-realms https://github.com/tc39/proposal-frozen-realms proposes something equivalent to Caja for modern JS. It can be a lot simpler now because ES6+ is much closer to what's needed than JS was when Caja was made.
MikeGale 9y ago
I'm guessing the folk around here include some who can make a browser happen. If it takes only well formed x/html/5 it's not that big a deal. Ideally a lot of "hooks" so that the more determined can make it do their thing. Not the thing that somebody else wants to force on them. I wonder who's game?
Taek 9y ago
Count me in. And count my web server in as well, we'd make sure all pages are compatible. Your computer belongs to you. I'm ready to escape the cycle of 'oh they own everything because they snuck human rights violations into their software and hardware and nobody stopped them'.
yosito 9y ago
It's not a technical problem. It's a political problem. Those with the means will seek to control the web, no matter what technical solutions are invented to keep it open. Preventing tyrannical control of the web is an endless struggle.
sogen 9y ago
C-HTML maybe? [1] https://en.wikipedia.org/wiki/C-HTML https://en.wikipedia.org/wiki/C-HTML
cobookman 9y ago
So amp?
jlarocco 9y ago
I can't tell if you're being sarcastic or not, but I'll point out anyway that literally every single feature of the current internet is opt-in. Most of the time it's not even difficult to opt-out. If you really want a separate internet without the "bad parts", you can still use Gopher. There are still sites around, and you won't even get images, which were the first thing to "ruin" the internet, and were the launching point down the slippery slope to DRM video. On a side note, it's interesting that so many HN readers are against this kind of DRM, but at the same time there's a large group here who are against ad-blockers. Ad-revenue is the main driver motivating companies to shoe-horn this crap into the web. It's not a coincidence that the biggest ad company in the world also makes one of the most popular web browsers and is a huge media distributor.
- baddox 9y ago
  I'll point out that, unless you have data suggesting otherwise, for all we know those two groups of people on HN have no overlapping members.
Iv 9y ago
I am bitter that XML/XSLT lost in favor of HTML/CSS. It promised a stricter separation of content and formating and would probably have required less javascript to do the crucial functions. Unfortunately, among the crucial functions nowadays are the silly cosmetics, the parallax scrolling, the animated backgrounds, that allow marketers to pretend to have a website when all they have is formating for zero content. We failed to provide them with this fluff.
- pjmlp 9y ago
  Me too, we have to thank HTML 5 for it. Yet almost 10 years later, they are still playing catchup with native apps.
jstewartmobile 9y ago
I threw this out there a year or so ago in the hope of getting some feedback on it: https://eggplant.pro/blog/proposal-safeweb/ https://eggplant.pro/blog/proposal-safeweb/ Really, I just need to find the time to do it.
hrjet 9y ago
We don't need a new web; just more browsers that respect the user's privacy. There are many ways to achieve this. At gngr[0], we are taking a "safe by default" approach. This is very similar to the NoScript / uMatrix approach, but with one difference: the browser itself is offering this and is hence more water tight. There are no behind-the-scenes requests that a plugin can't block. [0]: https://gngr.info https://gngr.info
rasz 9y ago
There was a time browser worked for you. Opera up to 12.xx offered a panel letting you configure what JS can/cant do. It even let you configure global/per domain storage quotas and forbid websites from dumping megabytes of garbage on harddrive (Im talking to you ad network trackers/wikipedia). You can check out all of the sweet customization Opera 12.xx provided: http://help.opera.com/operaconfig/versions/Win32/11.50/en/index.html http://help.opera.com/operaconfig/versions/Win32/11.50/en/in...
GraulPaham 9y ago
> If someone launches a new HTML-based Web with crippled javascript (no network comm access, for one, including ability to trigger links or forms), some small, restricted subset of CSS, and much better built-in dynamic table and form elements, I'm there. Why not just do this yourself? Fork chromium and start commenting stuff you don't want out. It would likely only take a weekend or two of hacking...

by ashark 9y ago

EGreg 9y ago

Wait, what? Perhaps you are right, but how do you make the leap from "W3C standardizes DRM" and "the Web is about to be eaten by DRM?" The Web is used for so many things these days. It is a publishing platform that allows anyone to host their own content to the entire internet, thanks to Web Browsers just loading it. I can see IPFS being an improvement over the Web but besides the web server being a single point of failure, why is a DRM standard specifically going to destroy the Web? Wordpress is used to power 20% of new sites. My own company is developing an open source platform for communities to run their own social networks (https://qbix.com https://qbix.com) so what is this "eating" you speak of? EDIT: This has been one of my most downvoted comments ever. Can someone explain the rationale? (Is it super obvious that the Web will be killed by DRM that asking the question should be punished?)

ashark 9y ago
DRM and webassembly. The end of openness in both cases—though at least WebAssembly means we eventually won't have to write Javascript anymore, which is nice as far as that goes. Sure, Javascript uglifiers and frameworks mucking with HTML standards and the DOM had already made "view source" nigh-worthless, and there were DRM'd plugins of course, and browsers had supported some schemes for a while as a de facto standard, but this still feels like a last-straw kind of situation to me. > My own company is developing an open source platform for communities to run their own social networks (https://qbix.com https://qbix.com) so what is this "eating" you speak of? Sure, it's already the world's premiere delivery mechanism for "apps", advertisements, and mass surveillance software. I know. That's exactly the kind of thing that I don't mind living somewhere, but I'd like it not to be all mixed up in my networked hypertext document reader. This Web's over. Anyone hosting an After-Web? I could do with a little more Webbing. [EDIT] Though actually your thing seems fine. I saw "social network" and glossed over the rest. Sorry.
- sp4ke 9y ago
  Bookmarking this page in hope of having some alternatives. I'm even ready to throw some money/programming hours to any serious projects

mabynogy 9y ago

> If someone launches a new HTML-based Web Few alternatives already exist (like gopher, the protocol). I found a new interesting one recently (ala markdown but tab-based and parseable with regexps): https://contnet.org/ https://contnet.org/ There is also a new browser that is being developped (not related to ContNet): https://netrunner.cc/ https://netrunner.cc/

anonacct37 9y ago

> If someone launches a new HTML-based Web with crippled javascript (no network comm access, for one, including ability to trigger links or forms), some small, restricted subset of CSS, and much better built-in dynamic table and form elements, I'm there. Me too. There will be dozens of us.

mozumder 9y ago
getting a little optimistic there...
- glitcher 9y ago
  Dozens compared to the many millions who wouldn't make such a switch doesn't feel all that optimistic.
  - shallot_router 9y ago
    I believe they were being sarcastic.
leggomylibro 9y ago
I already use noscript, but most people won't like having to hit 'temporarily allow' and reloading the page 1-3 times before most sites will function. Also, sites that lean heavily on trendy frameworks like fucking React often just white-screen because of their extreme reliance on JS. I'm hugely against its adoption for that reason, but I understand that I'm in the minority there. I dunno, it just seems like common sense at this point. Javascript is a powerful attack vector, like ads. And many people already use adblockers in some capacity, for that kind of reason. It'll definitely suck as HTML5's various peripheral features become strong and widely-used attack vectors.
- jdmichal 9y ago
  I mean, if a site legitimately needs a large amount of dynamic communication back to the server... Fine, whitewall me until I enable your JavaScript. I understand that server-side rendering is basically dead. But it's really frustrating when it's things that could be easily served statically, like blogs.

woodrowbarlow 9y ago

I think you're too quick to put DRM and WebAssembly in the same bucket. Yes, WebAssembly could lead to a future of closed-source proprietary technology on the web (and in that sense is similar to DRM), but the difference is that WebAssembly offers technical value. WebAssembly is a tradeoff for the public, whereas DRM exists strictly to restrict the public.

baddox 9y ago
I don't really see any new threat from WebAssembly. Isn't the only threat that the same malicious code can run with better performance than JavaScript? As far as I can tell, WebAssembly doesn't provide any additional access to native system features like this DRM spec does.
- gsnedders 9y ago
  WASM is strictly less powerful than JS.
  - baddox 9y ago
    Indeed, from what I'm reading it looks like most of the usual JS tasks (like DOM manipulation, listening to input, and network requests) still need to happen by your WebAssembly module calling out to normal JS.

kerkeslager 9y ago

Ultimately, I think the failure of the open web runs deeper than that. When I visit, for example, a cookbook website, when I view a recipe, the problem isn't just that the site can run arbitrary scripts on my computer. It's also that I have no control over how that recipe displays because so much of that display is in HTML. I can't pull it into a useful format and store it with all my other recipes because it's in HTML. And contrary to its goals, HTML isn't a semantic markup language. I can't automatically convert imperial into metric units, because they aren't represented as measurements at all. I can't configure the display of the recipes for my nearsighted grandmother because that configuration happens when the recipe is rendered from a recipe document into an HTML document. The failure of the open web is that we need JavaScript to reasonably render the various kinds of documents which are being stripped of their metadata so they can be shoehorned into a non-semantic document format. Removing JavaScript prevents malware and adware vendors from running their programs on our machines, but it doesn't empower users. We can control or data but we still can't analyze data websites give us. The way forward, I think, is to create more standardized document types and let people build renderers for them. If I go to a cookbook website, I should be able to download recipe documents. If I don't like how my cookbook program renders the recipe, I should be able to download another program can render it. This breaks the power that websites have as the sole entities with the capability to render their documents, and gives the power back to users.

jdmichal 9y ago
I'll repost a comment by mcphage on why this doesn't work, in general. TL;DR is that common ontologies sound great but don't work in reality, because it leaves no room for value-added services from individual providers. (Recipes would probably be OK, because there's just not a lot of value-add you can really provide. Or, alternatively, I'm just completely ignorant about how value could be added.) https://news.ycombinator.com/item?id=13214134 https://news.ycombinator.com/item?id=13214134 """ I'm not sure this goal is very practical, even in the toy example you used (being able to swap data sources for weather forecasts). If you can use a common vocabulary to access multiple APIs, that requires that all APIs implement the same feature set. Which means getting the API sources to agree on the features to implement, and how to describe them, and stop them from adding any features on that the others don't have. But of course, they'll all be motivated to add their own features, to distinguish themselves from their competition. And once a API consumer is using a feature that other API producers don't support, then the consumer is locked into that producer, and the whole shared vocabulary is for naught. And of course the API consumers will be looking for additional features, because those translate into features that they can offer to their customers. Basically, this requires API producers to work together to hobble their ability to meet their customers' needs, all to make it easier for their customers to drop them for a competing endpoint. So it looks like a net negative for everybody. """

tannhaeuser 9y ago

Upvoted you, so count me in. Hard to believe in 2017, but as recently as five years ago Google (of all people) published the Caja compiler [1] for sandboxed/statically verified JavaScript subsets, and there was AdSafe aiming for safe JavaScript as well. [1]: https://developers.google.com/caja/ https://developers.google.com/caja/ [2]: http://www.adsafe.org http://www.adsafe.org

qwepoiru 9y ago
adsafe, and all static lint of ads, was dead from the beginning. If companies serve whatever comes from the ad networks, specially dynamic URLS, there is absolutely no way to enforce anything. You can check, but you can't enforce. the only sane solution on ads is SafeFrames [1]. Which does not do much, but at least it prevents ads from scrapping the page and stealing your cookies from the main domain you are visiting. That is already a win, considering the mess it is now without it. [1] https://www.iab.com/guidelines/safeframe/ https://www.iab.com/guidelines/safeframe/
abecedarius 9y ago
I don't know its current status with the committee, but https://github.com/tc39/proposal-frozen-realms https://github.com/tc39/proposal-frozen-realms proposes something equivalent to Caja for modern JS. It can be a lot simpler now because ES6+ is much closer to what's needed than JS was when Caja was made.

MikeGale 9y ago

I'm guessing the folk around here include some who can make a browser happen. If it takes only well formed x/html/5 it's not that big a deal. Ideally a lot of "hooks" so that the more determined can make it do their thing. Not the thing that somebody else wants to force on them. I wonder who's game?

Taek 9y ago

Count me in. And count my web server in as well, we'd make sure all pages are compatible. Your computer belongs to you. I'm ready to escape the cycle of 'oh they own everything because they snuck human rights violations into their software and hardware and nobody stopped them'.

yosito 9y ago

It's not a technical problem. It's a political problem. Those with the means will seek to control the web, no matter what technical solutions are invented to keep it open. Preventing tyrannical control of the web is an endless struggle.

sogen 9y ago

C-HTML maybe? [1] https://en.wikipedia.org/wiki/C-HTML https://en.wikipedia.org/wiki/C-HTML

cobookman 9y ago

So amp?

jlarocco 9y ago

I can't tell if you're being sarcastic or not, but I'll point out anyway that literally every single feature of the current internet is opt-in. Most of the time it's not even difficult to opt-out. If you really want a separate internet without the "bad parts", you can still use Gopher. There are still sites around, and you won't even get images, which were the first thing to "ruin" the internet, and were the launching point down the slippery slope to DRM video. On a side note, it's interesting that so many HN readers are against this kind of DRM, but at the same time there's a large group here who are against ad-blockers. Ad-revenue is the main driver motivating companies to shoe-horn this crap into the web. It's not a coincidence that the biggest ad company in the world also makes one of the most popular web browsers and is a huge media distributor.

baddox 9y ago
I'll point out that, unless you have data suggesting otherwise, for all we know those two groups of people on HN have no overlapping members.

Iv 9y ago

I am bitter that XML/XSLT lost in favor of HTML/CSS. It promised a stricter separation of content and formating and would probably have required less javascript to do the crucial functions. Unfortunately, among the crucial functions nowadays are the silly cosmetics, the parallax scrolling, the animated backgrounds, that allow marketers to pretend to have a website when all they have is formating for zero content. We failed to provide them with this fluff.

pjmlp 9y ago
Me too, we have to thank HTML 5 for it. Yet almost 10 years later, they are still playing catchup with native apps.

jstewartmobile 9y ago

I threw this out there a year or so ago in the hope of getting some feedback on it: https://eggplant.pro/blog/proposal-safeweb/ https://eggplant.pro/blog/proposal-safeweb/ Really, I just need to find the time to do it.

hrjet 9y ago

We don't need a new web; just more browsers that respect the user's privacy. There are many ways to achieve this. At gngr[0], we are taking a "safe by default" approach. This is very similar to the NoScript / uMatrix approach, but with one difference: the browser itself is offering this and is hence more water tight. There are no behind-the-scenes requests that a plugin can't block. [0]: https://gngr.info https://gngr.info

rasz 9y ago

There was a time browser worked for you. Opera up to 12.xx offered a panel letting you configure what JS can/cant do. It even let you configure global/per domain storage quotas and forbid websites from dumping megabytes of garbage on harddrive (Im talking to you ad network trackers/wikipedia). You can check out all of the sweet customization Opera 12.xx provided: http://help.opera.com/operaconfig/versions/Win32/11.50/en/index.html http://help.opera.com/operaconfig/versions/Win32/11.50/en/in...

GraulPaham 9y ago