In protest of the web{*} bulldozer, a response to websocket port scanning
medium.com
medium.com
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.
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.
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.
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.
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
But whatever the case is, Safari definately does not support webp and special exceptions need to be made to support this edge case.
Nope you are right, when reading the linked issues, safari doesn’t have webp support.
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 count that as a good thing about ios safari.
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.
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.
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.
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.
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.
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?
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.
The idea isn't bad, but it should probably be guarded behind some permissions...
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.
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.
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 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.
Chrome's lumbering march to total dominance has been frightening to watch for many years now, and it only seems to be accelerating.
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...
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.
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.
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?
There's prior art for this, though:
https://web.archive.org/web/20121001002815/http://my.opera.c...
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.
https://w3c.github.io/ambient-light/#usecases-requirements
The camera one especially seems convincing to me.
>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.
- 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.
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.
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
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.
“Binary executables” makes it sound like it's machine code, but WebAssembly is more like a bytecode for JavaScript.
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.
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.
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.
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.
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.
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.
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).
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.
It’s a shame because it meant you could run your own server for eg js/html games.
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: 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.
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.
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.
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?