3 ms·

We already have all the of the technology we would need to build a document-only web now. The biggest unresolved problems are asset caching[0] and IP addresses[

We already have all the of the technology we would need to build a document-only web now. The biggest unresolved problems are asset caching[0] and IP addresses[1]. But for the most part, nobody would even have to build a new browser, they could just distribute a custom build of Firefox that turned off Javascript and a few other features. It would be very fast, reasonably private, probably a lot nicer to use (at least where documents are concerned), and nobody would use it. I don't necessarily disagree with your goal -- it seems very reasonable to want a document distribution platform that isn't encumbered with JS. But given that news sites can already speed up their pages dramatically by removing JS, and they don't, why would they support this new browser or platform? And without them supporting it, why would users move to it? We've seen this play out with AMP. AMP is fundamentally flawed, but it did get one thing right: that news sites only care about search engine placement, and they do not care about user experience past that point. I would (very cautiously) suggest that it might actually be easier to implement a VM that safely runs arbitrary code, than it would be to convince publishers to move to a user-friendly platform that only distributed documents. The only success I've seen in getting publishers to abandon scripting is via platforms like Facebook and Medium -- maybe that's replicable with a new browser or distribution layer on top of the web[2]? I dunno; I think that also might just be a really, really hard problem. I'd be happy to be proven wrong, I would happily start using a ubiquitous, script-free platform for document distribution. --- [0]: We maybe need to just bite the bullet and get rid of asset caching, or at least give asset caches a very short expiration date (<1 day). I guess making them domain-specific could help too. [1]: IP addresses are a huge issue, and I don't think the tech community talks about them enough. TOR is not really scaling. The best solution for ordinary consumers is a VPN, and VPNs have a lot of pretty obvious problems. [2]: My guess would be, someone would need to make publishing much easier than building a website (ie, Medium), maybe by adopting the DAT protocol and just offering free hosting for everyone. That runs into the same IP address problems (DAT and IPFS are not privacy friendly), but there's progress being made in that area. Or someone would need to find a way to get users to en-mass abandon the web and move to the new platform.

hollerith 7y ago
>it might actually be easier to implement a VM that safely runs arbitrary code, than it would be to convince publishers to move to a user-friendly platform that only distributed documents. Would the VM that safely runs arbitrary code render existing web pages or would it be necessary to persuade publishers to adopt it?
- danShumway 7y ago
  The current strategy being pursued by Apple and Mozilla is -- yes. They're hoping to make Javascript into that VM without breaking the majority of web pages. It is yet to be seen whether that's feasible. Apple and Mozilla are certainly making a lot of progress, but Javascript is very old, and was designed in an era where the attacks were much less sophisticated. The most promising progress (I think) is in building tracking protection that is undetectable. For example, you can put a permission prompt in front of someone's location and block off the API if the user clicked "no", but you could also just lie about their location, which means you'd still be compatible with most existing pages, and publishers wouldn't be able to strong-arm users into turning off the setting. This is how Firefox currently handles high-resolution timers. You can request them, they'll just lie to you sometimes. Again, it's yet to be seen whether that kind of stuff will work. The other hope is that WASM may be good enough on its own to encourage wide adoption -- being able to use (almost) any language to compile to the web is very, very attractive, so WASM might overcome Javascript's network effects (no pun intended) and replace it as the dominant language on the web. If that happens, WASM might be an opportunity to rethink web permissions. Might. If neither of those approaches work, then anything is fair game. At that point, we might as well try to make a document-only web, or migrate everyone to a new platform. I think that will be very difficult though.
- deleted 7y ago
  [deleted]
hollerith 7y ago
Thanks for your reply to my other question. I don't understand what problem(s) asset caching is currently causing. (Although I am a programmer, I'm not a web developer.) Is the asset caching done by the browser a major part of the problem you refer to? Is the caching done by content delivery networks a major part of the problem? Are there other major parts of the problem with asset caching?
- danShumway 7y ago
  Asset caching problems I worry about come from two sources: the browser itself, and 3rd-party content-delivery networks. On the browser side, by serving a unique set of resources to each user, I can identify them in future visits. Roughly speaking, the attack works by inserting a combination of unique asset URLs and repeated asset URLs, and then logging on the server which of those URLS the browser tries to fetch. By responding to fetch requests with 404s or bad assets, the server can avoid having your browser overwrite the unique combination of URLS it has cached, which allows for more persistent tracking. These caches also work across domains -- that means that if "foo" requests asset "googlepixel/my_id", and "bar" also requests asset "googlepixel/my_id", both will get served from the same cache. This means that caches can be used to track browsers across multiple websites. On the content-delivery side, the cached images are likely unique to the website you're visiting, and by downloading them, you're letting the 3rd-party know that your IP address visited the page that they're associated with. In a centralized web this is a small concern, to the extent that it allows Cloudflare/Google to know a lot more about what pages your IP is visiting. In a distributed web like IPFS this is a bigger problem, because now you're connecting to completely random people online to get your assets downloaded. Even worse, you're asking for those images/documents not by going to one specific server and saying, "hey, server X said you had asset Y", but by announcing to the entire network, "hey, I want asset Y, does anyone have it?"
