Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Most of those problems are specific to JavaScript. Just strip out JavaScript.


I never claimed the problems were hard to solve. (It's probably harder than you think, but there's off-the-shelf solutions for them now, as long as you've got a developer smart enough to reach for them, or one skilled and experienced enough to know how to build them in a pinch.)

But by the time you've solved them all, you're pretty much back to where Reddit, HN, Facebook, etc. are. I assume the author does not consider those "fun and weird".

I mean, I remember when Slashdot was having trouble with user abuse of

 tags. A simple 
 tag of all things! When you scale up, you have to close all the little holes, and what's left is not "fun and weird".

You can have fun and weird. It's out there, if you look, and worst case, you can always deploy your own site and do anything you want. But you can't have fun and weird at scale.


Then you strip out interactivity. Which is a pretty huge component of making the internet interesting and weird.

For its many sins, Flash was actually a pretty great sandbox for people to play with that way (as long as it didn't have one of its many security issues at the time)


Flash seems like a good example of how it's incredibly difficult to secure a system like that, even with a sandbox.

How many security updates did Flash have over the course of its life? Back in the heyday I remember it having to update multiple times a week.


> How many security updates did Flash have over the course of its life?

One. When they finally killed it.

All other updates were more or less security sidegrades.


There was a period when you could use Flash to invoke a javascript: protocol link and it would be executed in the containing page! They fixed it eventually but it was a great way to escape the Flash sandbox.


The other problem that bedeviled sites that allowed arbitrary HTML back in the day was crude phishing attempts: convert your user profile into a fake login page with CSS and HTML. Blocking this entirely is probably impossible. I suppose some machine learning could be used to detect pages styled as phishing attempts.

There were also all sorts of ways to sneak JavaScript back in. I remember embedding a javascript: protocol link inside a Flash applet would do it (flash eventually blocked that though).


Pretty sure if there's no JS you could just block iframes and maybe form tags and then people would have no way to submit anything. They could click a malicious link, sure, but they can do that on today's social networks.


Then you can replace the website "chrome"- the headers, the links back to the rest of the site- with doppelgangers that take you to a phishing page that makes it look like you've been logged out. All of those you'd expect to be internal links, so when they show you a "please log in again" screen you will have no reason for suspicion. You can't do that on Facebook today.

Alternatively, you don't need a form tag. Just show a login set of text inputs and an image that looks like a submit button. That button links you to a phishing site that says "oops! try again" and then you put your password in a second time and this time it's a real form. So you'd have to get rid of text inputs entirely.


If I understand you correctly those "you are leaving example.com" interstitial pages with a redirect are a solution to this problem. Although they are not so pleasant.


Is it technically possible to completely strip out javascript but still retain full html + css compatibility? I had the impression that somebody always finds a way to outsmart any filter using UTF arcanes or some other method.


     Content-Security-Policy: sandbox allow-same-origin allow-top-navigation allow-forms;
That gives you HTML + CSS - JS for the whole page.


Hmm. I can't say for absolute sure, but if the root document is HTML and there are no