Clever. And so frustrating that optimisations need to be turned off due to bad actors.
Letting any website and their friends (and the friends of their friends) run turing complete code on the client PC probably sounded reasonable when the web was created but it seems incredibly naive in hindsight. It's not as bad as ActiveX and other plugins, but it's pretty close.
Hopefully both, someday :)
Also, good regulation is important to keep the big dogs on a leash and to have something to go after them when they don't behave.
Technological solutions will of course come, but you also need regulation, especially until the technological solutions come.
No, this is really out of touch with how crime online works. People that want to hammer a bank rent botnets, use tor, vpns, etc.
Banks get absolutely zero protection from the law in that regard. It’s “illegal” but completely unenforceable to the point of being useless.
Yes there is. A mugging is still a mugging even if the victim is "free" to give their wallet.
> websites are free to not abuse cookies to track their users.
You're free to not use such websites.
I dislike tracking and avoid being tracked myself. But this absolutely is a regulation and it's immensely disingenuous to pretend otherwise.
On the other hand, many sites work better with JS disabled: they load much faster, don't slow down scrolling, don't break copy & paste, and so on.
edit: I should probably make clear that I'm not the same user you responded to
I'm not a promiscuous browser, if I click on an interesting link and I get an empty page because it insists on javascript I close that tab and figure I saved myself from wasting my time on a crappy ad-tracking-infested website, so many of which are lame anyways.
That being said I do sometimes enable javascript temporarily on sites when I am desperately looking for some specific bit of info, then I reset back to my default-off when finished.
I've been doing this for a couple/few years, and it doesn't seem like a big deal to me. I'm happy to have that reminder that a site is irritating me insisting on javascript for no good reason, more often I go elsewhere and that suits me fine. It saves me from having to worry about so many nefarious things that go on in this space.
Why not give it a try? Ublock lets you default disable all javascript and enable it on the page you are looking at with a couple clicks, and edit/revert your list of rules whenever you want. You might be pleasantly surprised at how few times you need to fiddle with it after you set it up for your important sites.
What frustrates me the most is that we can't individually disable web api's that provide no value to us. Yeah, that would give greater entropy to fingerprinting, but I'm willing to take that tradeoff if I could prevent webrtc, motion sensing, screen size detection, or web assembly e.g. except on selected whitelisted websites.
"No no no. The problem isn't unencrypted network connections, it's companies and people who use them in evil ways. I would rather handle that even if it's much harder."
Should we not have introduced HTTPS? Permission models on modern operating systems? 2-factor authentication?
What about Javascript makes it different to the problems solved by these other features?
[0] https://addons.mozilla.org/en-US/firefox/addon/disable-javas...
---
[1] https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-...
Obfuscated to resist ad-blockers and anti-tracking features.
At least that's how I understand it, care to give ideas why it's not a positive change? :)
What I wrote above: it's going to encourages 10x more bloated and obfuscated websites.
Apart from the security and privacy issues, it will make the web even less accessible to users with slower Internet connections (some 2bln people) and visually-impaired users.
Not exactly.
The root of all evil here is HTTP. You don’t need any JavaScript to plant cookies or other tracking assets. As a proof this technique is used to track users in email, such as embedding a 1 pixel image in an email retrieved via HTTP.
I guess it's probably a bad idea to let the browser send this type of potentially unique info to the server by default, but I understand how it makes sense from a performance perspective.
As far as I'm concerned privacy should always trump performance, but I realize that not everybody shares this point of view.
Suppose, that you are visiting a web site with Evil Embedding (an iframe tag or script, that loads Evil Resource on behalf of advertiser). If your browser requests Evil Resource without telling advertiser the name of top-level site, the advertiser gets little. They get to know, that user 9062342154 is online and they are asking for Evil Resource X, but that's all. They can't even tell, which specific website is being visited!
The real problems start, when the top level web site cooperates with advertiser by running a Javascript "bridge", that acts both as an arbiter and a communication channel for siphoning your information. In addition to transferring information, the bridge acts as anti-fraud measure to confirm, that there is no foul play on the part of web site operator. Since the script is Turing-complete and can be updated anytime, there is no way to restrict it's actions.
But the advertiser will get the referrer so will know the domain name?
(And if they didn't, they could require the site operator to include the site name in the resource URL.)
Oh stop with the dramatics, please. JS has brought us an immense amount of innovation on the web. It has lowered the barrier of entry to programming and introduced tens of millions of people to the world of development.
If you're on HN the odds are that directly or indirectly, JS is one of the reasons you have a job today, and that you can execute it remotely. And today specifically, it's the only reason many kids can do remote learning as efficiently as they can.
Dude/dudette, I'm not a big fan of JS but let's recognize the good it has brought on the world, instead of complaining in the likes of what amounts to "if only we still lived in caves, we wouldn't have those pesky problems with online advertising" or something.
Technically, the detail of super-cookies is inventive and surprising. The general trend for how capitalism inevitably both uses and abuses advertising was predictable.
What does JS have to do with my VPN? What was wrong with Skype? Still beats the pants off others for quality.
I cannot think of much good agressive whitespace, hamburger menus, infinite scrolling, HID hijacking, copy-paste preventing, trackers etc, etc etc, has brought us, besides into the world of Aggressive Ad Arbitrage.
Need https://motherfuckingwebsite.com/ be mentioned?
The real powerhouse was Flash, then HTML5, and now WebAssembly, or as I like to call it, reinventing the wheel while simultaneously and conveniently blocking ad-blockers.
This has shades of "What have the Romans ever done for us".
That's like saying wool is useless because you don't like modern fashion.
This meme needs to die.
WebAssembly doesn't prevent ad blocking at all. Ad blocking relies on blocking network requests for the most part, which can still absolutely be blocked when done by WASM.
Some ad blockers also optionally relies on removing DOM nodes for greater coverage. It's important to note that this technique is used to reduce visual clutter, but doesn't prevent tracking, and doesn't increase browsing performance as the ad still gets downloaded before being removed.
Yes, a purely canvas-based app could work around DOM blocking, but WASM has nothing to do with it: you can do pure canvas-based UIs in javascript too, that's what all the modern web games do.
Skype is superceeded by a half dozen more targetted classroom video chats - none of which need installing or require the kids to have accounts.
From the perspective of more easily deployable apps that are more useful to end users, WebAsm > HTML5 > Flash. The fact the ad monopolies run our major web developments is convenient for them to piggyback these changes, but isn't the drive for them.
The sad part is we're probably just one decent privacy bill away from making almost all of this go away. JS + an anti-regulatory political climate is the larger problem. The EU has tackled this heads on recently with its privacy laws. At a certain point, technical work-arounds just don't work and the bad commercial actors will always win unless there's regulation stop them.
JS has dumb flaws. It doesn't mean anything is happening "in spite" of it. If anything, innovation is happening thanks to JS AND in spite of its flaws. But don't think for a second we would have even one tenth of the developers we have at our disposal today if JS and the internet didn't massively lower that barrier of entry. And less developers means less progress overall in the entire industry, not just less left-hand libraries.
It has a type system. "Excellent" feels a bit strong.
https://blog.asana.com/2020/01/typescript-quirks/
https://www.executeprogram.com/courses/typescript/lessons/ty...
That second article is legitimately cool though.
I think Basic, Pascal or Python achieved more at that.
> it's the only reason many kids can do remote learning as efficiently as they can.
The main reason is internets and TCP/IP, that’s essential and irreplaceable. Another important reason is h.264, equivalents do exist, but given the state of hardware acceleration it’s irreplaceable, at least not on mobile devices.
JavaScript ain’t an essential tech, as it’s replaceable on both clients and servers. Your kids would learn equally efficiently using a native app instead of these JS-rich web sites.
And TCPIP may have helped but just because it's essential part of the stack doesn't mean the remote learning could have happened without JS existing (in the time it did). The web would be a glorified FTP server if some people here had their way.
Javascript is one of the, if not the, most influential technologies of the past 100 years. It changed the course of history. Can you say the same of, like, wxWidgets or whatever UI toolkit you'd be using for your native app?
That's... one hell of a claim.
A sandboxed environment was a huge idea and the browser has been the primary example of how great it can be. The app model in mobile with permission isolated access is more or less the proprietary re-implementations of the browser sandbox.
To apply the common construction analogy to JavaScript: no one would call a quick sketch on a napkin a valid blueprint for a building.
what problems? Yeah, stuff like left-pad happened with NPM, but that has nothing to do with sandboxed scripting in browser. Also within my already-depressingly-long career, I had more problems with deploying "robust" .NET desktop apps (WPF & Forms) and even Qt based supposedly "cross-platform" apps than web apps. Web is the most robust platform I've ever worked with, and that's by a huge margin.
JS as a language has problems[1] but the idea behind it proved itself to be great.
[1]: and with the latest additions it's one of the better programming languages to work with, although the standard library sucks (or more like, nearly non-existent). But that's totally another topic.
The browser runtime is what enabled us to use software provided by a huge number of developers of varying aptitude and motivation without putting in place some centralised gatekeeper with its own vested interests.
It would be naive to download and run native code for every website you visiti, yes. A few that you trust and where you think that is warranted is a different matter.
Running javascript in a sandbox provides the illusion of safety so it gets enabled by default while still creating tons of problems.
We tried that, and the security issues it caused were orders of magnitude more severe than any of the problems caused by defects in an up-to-date browser sandbox. Basically all consumer PCs used to be infested with viruses all the time. It sparked an entire virus scanning industry.
It takes far too much discipline and diligence to make sure that you can trust the motivations and security capabilties of all your software providers. Sandboxing is good. It's the only thing short of the most heavy handed, restrictive and centralised control that has ever worked.
The security issues we have on today's Web are overwhelmingly unrelated to client-side security. The problem is protecting the data that is stored on servers and the incentives created by ad based business models. All of that is equally problematic regardless of whether you run native code or sandboxed JavaScript.
I think we could have done better if we knew what we were doing.
And wasted zillions of man hours to relearn the latest web framework every 2 years. Good job JS. We all love you.
JS didn't lower the barrier to programming at all. On the contrary, programming with VisualBasic and SQL was 10 times more accessible and productive than web development. What enabled millions to write software was the availability of computers in every household.
What the Web did was revolutionise software distribution. After making a change to my 1990s style VB program I had to pack a stack of floppy disks and travel to my customer to install the new version on their PCs, migrate the data, make sure everything still worked in spite of other programs installing an overlapping set of DLLs, etc.
With the Web, we took a massive hit in terms of developer productivity and complexity, but the distribution model trumped absolutely everything. It also made things possible that would have been completely unthinkable, such as running software made by a large number of developers you don't know and don't necessarily trust with all your data.
To this day, the Web is the only reasonably secure runtime environment that isn't centrally controlled by some gatekeeper with its own agenda.
So I actually agree with most of what you have said elsewhere in this thread. But I disagree about lowering the barrier for developers.
I think OP meant it as browsers that run JS. The built in console is so useful for testing/practice. You can run JS without any setup on most popular OS - Win/Linux/Mac.
You can practice JS in console while viewing YouTube tutorial or following a JS blog/ Mozilla dev page.
Everyone who had MS Office installed back in the 1990s (which was basically everyone) could easily run some quick VB code to try things.
But the difference was that you could also create proper applications with a UI, a database and (optionally!) some glue code.
We just had no good way of distributing our apps. Creating anything collaborative that wasn't restricted to a local network was exceedingly difficult as well.
The Web fixed all that, albeit at the cost of cratering developer productivity, a massive increase in complexity and higher barriers to entry for new devs.
And if you're asking me why the number of developers exploded while the barriers to entry supposedly went up, my answer is that the new opportunities that came with unrestricted worldwide distribution of software trumped the narrower issue of writing that software in the first place.
Can't be everyone, how do you know the numbers? How many Office users actually used VB? MS famously stifled competition in internet browsers. 1990s numbers still won't give a fair picture.
>The Web fixed all that, albeit at the cost of cratering developer productivity, a massive increase in complexity and higher barriers to entry for new devs.
Why blame the web for higher barrier to entry. JS is doing fine. See a few surveys for popular languages: https://insights.stackoverflow.com/survey/2020#most-popular-...
You don't acknowledge the need to sandbox code, regardless of language.
No, it was already very unreasonable, especially as the browsers of the time had even worse sandboxing than now.
But even if you turn off Javascript, you are not invisible or untraceable, you are just getting a little harder to be tracked. I don't wanna name anyone, but there are tons of famous websites that tracks by including <img> tags and referencing pixel trackers.
I usually browse with JS turned off, it's blazingly fast, and, well most websites work without any significant drawbacks.
Gmail no longer loads them. Thunderbird no longer loads them. Most providers, offering online email, have already caught on.
> Trust me, people will find ways around it without JS. Reinventing Flash, for a start.
There is no need for that. Why bother, when you can write a mobile app in proper computer language and eliminate the middleman (browser)?
Definitely this. Reminds me of the whole Spectre/Meltdown debacle.
I suspect you'll find this is _way_ more common than you expect.
(Also, if you thing Goog aren't doing this with their font CDN or various javascript library coaches, even (or especially) for sites without Google Analytics... I've got a bridge to sell you...)
The likes of Amazon, Google, and Facebook are the envy of the Government, if anything.
Of course publishers don’t follow it and do the exact opposite: default allow everything, click every single one to say no.
For cross-origin, you'd add CORS.
If you generate a random URL, you'll always get a cache miss.
If you use a static URL, you'll know if you have a new session or not, but that doesn't tell you what the tracking ID was.
The only thing I can imagine is the server serve several images /byte1.png /byte2.png etc. and make them all X by 1 pixels, encoding a random value in the dimensions, assuming that's available to Javascript.
But if you encode the tracking ID in the image somehow, you don't care much whether it was cached or not, it's inherently persistent. It'd mainly be useful if you're trying to reconstruct a super cookie.
As Mozilla have said:
> "In the case of Firefox’s image cache, a tracker can create a supercookie by “encoding” an identifier for the user in a cached image on one website, and then “retrieving” that identifier on a different website by embedding the same image."
The identifier is encoded into the image itself on a fresh fetch of the static URL, which can then be extracted by JS (which can access pixel data, and their RGBA channel values).
When a cache-hit is detected, you know you have an identifier that correlates to user history.
If you have to hit the server on that static URL, you write a request handler that will always give you back a new image with a new ID encoded in the pixels. Think of it like dynamic page generation on the server side, but for an image instead. Every time you hit the same URL you get a different image.
On the client you can decode that ID and use it throughout your code, in network requests, etc., to track user activity.
If the image is already cached you just decode the ID and use it as described above. All the browser cares about is associating a URL with a resource: it doesn't know or care that the resource in question changes every time it's asked for.
Also, the client code literally doesn't need to care whether the ID is from an image in cache or an image returned from the server.
The server can simply tie all activity for a given ID together on the back end.
This is one way of doing it: there are probably others. I'm certainly no expert.
When image loaded, js read the identifier, if the image loaded from cache, the identifer still same
Edit: typo
1. On site A, make a request to eviltracker (e.g. load an image); eviltracker returns an image encoding some unique identifier. Maybe the image request contained some cookie data which the server includes as part of the image.
2. On site B, make another request to evil tracker with the same URL. Browser helpfully notices that the image has been cached, and so site B can access the information contained within that information. In such a manner, information has been transferred from site A to B. You could theoretically repeat this process again: make another non-caching request to eviltracker (maybe with some cookie set to the combined A+B info)
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabl...
"Personalized" ads are partly a scam to devalue publishers: set a tracking cookie when a user is on an expensive-to-advertise-on website, and then serve ads to the very same user when they visit cheap sites. I'm dumbfounded why reputable publishers put up with this.