deleted 7y ago
[deleted]

hollerith 7y ago

>it might actually be easier to implement a VM that safely runs arbitrary code, than it would be to convince publishers to move to a user-friendly platform that only distributed documents. Would the VM that safely runs arbitrary code render existing web pages or would it be necessary to persuade publishers to adopt it?

danShumway 7y ago
The current strategy being pursued by Apple and Mozilla is -- yes. They're hoping to make Javascript into that VM without breaking the majority of web pages. It is yet to be seen whether that's feasible. Apple and Mozilla are certainly making a lot of progress, but Javascript is very old, and was designed in an era where the attacks were much less sophisticated. The most promising progress (I think) is in building tracking protection that is undetectable. For example, you can put a permission prompt in front of someone's location and block off the API if the user clicked "no", but you could also just lie about their location, which means you'd still be compatible with most existing pages, and publishers wouldn't be able to strong-arm users into turning off the setting. This is how Firefox currently handles high-resolution timers. You can request them, they'll just lie to you sometimes. Again, it's yet to be seen whether that kind of stuff will work. The other hope is that WASM may be good enough on its own to encourage wide adoption -- being able to use (almost) any language to compile to the web is very, very attractive, so WASM might overcome Javascript's network effects (no pun intended) and replace it as the dominant language on the web. If that happens, WASM might be an opportunity to rethink web permissions. Might. If neither of those approaches work, then anything is fair game. At that point, we might as well try to make a document-only web, or migrate everyone to a new platform. I think that will be very difficult though.
deleted 7y ago
[deleted]

hollerith 7y ago

Thanks for your reply to my other question. I don't understand what problem(s) asset caching is currently causing. (Although I am a programmer, I'm not a web developer.) Is the asset caching done by the browser a major part of the problem you refer to? Is the caching done by content delivery networks a major part of the problem? Are there other major parts of the problem with asset caching?

danShumway 7y ago
Asset caching problems I worry about come from two sources: the browser itself, and 3rd-party content-delivery networks. On the browser side, by serving a unique set of resources to each user, I can identify them in future visits. Roughly speaking, the attack works by inserting a combination of unique asset URLs and repeated asset URLs, and then logging on the server which of those URLS the browser tries to fetch. By responding to fetch requests with 404s or bad assets, the server can avoid having your browser overwrite the unique combination of URLS it has cached, which allows for more persistent tracking. These caches also work across domains -- that means that if "foo" requests asset "googlepixel/my_id", and "bar" also requests asset "googlepixel/my_id", both will get served from the same cache. This means that caches can be used to track browsers across multiple websites. On the content-delivery side, the cached images are likely unique to the website you're visiting, and by downloading them, you're letting the 3rd-party know that your IP address visited the page that they're associated with. In a centralized web this is a small concern, to the extent that it allows Cloudflare/Google to know a lot more about what pages your IP is visiting. In a distributed web like IPFS this is a bigger problem, because now you're connecting to completely random people online to get your assets downloaded. Even worse, you're asking for those images/documents not by going to one specific server and saying, "hey, server X said you had asset Y", but by announcing to the entire network, "hey, I want asset Y, does anyone have it?"

deleted 7y ago

[deleted]