In protest of the web{*} bulldozer, a response to websocket port scanning(medium.com)
medium.com
In protest of the web{*} bulldozer, a response to websocket port scanning
https://medium.com/@bjt2n3904/in-protest-of-the-web-bulldozer-e0fce4567d26
105 comments
I own a business and recently had to change all the pictures on my website from webp to png because safari both refuses to render webp and pretends to accept them. I hate it so much and see very real costs in increased bandwith (every image is around 3-4x bigger) but I have no choice because I want people with iphones to be able to buy things from me. Safari is honestly just as bad as chrome but for different reasons (ios safari was arguably the single biggest cause of the death of flash, for example). I also had to go through and fix a few other pseudo css classes that only safari didn't support which was really annoying, what a waste of time.
I don't think many people would consider "Don't use safari" banners a valid option unless the website was somehow really focused on non-apple users or not trying to sell something.
I don't think many people would consider "Don't use safari" banners a valid option unless the website was somehow really focused on non-apple users or not trying to sell something.
> ios safari was arguably the single biggest cause of the death of flash
I count that as a good thing about ios safari.
I count that as a good thing about ios safari.
[deleted]
I use Roll20, a popular web app for playing tabletop games with others over the internet. It doesn't work in Firefox or Safari; it's the only reason I keep Chromium on my machine.
I've used Roll20 a fair amount in Firefox and the only times I've had to pull out Chromium it turned out the the bug was present there too. Which things specifically don't work for you? (gf knows one of the devs, so I might try to poke at them to fix it)
And this from Slack: https://twitter.com/SlackHQ/status/958645632620748800?s=20
And Skype: https://news.ycombinator.com/item?id=20818750
For every example you can find me of a website that doesn't support safari I could find 10 that make exceptions to do so. The point isn't that nobody does it, it's just that most companies who want to make money from the general population (aka most of them) have to.
Roll20 is also such a niche thing already it's not really a fair example. People who want to use roll20 will use another browser because they want to play dnd with their friends. Most stores don't have that social aspect.
Roll20 is also such a niche thing already it's not really a fair example. People who want to use roll20 will use another browser because they want to play dnd with their friends. Most stores don't have that social aspect.
My point is that if YouTube stopped working on Firefox because they didn't agree to a new standard Google had invented, lots of people would stop using Firefox.
It takes someone who really cares about these issues to bother switching back and forth between two different browsers because you want to use a non-Chromium for most things but have to use Chromium for a couple of things. The vast majority would just say "well, whatever" and switch completely.
It takes someone who really cares about these issues to bother switching back and forth between two different browsers because you want to use a non-Chromium for most things but have to use Chromium for a couple of things. The vast majority would just say "well, whatever" and switch completely.
[deleted]
I stopped using Roll20 but switched to Zoom chat. Zoom chat has much better video chat support, also has a private chat function, and for our game, we could do without the "whiteboard" and the computerized dice rolling. It also would kill my network connection. It was a horrible experience.
I've been using Roll20 on Firefox for 4ish years. (I was a Kickstarter backer, but I'm not sure when I switched to Firefox from chromium).
> safari both refuses to render webp and pretends to accept them
weird, i haven't had that issue! i run a site that's set up¹ to redirect image requests to a WebP version if the Accept header allows it; half our team uses Macs w/ Safari and no one reported any issues with images.
---
¹ wordpress + webp-express: https://github.com/rosell-dk/webp-express i guess it's possible they special-case Safari, i'll check later
weird, i haven't had that issue! i run a site that's set up¹ to redirect image requests to a WebP version if the Accept header allows it; half our team uses Macs w/ Safari and no one reported any issues with images.
---
¹ wordpress + webp-express: https://github.com/rosell-dk/webp-express i guess it's possible they special-case Safari, i'll check later
It could've been my setup, to be honest I had just finished fixing all the pseudo classes and was kind of frustrated and decided to just switch to png after I couldn't figure it out in 5 minutes hahaha
But whatever the case is, Safari definately does not support webp and special exceptions need to be made to support this edge case.
But whatever the case is, Safari definately does not support webp and special exceptions need to be made to support this edge case.
> https://caniuse.com/#search=webp
Nope you are right, when reading the linked issues, safari doesn’t have webp support.
Nope you are right, when reading the linked issues, safari doesn’t have webp support.
Yeah, but that’s not the issue/question. Not supporting webp is fine, the important thing is that it doesn’t send an accept header that includes it. I don’t believe it does.
just had a friend with a Mac test it. when requesting foo.jpg (from an <img> tag), it sends:
i also tested it in Firefox, which sends:
honestly, i'm not entirely sure how
---
edit: looking at the generated .htaccess, it appears that WebP is served only if Accept contains an explicit `image/webp` (no wildcards), so that explains it.
Accept: image/png, image/svg+xml, image/*;q=0, video/*;q=0.8, */*;q=0.5
i also tested it in Firefox, which sends:
Accept: image/webp, */*
honestly, i'm not entirely sure how
image/*;q=0
*/*
---
edit: looking at the generated .htaccess, it appears that WebP is served only if Accept contains an explicit `image/webp` (no wildcards), so that explains it.
> I think for this we can blame Chromium's dominance. As the author said, many of these features were probably motivated by Chrome OS. And the devil's bargain of letting Chromium take such complete control over the web is that Google can strongarm whichever new "standards" they like into the Web.
The dark side to this is that the Chrome team can implement an API as an experiment, then when it's ready, propose it to the standards body and push it through before anybody else can catch up.
The dark side to this is that the Chrome team can implement an API as an experiment, then when it's ready, propose it to the standards body and push it through before anybody else can catch up.
I don't really see it as a dark side, but an important part of standardization. Why standardize an API no one wants? What's the best way to know someone wants it? What's the best way to work out the kinks in a proposal? A reference implementation.
I get what you're saying though. Google has the manpower to crank these out at a volume none of its competitors can, but I don't think that's a failure of the standards process.
I get what you're saying though. Google has the manpower to crank these out at a volume none of its competitors can, but I don't think that's a failure of the standards process.
I don't think it's about the manpower, but more about controlling a browser engine that powers an ever-increasing number of mainstream browsers.
Chrome's lumbering march to total dominance has been frightening to watch for many years now, and it only seems to be accelerating.
Chrome's lumbering march to total dominance has been frightening to watch for many years now, and it only seems to be accelerating.
The fact they accept PRs from outside changes your argument a little.
If you have a good idea for a new web standard, you can download the chromium source, add your new standard, build your cool webservice to work with it, and send the chromium OWNERS (many of whom don't work for Google) a PR.
Sure, there will be a bunch of rounds of review and questioning if your feature really is suitable for the whole web, but at the end of the day you'll probably get it in. Then you can add it to Firefox. You could theoretically add it to safari too, but they don't really like taking PR's these days...
If you have a good idea for a new web standard, you can download the chromium source, add your new standard, build your cool webservice to work with it, and send the chromium OWNERS (many of whom don't work for Google) a PR.
Sure, there will be a bunch of rounds of review and questioning if your feature really is suitable for the whole web, but at the end of the day you'll probably get it in. Then you can add it to Firefox. You could theoretically add it to safari too, but they don't really like taking PR's these days...
Yeah, that too
[deleted]
I don't think these features are bad, they are useful in some ways. Why we need USB on the browser? Think about updating the firmware of a device, you just go to the webpage, connect the device to the USB and update it, without having to download and install a tool to flash it, for an operation that you need to do just one time. This is only one example of many that we can make, another could be IDEs in the browser to program boards like Arduino, without installing software on the PC.
Battery status? It could be useful to know if the PC is connected to a power source and the level of the battery, even for a stupid scenario like watching a video, when I'm low on battery I usually reduce the resolution of a YouTube video because reproducing a 4k60p video uses a lot of resources, and drains the battery quickly. It would be useful if the webapp could just do that automatically, maybe on YouTube an option like reduce resolution when low on battery. Or for games, or whatever uses a lot of resources.
Think about it: the only reason because Electron apps exist (and we waste 200Mb of disk for each one of them) is only because browsers don't have APIs to access the filesystem! To me is a waste, the browser should give each application (let's stop calling them sites, they are no longer that) the APIs and permissions to access hardware, just like on mobile devices you have a dialog that says "this app would like to access the internal storage, consent or deny?".
Where is the problem? The user should give the privilege (only one time) and you finally can do basically 99% of work in the browser (and maybe the browser introduces also API to run the application in a window), you no longer need Electron just to do these kind of things, is still more secure than Electron because the code is sandboxed by the browser, and you don't have to worry about packaging your software for different operating systems.
Battery status? It could be useful to know if the PC is connected to a power source and the level of the battery, even for a stupid scenario like watching a video, when I'm low on battery I usually reduce the resolution of a YouTube video because reproducing a 4k60p video uses a lot of resources, and drains the battery quickly. It would be useful if the webapp could just do that automatically, maybe on YouTube an option like reduce resolution when low on battery. Or for games, or whatever uses a lot of resources.
Think about it: the only reason because Electron apps exist (and we waste 200Mb of disk for each one of them) is only because browsers don't have APIs to access the filesystem! To me is a waste, the browser should give each application (let's stop calling them sites, they are no longer that) the APIs and permissions to access hardware, just like on mobile devices you have a dialog that says "this app would like to access the internal storage, consent or deny?".
Where is the problem? The user should give the privilege (only one time) and you finally can do basically 99% of work in the browser (and maybe the browser introduces also API to run the application in a window), you no longer need Electron just to do these kind of things, is still more secure than Electron because the code is sandboxed by the browser, and you don't have to worry about packaging your software for different operating systems.
> Battery status? It could be useful to know if the PC is connected to a power source and the level of the battery, even for a stupid scenario like watching a video, when I'm low on battery I usually reduce the resolution of a YouTube video because reproducing a 4k60p video uses a lot of resources, and drains the battery quickly. It would be useful if the webapp could just do that automatically, maybe on YouTube an option like reduce resolution when low on battery. Or for games, or whatever uses a lot of resources.
I don't think it's a wrong API, but it certainly is a backward one. I don't want a website to collect low-level information from my computer's ACPI sensors, and then build its own policy on top. (Will I, the user, get any control over that policy? Probably not.) Instead, I want my OS to implement an energy policy (and a control panel for that policy) and then to maybe expose the information about the current energy policy to websites.
E.g., I'd be fine with iOS telling websites that I currently have Low Power mode enabled. If I don't have it enabled, then I don't care if the website thinks 10% is an emergency—I left it disabled for a reason. (And, contrariwise, if I turned on Low Power mode at 100% battery, then I'd like the website to cooperate.)
For a similar idea, I don't want websites to try figuring out that my IP translates to a cellular data connection. But I do want the state of my OS's "Metered Data mode" setting to be passed on to websites, so that they can help me to use less data, when I've decided I want to do so.
I don't think it's a wrong API, but it certainly is a backward one. I don't want a website to collect low-level information from my computer's ACPI sensors, and then build its own policy on top. (Will I, the user, get any control over that policy? Probably not.) Instead, I want my OS to implement an energy policy (and a control panel for that policy) and then to maybe expose the information about the current energy policy to websites.
E.g., I'd be fine with iOS telling websites that I currently have Low Power mode enabled. If I don't have it enabled, then I don't care if the website thinks 10% is an emergency—I left it disabled for a reason. (And, contrariwise, if I turned on Low Power mode at 100% battery, then I'd like the website to cooperate.)
For a similar idea, I don't want websites to try figuring out that my IP translates to a cellular data connection. But I do want the state of my OS's "Metered Data mode" setting to be passed on to websites, so that they can help me to use less data, when I've decided I want to do so.
> I don't think these features are bad, they are useful in some ways.
That’s the whole point: they look like APIs that might be useful for something but then they invariably become used for fingerprinting or an attack surface and we find out that nobody was actually using it at all, even though we came up with a couple of legitimate-sounding use cases for it.
> the code is sandboxed by the browser
What’s the point of a sandbox if you keep poking holes in it by adding new APIs?
That’s the whole point: they look like APIs that might be useful for something but then they invariably become used for fingerprinting or an attack surface and we find out that nobody was actually using it at all, even though we came up with a couple of legitimate-sounding use cases for it.
> the code is sandboxed by the browser
What’s the point of a sandbox if you keep poking holes in it by adding new APIs?
aka the road to hell is paved with good intentions
>Battery status? It could be useful to know if the PC is connected to a power source and the level of the battery [...]
But when was it ever implemented in the wild? This applies to most of these "features". There's a bunch of theoretical use cases, but there's pretty much 0 use for it in reality, and even if there's significant use, it's used more for fingerprinting.
But when was it ever implemented in the wild? This applies to most of these "features". There's a bunch of theoretical use cases, but there's pretty much 0 use for it in reality, and even if there's significant use, it's used more for fingerprinting.
IIRC, that feature might have been introduced by Mozilla for FirefoxOS? A lot of sensor APIs were.
The idea isn't bad, but it should probably be guarded behind some permissions...
The idea isn't bad, but it should probably be guarded behind some permissions...
> Why we need USB on the browser? Think about updating the firmware of a device, you just go to the webpage, connect the device to the USB and update it, without having to download and install a tool to flash it, for an operation that you need to do just one time. This is only one example of many that we can make, another could be IDEs in the browser to program boards like Arduino, without installing software on the PC.
This is a great idea! Now I not only have to be careful what drivers I install, I also have to be careful which websites I visit or they'll drive-by brick my development tools. Thanks!
It really should not be easy to update firmware on a device. It should be hard enough that it establishes obvious user intent. And I don't want to use a browser to do this. They're unstable enough without adding in soft real-time requirements. Firefox crashes on me about once per day. Doing it while I'm updating a $3000 JTAG adapter would be an absolute disaster.
This is a great idea! Now I not only have to be careful what drivers I install, I also have to be careful which websites I visit or they'll drive-by brick my development tools. Thanks!
It really should not be easy to update firmware on a device. It should be hard enough that it establishes obvious user intent. And I don't want to use a browser to do this. They're unstable enough without adding in soft real-time requirements. Firefox crashes on me about once per day. Doing it while I'm updating a $3000 JTAG adapter would be an absolute disaster.
Another use-case for USB is to access crypto tokens. There are USB devices which store private key and allow to perform crypto operations. It's much safer than storing private key in file system. Using those keys in website is a useful feature.
Ditto for smart cards. I've seen a lot of activex apps over the years do this.
> The standards committee doesn't want WebBatteryStatus? Fine, we'll implement it anyway and now Chrome desktop/mobile, Chromebooks, and Edge will all have it. Sites that want to use it will probably just use it and throw up a "Use Chrome" notification for Firefox and Safari.
The right answer is for Mozilla to implement the API, and leave it disabled by default. Disabled meaning it reports 90% full all the time, or some suitable probability distribution. If a specific API is actually useful for something, then the browser can notice if it being used and pop up its own permissions dialog to enable the API per-site.
The right answer is for Mozilla to implement the API, and leave it disabled by default. Disabled meaning it reports 90% full all the time, or some suitable probability distribution. If a specific API is actually useful for something, then the browser can notice if it being used and pop up its own permissions dialog to enable the API per-site.
That is starting to sound a lot like some sort of arms race.
Truth is, from the browser vendor perspective, it already is. Firefox used to be in an "arms race" of sorts when it was one of the most dominate browsers as well. Google just intensifies this reality as Microsoft with internet explorer rested on their laurels at a certain point which let Mozilla not have to push as fast/hard as they do now.
Yes, as is any ecosystem with competing parties. Surveillance companies want to exfiltrate as much information as possible, users want security. Every new facet added to the API is a site for this competition. Which is why every new web API needs to be reviewed by someone looking out for security of the users.
Reminds me of the EEE and Microsoft post recently on HN.
> The web already has a user-facing permissions system; it wouldn't be hard to add many of these under that umbrella (USB, Bluetooth, and Sensors stand out as obvious candidates that should've been behind that barrier from the beginning)
Let’s add Javascript to that list too.
Not all sites need it, and given the abuse it’s responsible for, it shouldn’t be permitted unless a user opts in.
Let’s add Javascript to that list too.
Not all sites need it, and given the abuse it’s responsible for, it shouldn’t be permitted unless a user opts in.
>Not all sites need it, and given the abuse it’s responsible for, it shouldn’t be permitted unless a user opts in.
And 99.999% of internet users will therefore be trained to blindly click "accept" on any permission popups a website shows them, since outside of HN pretty much everybody loves and appreciates the rich functionality javascript provides.
And 99.999% of internet users will therefore be trained to blindly click "accept" on any permission popups a website shows them, since outside of HN pretty much everybody loves and appreciates the rich functionality javascript provides.
> And 99.999% of internet users will therefore be trained to blindly click "accept" on any permission popups a website shows them
Or not, when they inevitably discover that leaving it turned off bypasses 90% of newspaper website paywalls whereas turning it on slows their browser down to a crawl and floods their screen with ads.
Or not, when they inevitably discover that leaving it turned off bypasses 90% of newspaper website paywalls whereas turning it on slows their browser down to a crawl and floods their screen with ads.
That was also the logic behind Windows Vista's UAC popup.
A great example!
That single move from Microsoft more or less eliminated the need for any normal application run by any normal user to require admin-rights to function, something which up to that point more or less had been the norm.
Developers fixed their applications to work with a sane privilege level and pretty much everyone was better off.
Let’s do the same with the rampant JS-abuse on the web.
That single move from Microsoft more or less eliminated the need for any normal application run by any normal user to require admin-rights to function, something which up to that point more or less had been the norm.
Developers fixed their applications to work with a sane privilege level and pretty much everyone was better off.
Let’s do the same with the rampant JS-abuse on the web.
> Unlike the rest of the technologies, [Websockets] seems to have somewhat of a purpose — even if it’s been made redundant by things like HTTP/2 streams.
...
Give it a few months, and there will be some NodeJS fad where everyone wants to re-implement HTTP with WebSockets, and load every asset for their website through JavaScript to save a tenth of a microsecond in some edge case involving tech buzzword bingo. ... Once this happens, disabling WebSockets breaks the internet.
To be fair to Websockets, they've been around for almost a decade, pre-dating http/2 by a few years, and the duplex communication they offer is a fundamental building block for all kinds of stuff, from games to trading websites to chat systems.
Although the Battery API is a different story, the author's point about Websockets seems to be based on somehow having overlooked them for quite a while.
To be fair to Websockets, they've been around for almost a decade, pre-dating http/2 by a few years, and the duplex communication they offer is a fundamental building block for all kinds of stuff, from games to trading websites to chat systems.
Although the Battery API is a different story, the author's point about Websockets seems to be based on somehow having overlooked them for quite a while.
Yes, and WebSockets are a clean and fast replacement for horrible hacks that preceded them. Nobody liked having to constantly poll the server one way or another, or god forbid, use Flash.
One alternative to repeated polling or Flash is hanging GETs. But yes, that's a pretty weird hack.
That's called 'long polling'. You can also leverage HTTP 1.1 chunked transfers. Cf https://en.wikipedia.org/wiki/Comet_(programming)
That's unidirectional. Websockets allow fully stateful bidirectional data transfer (just like a regular socket). They're wonderful when that's what you need.
Yeah, you pair hanging GETs with XHR to get bidirectional transfer. Yeah I agree websockets are a lot easier than the hacky hanging GETs + XHR setup.
I am starting to wonder whether we should split the web into "document mode" with only small subset of javascript APIs and "application mode". This could actually spark some innovation because the threshold to build a document-web-browser from scratch would be so much lower and it could have much better security.
I browse the web with js off by default, and turn it on per domain in 2 clicks. That's basically what you are proposing accessible today, with Firefox, on desktop and on Android
Aside: I turn off JS and never allow it on outside a VM (which gets wiped back to a clean state on shutdown).
It's definitely not the same thing because a lot of documents simply do not render (here's one I was looking at not 2 minutes ago, at least it has text, but no pics https://vanschneider.com/the-kawaiization-of-product-design A Number of sites will render absolutely nothing at all, text or otherwise eg https://www.washingtonpost.com).
Nope, he's got a good suggestion IMO.
It's definitely not the same thing because a lot of documents simply do not render (here's one I was looking at not 2 minutes ago, at least it has text, but no pics https://vanschneider.com/the-kawaiization-of-product-design A Number of sites will render absolutely nothing at all, text or otherwise eg https://www.washingtonpost.com).
Nope, he's got a good suggestion IMO.
Oh hell yes, I'm all for this. Though with the proviso of NO javasccript for document mode at all. I think this is a great idea.
Daniel Janus had written about it here: http://blog.danieljanus.pl/2019/10/07/web-of-documents/
I am fairly certain I have written about it as well, here or on my blog somewhere.
My ideas are a bit more pragmatic maybe: I hope Mozilla or someone else will make a html version of asm.js - an extremely performant renderer for a subset of html and css.
This could solve the bootstrapping dilemma since it would work in every other browser as well - only hopefully even faster in browsers that supports it - and make real headway in as little as a few years while working from day 1.
My suggestions:
- a meta field in the header indicating html document
- a free validation service
- if a document signals it is a modern document, send it down the fast path
- if the document doesn't follow the rules, restart with ordinary rules
- js is forbidden except for a number of vetted common libraries for things like autocomplete
I am fairly certain I have written about it as well, here or on my blog somewhere.
My ideas are a bit more pragmatic maybe: I hope Mozilla or someone else will make a html version of asm.js - an extremely performant renderer for a subset of html and css.
This could solve the bootstrapping dilemma since it would work in every other browser as well - only hopefully even faster in browsers that supports it - and make real headway in as little as a few years while working from day 1.
My suggestions:
- a meta field in the header indicating html document
- a free validation service
- if a document signals it is a modern document, send it down the fast path
- if the document doesn't follow the rules, restart with ordinary rules
- js is forbidden except for a number of vetted common libraries for things like autocomplete
> the threshold to build a document-web-browser from scratch would be so much lower
Wouldn't it be easier to just clone the normal Firefox/Chromium and strip everything out that is not needed? You wouldn't even have to do it all at once. Just turn things of and rip the code out/refactor later.
Wouldn't it be easier to just clone the normal Firefox/Chromium and strip everything out that is not needed? You wouldn't even have to do it all at once. Just turn things of and rip the code out/refactor later.
So much misinformation and FUD in this article. It's immediately suspect that the author had to lookup what websockets even WERE. No mention of the permissions system? This is a super low-quality article to make it to the front page.
Right, and he didn't try out all sockets to find out what is the blacklist. Did he notice that Firefox is open source and reading the source might give good hints? (On my phone now and not starting to do it myself. But I have run Firefox under gdb before to check how Google Streetview uses WebGL. It's not difficult under Linux at least, even if you like myself know absolutely nothing about the somewhat intimidating code base of Firefox.)
Yeah. Not to mention that WebSockets designers gave considerable thought to its security. Things like adding a mask to client messages look like puzzling inefficiencies, but are actually well designed security measures.
Good list of Web* technologies but he is wrong about them being all on-by-default security risks and wrong about them being useless gimmicks:
* WebSockets: On by default but obviously useful and not that different to normal HTTP requests. Can you port scan with XMLHttpRequest? I wouldn't be surprised.
* WebBluetooth: Has a permission dialog. This is actually really useful for things like the physical web - you can control nearby one-off devices without needing to install an app or for either device to have internet access. Great for interactive art installations for example.
* WebRTC: Enabled by default but very useful for web based games because it allows UDP-like communication. Also obviously useful for video conferencing.
* WebAssembly: This doesn't let you do anything that Javascript didn't so he's just being paranoid that it "enables binary executables to run in your browser".
* WebGL: This one he has a point on - GPU drivers are full of bugs and weren't designed to run untrusted software. I'm surprised there aren't more exploits of this.
* WebUSB: Again, useful for using USB devices without having to install an app. This also has a permission dialog.
Most of these are because the web is now an app platform, not just a document store.
* WebSockets: On by default but obviously useful and not that different to normal HTTP requests. Can you port scan with XMLHttpRequest? I wouldn't be surprised.
* WebBluetooth: Has a permission dialog. This is actually really useful for things like the physical web - you can control nearby one-off devices without needing to install an app or for either device to have internet access. Great for interactive art installations for example.
* WebRTC: Enabled by default but very useful for web based games because it allows UDP-like communication. Also obviously useful for video conferencing.
* WebAssembly: This doesn't let you do anything that Javascript didn't so he's just being paranoid that it "enables binary executables to run in your browser".
* WebGL: This one he has a point on - GPU drivers are full of bugs and weren't designed to run untrusted software. I'm surprised there aren't more exploits of this.
* WebUSB: Again, useful for using USB devices without having to install an app. This also has a permission dialog.
Most of these are because the web is now an app platform, not just a document store.
I fully agree.
When I open a newspaper website, I want to receive a tiny bit of HTML and CSS and maybe references to some images. Like 50KB+images.
Instead, I am bombarded with megabytes of JavaScript and these new APIs so that advertisers can better spy on me. All of that comes at the expense of my bandwidth, my CPU usage and battery power, and my privacy.
Soon, we'll need a service that remotely opens those websites for you, then dumps the DOM and only forwards that to you. So basically server-side rendering for other people's delinquent websites.
When I open a newspaper website, I want to receive a tiny bit of HTML and CSS and maybe references to some images. Like 50KB+images.
Instead, I am bombarded with megabytes of JavaScript and these new APIs so that advertisers can better spy on me. All of that comes at the expense of my bandwidth, my CPU usage and battery power, and my privacy.
Soon, we'll need a service that remotely opens those websites for you, then dumps the DOM and only forwards that to you. So basically server-side rendering for other people's delinquent websites.
Actually Microsofts work on https://docs.microsoft.com/en-us/openspecs/windows_protocols...
> Firstly, WebSockets seem to be prohibited from accessing 192.168.0.0/16 and 10.0.0.0/8. In Firefox, it raises SecurityError.
And 172.16.0.0/12 I hope. I did a little Googling and didn't quickly find a list of sources they are blocking in Firefox (or is it part of the standard?), but I hope that one is included. It's not as common, but it's still a private network and used sometimes.
And 172.16.0.0/12 I hope. I did a little Googling and didn't quickly find a list of sources they are blocking in Firefox (or is it part of the standard?), but I hope that one is included. It's not as common, but it's still a private network and used sometimes.
> And 172.16.0.0/12 I hope
Yes, at least on my Firefox (76.0.1 on Ubuntu).
However, Chrome will happily open a websocket to addresses in the 192.168., 10., and 172.16. ranges. It fails for 127.0.0.1, but only because it says there's nobody listening (not, as Firefox does, because of a security error accessing that IP in the first place); for localhost it can actually verify that no service is running on that port, whereas for remote hosts in the private ranges it can't.
Yes, at least on my Firefox (76.0.1 on Ubuntu).
However, Chrome will happily open a websocket to addresses in the 192.168., 10., and 172.16. ranges. It fails for 127.0.0.1, but only because it says there's nobody listening (not, as Firefox does, because of a security error accessing that IP in the first place); for localhost it can actually verify that no service is running on that port, whereas for remote hosts in the private ranges it can't.
I don't understand the point of blocking all of 192.168/16, 172.16/12, and 10/8. If the point is to block access to other hosts on your LAN shouldn't it just block the one your LAN actually uses?
I don't understand the point of not blocking all of those ranges. Why should the browser bother trying to figure out which ones are actually used on a particular LAN? All of those IP ranges are designated as private, and that in itself should be reason enough for browsers to block websocket connections to them.
I use both 192.168/16 and 10/8 on my computer. One is for my regular LAN and the other is for my 10G link to my NAS.
What if the my network uses several different local subnets? How would the browser figure that out?
No, blocking all these IP ranges is a good idea. After all, these ranges are supposed to not be directly routeable to from the Internet.
No, blocking all these IP ranges is a good idea. After all, these ranges are supposed to not be directly routeable to from the Internet.
> What if the my network uses several different local subnets? How would the browser figure that out?
It would look at your computer's routing table. If it is an IP address your computer talks to directly, it is on a LAN your computer is on and would be blocked. If it is an IP address that your computer talks to through a gateway, it is on the internet and would not be blocked.
> After all, these ranges are supposed to not be directly routeable to from the Internet.
They are supposed to not be directly routeable to/from the public internet. They can be directly routable between non-public parts of the internet.
A not uncommon example, especially now, is having a VPN connection between a home network and the internal network of a business, both of which are using addresses in the private ranges.
It would look at your computer's routing table. If it is an IP address your computer talks to directly, it is on a LAN your computer is on and would be blocked. If it is an IP address that your computer talks to through a gateway, it is on the internet and would not be blocked.
> After all, these ranges are supposed to not be directly routeable to from the Internet.
They are supposed to not be directly routeable to/from the public internet. They can be directly routable between non-public parts of the internet.
A not uncommon example, especially now, is having a VPN connection between a home network and the internal network of a business, both of which are using addresses in the private ranges.
> They are supposed to not be directly routeable to/from the public internet. They can be directly routable between non-public parts of the internet.
Sure, but this is different from a VPN. This would be untrusted code downloaded from a remote website talking to unrelated devices on my local network. Effectively, it would be the remote website having free reign inside my local network, with my web browser acting as a proxy (or as a trojan horse, with a bit of exaggeration).
Sure, but this is different from a VPN. This would be untrusted code downloaded from a remote website talking to unrelated devices on my local network. Effectively, it would be the remote website having free reign inside my local network, with my web browser acting as a proxy (or as a trojan horse, with a bit of exaggeration).
> If it is an IP address that your computer talks to through a gateway, it is on the internet and would not be blocked.
No, this would just make the security problem worse, because now any website could use websockets to scan, not just your personal LAN, but any network you are connected to through a VPN or any other gateway.
No, this would just make the security problem worse, because now any website could use websockets to scan, not just your personal LAN, but any network you are connected to through a VPN or any other gateway.
Gee, good job no one uses IPv6.
Consider a /64 subnet will take a while, if not forever, to scan.
Unless you know part of the mac address. Or it's bound to :0:0:0:1. And maybe you already know the IP and the firewall is blocking connections from outside the building.
Shhh the kids are thinking. They'll work it out eventually.
My IPX/SPX and pigeon borne packet transfers are all good.
I'm using a dual IPv4/6 stack laptop at home with a dual stack IPv4/6 OpenVPN to the office at the moment, with my default gateways forced down the VPN. Silly me, click (disconnect) Oh, no real change in experience.
My IPX/SPX and pigeon borne packet transfers are all good.
I'm using a dual IPv4/6 stack laptop at home with a dual stack IPv4/6 OpenVPN to the office at the moment, with my default gateways forced down the VPN. Silly me, click (disconnect) Oh, no real change in experience.
I remember being a little surprised websockets could violate the same origin policy. It was only a matter of time before that was going to be abused.
It’s a shame because it meant you could run your own server for eg js/html games.
It’s a shame because it meant you could run your own server for eg js/html games.
> I remember being a little surprised websockets could violate the same origin policy. It was only a matter of time before that was going to be abused.
WebSockets don't have the Same Origin Policy like XMLHttpRequest does, yes, but they are required to tell the server they connect to what origin they came from, so the server can enforce whatever restrictions it likes.
WebSockets were also designed with preventing abuse in mind: note the protocol obfuscation and weird headers, which I think are there so you can't confuse non-WebSocket-aware servers and non-HTTP protocols.
However, as with XMLHttpRequest and other ways to do an HTTP request, it's not possible for the browser to know if a destination server speaks HTTP without trying to connect to it, and I guess that's why port scanning is possible.
WebSockets don't have the Same Origin Policy like XMLHttpRequest does, yes, but they are required to tell the server they connect to what origin they came from, so the server can enforce whatever restrictions it likes.
WebSockets were also designed with preventing abuse in mind: note the protocol obfuscation and weird headers, which I think are there so you can't confuse non-WebSocket-aware servers and non-HTTP protocols.
However, as with XMLHttpRequest and other ways to do an HTTP request, it's not possible for the browser to know if a destination server speaks HTTP without trying to connect to it, and I guess that's why port scanning is possible.
[deleted]
All the new web standards are a bit tiresome, to be honest, and some of them have the flimsiest justification. I remember someone pushing the Ambient Light Sensor API on Twitter at some point and the example they gave was "you can offer dark mode to your users if the brightness you detect is low". Like, really? There are actual browser APIs for this, and they offer a better signal of user intent than brightness levels could ever do. Can you please just think these through?
Extrapolating the reasons behind a particular standard being created from a random Tweet is a bit disingenuous. Here are the examples that the standard proposal cites:
https://w3c.github.io/ambient-light/#usecases-requirements
The camera one especially seems convincing to me.
https://w3c.github.io/ambient-light/#usecases-requirements
The camera one especially seems convincing to me.
None of the examples they've listed sound convincing.
>A Web application provides input for a smart home system to control lighting.
Why would you need ambient light level to control lighting? Do you need a phone to calibrate the room's brightness or something?
>A Web aplication checks whether light level at work space is sufficient.
Can't think of a reason why an app would need to do this
>A Web application calculates settings for a camera with manual controls (apperture, shutter speed, ISO).
Seems contrived to me. It might make sense for an analog camera, but every digital camera has a lightmeter, which is what you'd want anyways rather than the light sensor on your phone with unknown accuracy and viewing angle.
>A Web application monitors light level changes produced by hovering hand user gesture and interprets them to control a game character.
Wouldn't that be better served by using the front facing camera? You can even implement different hand gestures that way.
>A Web application provides input for a smart home system to control lighting.
Why would you need ambient light level to control lighting? Do you need a phone to calibrate the room's brightness or something?
>A Web aplication checks whether light level at work space is sufficient.
Can't think of a reason why an app would need to do this
>A Web application calculates settings for a camera with manual controls (apperture, shutter speed, ISO).
Seems contrived to me. It might make sense for an analog camera, but every digital camera has a lightmeter, which is what you'd want anyways rather than the light sensor on your phone with unknown accuracy and viewing angle.
>A Web application monitors light level changes produced by hovering hand user gesture and interprets them to control a game character.
Wouldn't that be better served by using the front facing camera? You can even implement different hand gestures that way.
They left some out:
- Monitor room light level for fluctuations that correspond to advertising broadcasts for advertising proximity fingerprinting, or location fingerprinting, ie: the illuminance profile for a video broadcast is moderately unique, and can identify the fact that it's playing on a screen near the user
- Side channel for data exfiltration attacks (we require permission to use the microphone for more reasons than just listening for people talking)
- Monitoring for in/out of pocket/purse state for the phone
- Probably a ton of other nefarious stuff that I am not devious enough to think of.
- Monitor room light level for fluctuations that correspond to advertising broadcasts for advertising proximity fingerprinting, or location fingerprinting, ie: the illuminance profile for a video broadcast is moderately unique, and can identify the fact that it's playing on a screen near the user
- Side channel for data exfiltration attacks (we require permission to use the microphone for more reasons than just listening for people talking)
- Monitoring for in/out of pocket/purse state for the phone
- Probably a ton of other nefarious stuff that I am not devious enough to think of.
The problem is that these APIs have been developed with little concern paid to security. Compounding this, Mozilla hasn't even tweaked the implementation details to retain what security they could. This is seemingly due to a mistaken idea that sandbox escape is the only security property that matters, allowing these APIs to leak identifying information like sieves.
For example, AFAICT the common wisdom for mitigating Location with user.js is to set it to Ask for every site instead of a blanket Deny, because the latter actually turns out to be more fingerprintable. Whereas Deny should be indistinguishable from Ask with a negative response.
For example, AFAICT the common wisdom for mitigating Location with user.js is to set it to Ask for every site instead of a blanket Deny, because the latter actually turns out to be more fingerprintable. Whereas Deny should be indistinguishable from Ask with a negative response.
I’m a bit surprised that anyone with a remotely techie background has been unaware of websockets until now.
> Each brings the browser closer and closer to my desktop, and seems solely driven by ChromeBook developers.
Yes. So let’s reject them all.
Let sane desktop browsers tell the web that these APIs don’t exist in a meaningful way, and that building applications that rely on them is a waste of time.
Mozilla, Microsoft and Apple? Pretty please?
Yes. So let’s reject them all.
Let sane desktop browsers tell the web that these APIs don’t exist in a meaningful way, and that building applications that rely on them is a waste of time.
Mozilla, Microsoft and Apple? Pretty please?
> Web{Assembly}: Enables binary executables to run in your browser
“Binary executables” makes it sound like it's machine code, but WebAssembly is more like a bytecode for JavaScript.
“Binary executables” makes it sound like it's machine code, but WebAssembly is more like a bytecode for JavaScript.
I'm of two minds about it. On the one hand, JS should've been compiled in the first place; that we spent some two decades making computers parse increasingly complex scripts repeatedly is a sad waste, and it spawned what's probably the biggest hack ever to become a standard practice: minifying code. On the other hand, WebASM webapps will be an order of magnitude less inspectable.
Why will WebAssembly applications be less inspectable? JS applications are already aggressively minified multi-megabyte blobs.
I can take a look at a minified piece of JS after reformatting, and quickly guess what many of the functions do just by their shape. I won't be able to do that anywhere as easily with a piece of decompiled bytecode, especially if it went through an optimization pass.
The re-prettification of the minified code doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does.
The decompiled WASM doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does.
Not really seeing the difference.
Minified/"uglified" JS—and especially obfuscated JS (where "minification" and "obfuscation" are frequently aligned interests, so most libraries incidentally do both)—is already "a bytecode for the browser virtual machine", just a highly-redundant encoding of one.
The decompiled WASM doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does.
Not really seeing the difference.
Minified/"uglified" JS—and especially obfuscated JS (where "minification" and "obfuscation" are frequently aligned interests, so most libraries incidentally do both)—is already "a bytecode for the browser virtual machine", just a highly-redundant encoding of one.
On the other hand, V8 is the most widely run, heavily invested and thus optimized JIT compiler in history. So I think most of the interpreted vs compiled mistakes have been Google’d out at this point.
In my opinion, the "sad waste" has nothing to do with CPU clock cycles and everything to do with the uncountable hours humans have spent trying to make javascript tolerable. If we had bytecode from the start, it would have enabled a huge reduction in human labor.
Flash implemented using bytecode.
It helps with execution speed, but not with the speed of parsing the plaintext code and interpreting (or compiling) it.
One website can use resources from other website using img, script, link tags. That was since WWW invented. User agent will retrieve related resources from other websites.
Those port scanners abuse that feature. <img href="https://website-resolving-to-127-0-0-1.com:1234"> is a legitimate code and browser is expect to establish TLS connection to 127.0.0.1:1234.
Trying to patch that fundamental behaviour is hard.
Websockets are not enemy here. They are just convenient tool. It could be implemented without websockets.
Imagine that google.com added <img src=yourpoorwebsite.com> into their main page. Now you've got billions of requests and your website is DDoSed. Who's bad here? Browser which allows requests from google.com to yourpoorwebsite.com? Or Google who decided to kill your website?
Those port scanners abuse that feature. <img href="https://website-resolving-to-127-0-0-1.com:1234"> is a legitimate code and browser is expect to establish TLS connection to 127.0.0.1:1234.
Trying to patch that fundamental behaviour is hard.
Websockets are not enemy here. They are just convenient tool. It could be implemented without websockets.
Imagine that google.com added <img src=yourpoorwebsite.com> into their main page. Now you've got billions of requests and your website is DDoSed. Who's bad here? Browser which allows requests from google.com to yourpoorwebsite.com? Or Google who decided to kill your website?
"One website can use resources from other website using img, script, link tags."
Interestingly, you can't do this for web fonts, because they require CORS, which was only added to make type foundries happier by making hotlinking fonts not possible.
Interestingly, you can't do this for web fonts, because they require CORS, which was only added to make type foundries happier by making hotlinking fonts not possible.
[deleted]
Trying to patch that fundamental behaviour is hard.
There's prior art for this, though:
https://web.archive.org/web/20121001002815/http://my.opera.c...
There's prior art for this, though:
https://web.archive.org/web/20121001002815/http://my.opera.c...
This reminds me of the DDoS service that was using adverts on various ad networks to abuse firefox’s ftp:// url support in exactly the same manner, because ftp protocol didn’t have any limitations, so there were 65k connections spawned simultaneously per client/bot.
But I don't agree with the overall thesis, that the web fundamentally should not get features like these. Though, obviously, some of these "standards" have been rushed through and poorly executed.
I think for this we can blame Chromium's dominance. As the author said, many of these features were probably motivated by Chrome OS. And the devil's bargain of letting Chromium take such complete control over the web is that Google can strongarm whichever new "standards" they like into the Web.
The standards committee doesn't want WebBatteryStatus? Fine, we'll implement it anyway and now Chrome desktop/mobile, Chromebooks, and Edge will all have it. Sites that want to use it will probably just use it and throw up a "Use Chrome" notification for Firefox and Safari.