Ask Slashdot: Does WebAssembly Increase Your Web Browser's Attack Surface? (github.com) 104
Steve Springett is a conscientious senior security architect. And in 2018, he published an essay on GitHub arguing that from a security engineer's perspective, WebAssembly "increases the attack surface of any browser that supports it."
Springett wrote that WebAssembly modules are sent in (unsigned) binary format — without a transport-layer security mechanism — and rely on browser sandboxing for safety. But the binary format makes it harder to analyze the code, while sandboxing "is prone to breakouts and effectiveness varies largely by implementation. Adobe Flash is an example of a technology that was sandboxed after a series of exploits, yet exploits and breakouts still occurred." Springett even went so far as to offer the commands for switching off WebAssembly in your browser.
Now Tablizer (Slashdot reader #95,088) wants to know what other Slashdot readers think of Spingett's security concrens around WebAssembly.
And also offers this suggestion to browser makers: Browsers should have a way to easily disable WebAssembly — including whitelisting. For example, if you need it for specific gaming site, you can whitelist just that site and not have WASM exposed for other sites.
Springett wrote that WebAssembly modules are sent in (unsigned) binary format — without a transport-layer security mechanism — and rely on browser sandboxing for safety. But the binary format makes it harder to analyze the code, while sandboxing "is prone to breakouts and effectiveness varies largely by implementation. Adobe Flash is an example of a technology that was sandboxed after a series of exploits, yet exploits and breakouts still occurred." Springett even went so far as to offer the commands for switching off WebAssembly in your browser.
Now Tablizer (Slashdot reader #95,088) wants to know what other Slashdot readers think of Spingett's security concrens around WebAssembly.
And also offers this suggestion to browser makers: Browsers should have a way to easily disable WebAssembly — including whitelisting. For example, if you need it for specific gaming site, you can whitelist just that site and not have WASM exposed for other sites.
Yes. (Score:5, Insightful)
Yes.
Re: Yes. (Score:5, Informative)
How is this even a question? (Score:2, Insightful)
Just another pile of "whee! lookit us!1!" code, as everything else in this browser/webbertube space.
The real question is: Has anyone realised this?
To which the answer is, yes, everyone not stupid. But that's the same set of people who both have the requisite insight into piles of code and who generally stay well away from diddling with "'web".
Put another way, "How have the people involved not realised this?"
The people who do diddle with "'web" either have corporate interests and don't care, or are enamo
Re: (Score:2)
From the perspective of responsiveness and performance I can understand the speculative execution but for the perspective of power efficiency it's not that good.
Speculative execution is also of course a potential risk of a security issue, but it will require in-depth knowledge to utilize it in a meaningful way.
Re: (Score:2)
Put another way, "How have the people involved not realised this?"
The people who do diddle with "'web" either have corporate interests and don't care, or are enamoured by the idea, and thus don't care, or both. Notice a pattern here? The people who come up with this shit just don't care.
"It is difficult to get a man to understand something when his salary depends upon his not understanding it."
- Upton Sinclair
Re: (Score:2)
The real question is: Has anyone realised this?
No. The real question is: is it worth it? Every new app on server/phone/PC increases risk of break in. But we install them because it's worth it (for us). Sometimes because risk is low, sometimes because (perceived) gain is high.
Re: (Score:2)
WASM used to just be a subset of JavaScript that was easy to optimize and made a good compilation target. This allowed existing browsers to use wasm, unmodified. It would have been hard to complain about an increased attack surface in that case, as nothing new needed to be added.
From what I understand, the current version of WASM is not just a binary version of that old subset, but something more like LLVM. It's designed to be an efficient compilation target and easy to recompile into native code (eithe
Re: (Score:2)
The standard first post for something like this is:
Betteridge's Law
No.
Re: Yes. (Score:2)
Talk about wasting time... (Score:4, Interesting)
... did developers not notice the last 23 years of PC game theft, and the evils of mainframe computing and client-server executables?
To complain about web assembly in a world of steam, world of warcraft and locked down android and mobile devices like iphone, web assembly is the least of your worries. The thing that should actually worry us - is the death of local applications, because by defintion if you have any client-server app you don't own the device or application.
So any steam/uplay/mmo/f2p app can literally harvest your data because you don't have the source to see what valve/and the rest of the software and hardware industry is harvesting from your PC.
I'm sure many of these developers have a copy of steam and windows 10, I've seen developers almost proud they are using malware like windows 10 and 11. Either way the battle for privacy and security was lost because the average person on our planet simply keeps buying client-server infested exe's with drm and encryption.
Re: (Score:2)
The thing that should actually worry us - is the death of local applications, because by defintion if you have any client-server app you don't own the device or application.
I wouldn't go that far actually. No, I wouldn't put it that way.
"Client-server" just means there is a client and there is a server and they talk to each other. If they do it over an openly-specified protocol then it's no longer necessarily the case you're talking about.
Dude you are an idiot, when I mean "client server" I mean a program who which is note entirely running locally on your PC and is using the network cable as a dongle for missing files and game code, mmo's were just a rebranding of PC games so they could steal them and prevent piracy, they are litearlly just PC games with missing networking code, the plethora of server emulators for ultima online and wow should put to death any idea that they rerquired user names, login accounts, and magical networking code t
Re: (Score:2)
so you're going to have to recognise that "client-server" has a fixed and specific meaning....
And you missed the enitre context of the OP story, what was the OP complaining about, the large attack surface, now considering the topic you're being a total fucking tool. The tool was about web assembly leading to large attack surface in browers, not getting that ANY client-server program like steam, mmo's, windows 10, iphone IOS, and android have HUGE attack surfaces, so why would web assembly be anything when people are willingly taking up software that has constant open ports?
You are really a jackass
Beautiful (Score:2)
One little change and your description is perfect:
when I say "the cloud" I mean a program who which is note entirely running locally on your PC and is using the network cable as a dongle for missing files and game code, mmo's were just a rebranding of PC games so they could steal them and prevent piracy, they are litearlly just PC games with missing networking code, the plethora of server emulators for ultima online and wow should put to death any idea that they rerquired user names, login accounts, and magical networking code to begin with. It was a bid to artificially increase the price of software and games.
They're right about the term client-server - that's well defined as just a set of roles most things talking across a network will adopt.
But your description perfectly encapsulates how "The Cloud" is different. They've engineered a digital gatekeeper economy on top of what was designed to be a communications platform, and are not being responsible with their position.
Re: (Score:2)
You're right about client-server.
Signing code, so you know who wrote it, isn't a bad thing. in fact a significant percentage of the time people try to run malicious code in my company, they mistakenly think they are running something from a trusted source.
Having the code signed so I can tell whether it's actually an original DLL from Microsoft or an original driver from Ubuntu is a *good* thing for security.
I've been a security professional for 25 years. I have a couple degrees in the field. Last week I spo
Re: (Score:2)
You're right about client-server.
Signing code, so you know who wrote it, isn't a bad thing. in fact a significant percentage of the time people try to run malicious code in my company, they mistakenly think they are running something from a trusted source.
Having the code signed so I can tell whether it's actually an original DLL from Microsoft or an original driver from Ubuntu is a *good* thing for security.
I've been a security professional for 25 years. I have a couple degrees in the field. Last week I spoke at Defcon 214, next month I'll be speaking at Defcon in Vegas. Security professionals show up to hear me, so apparently I've learned a few things. Damn right I have my TPM fully enabled, so my keys are protected like they are supposed to be. Damn right I want to know that my Linux drivers haven't been hijacked by malware, so I use secure boot.
What I don't do is buy hardware that prevents me from running my software of choice, by locking the bootloader / EFI with a key they won't give me.
And for being a security professional it really doesn't matter because the masses have taken up windows 10 and steam, and the fact you're falling into the trap that was sprung by big media companies, they are changing how exe's and files will be issued over the next coming decades, and ou will always be permanently identifiable with TPM keys on your PC. So no more anonymity for you on the internet (IP addresses give reasonable doubt, hardware encrypted identifiers will always id your PC the same, regardless
Re: (Score:2)
Re: (Score:2)
Nice whaddaboutism! Let me see if I can one-up you: why worry about controlling your compute environment when youâ(TM)re certain to die anyway? You should be focused on cancer cures *instead of* computer security issues.
Did I do it right?
Man, you really don't grasp how companies operate, companies only want "Security" for drm and harvesting data from users (aka so they can engage in malfeasance and get away with).
It's not what aboutism, companies want you always online (aka PC games, mobile, etc) for ads, engagement and data, their interests are at odds with a geninely secure computer that allows you to block stuff, lie to google and have control over your PC. Like we had with CPU's from the 60's until the mid 2000's and early 2010's (inte
ABI and API incompatibility of local EXEs (Score:2)
9 times out of 10 most web apps are garbage and would be bettter as a local exe.
The problem comes when the author of said local exe hasn't yet produced the exe for the combination of instruction set and operating system that your device uses. Even if the program is provided in source code form under a free software license, I'm not aware of an easy way to add support for enough of (say) Cocoa to GNUstep to get a typical Mac application building from source and running on anything but a Mac.
The most secure apps are the ones not constantly opening connections or having functions living out on remote computers
Based on how I understand "not constantly opening connections", it sounds like you favor applicat
Re: (Score:2)
Do I understand correctly?
No you don't understand correctly, a computer is a very simple device, on clock pulse a byte is pushed to CPU cache then back to ram, now in a networkworked world, the ethernet cable to your cable model and your ISP acts as a trace in giant otherboard. When you link comptuers in a network they become a single computer, and whoever programs the network owns the network. AKA you can now instanlty get your computer pwned or hacked by SaaS companies, aka software as a service is the same thing as stealing fil
Re: (Score:2)
You don't seem to grasp if ANY application requires an internet connection or user name and login account you're getting robbed.
An email client, news reader, or chat client requires an Internet connection. How would one replicate the functionality of such programs without robbing users?
Re: (Score:2)
You don't seem to grasp if ANY application requires an internet connection or user name and login account you're getting robbed.
An email client, news reader, or chat client requires an Internet connection. How would one replicate the functionality of such programs without robbing users?
Dude consider the topic of attack surfaces, you're being pedantic tool. The topic of the article was about web assembly being an attack surface, having STEAM or windows 10, which are constantly opening ports and spying on you 100% means you're constantly exposed to attack. By the god slashdot has declined.
You need to consider those are legitimate applications, we're talking about things like Operating systems, mmo's and steam, which are totally hostile malware oriented programming.
AKA since every applicat
How can an MMO be replaced? (Score:2)
that means every "MMO" PC game was just literally the game industry carving back networking multiplayer and using it is a drm mechanism to prevent game piracy, but it has the hostile side effect of b) removing control over your PC. 2) stealing features out of the game and selling them back to you at inflated prices.
I agree with your diatribe against service as a software substitute (SaaSS). So does Richard Stallman in "Who does that server really serve?" [gnu.org].
So what's the way forward? Stallman and others have suggested to fight back against the theft you describe by developing free, self-hostable replacements for SaaSS. Free software has worked well for libraries and other tools that businesses use to provide a product or service because the companies that use a program hire people to contribute to the program's maintenan
Re: (Score:2)
So any steam/uplay/mmo/f2p app can literally harvest your data because you don't have the source to see what valve/and the rest of the software and hardware industry is harvesting from your PC
Sorry but no. That issue long predates anything to do with games, and is largely not resolved with any open source either. There is practically no one out there with the skills and capability to independently audit all the code running on their PC. Fuck just the audit on OpenSSL, and the audit on Truecrypt took teams of people over a year to complete.
I'll show you some source, you'll download it without understanding it, compile it and hope I'm trustworthy. Nothing more. Hell I bet you won't even do that, I
Re: (Score:2)
So any steam/uplay/mmo/f2p app can literally harvest your data because you don't have the source to see what valve/and the rest of the software and hardware industry is harvesting from your PC
Sorry but no. That issue long predates anything to do with games,
Sigh you don't grasp the issue didn't matter because the internet didn't exist, pre 1992. The difference in an internet enabled society under american copyright law every software company can take over your computer trivially by back ending every executable and even the OS, and therby take us back to mainframe computing of the 60's, you don't seem to grasp the internet wires are just traces in a giant world sized motherboard and our PC's and phones are the defective microchips intel and amd and ms want to
Re: (Score:2)
The point I am getting from your "dissertation" is that we shouldn't worry about Web Assembly because there are other things much worse to worry about. Is that a correct assessment of your words?
"I wouldn't worry about the pickpocket because there are gang members nearby who will kill you." would be a rough equivalent?
I dunno man, I need my money if I end up surviving the gang members.
The question is "by how much?" (Score:5, Insightful)
Even if WebAssembly's design is completely secure, implementations will never be.
WebAssembly is just the standardization of things that Javascript VMs have been doing, or moving towards. If people don't use WebAssembly, they'll still use Javascript, which is not immune from security issues either. Especially with the NPM nonsense where people just blindly depend on any unverified code.
Re: (Score:2)
Wasm is somehow worse though...
Re: (Score:1)
It's not necessarily matter of which is worse, but of increasing the number of attack vectors by having more parts and features to be hacked. The key question is does WASM with JS offer notably more exploits than JS alone?
Reduce attack surface using one for both? (Score:1)
WebAssembly is just the standardization of things that Javascript VMs have been doing, or moving towards. If people don't use WebAssembly
Are any browsers running Javascript on top of WASM? Then at least you just have one implementation to try and keep secure, instead of a WASM implementation and a separate Javascript native JIT...
Re: (Score:3)
Which ones? (Score:1)
They're running Javascript on top a virtual machine
Who are "they" though? Which browsers do this?
Are you sure you are not commenting on the article the other day about being able to use Javascript with WASM? Because that's not what this story, or my comment are about. Instead it's more - are there any browsers currently putting the core Javascript engine on top of the same WASM that any web based WASM site would use?
Re: (Score:2)
Re: (Score:1)
Thanks - If that's the case the story seems kind of wrong, I don't see the attack surface increased that substantially since any exploit found you could get to through Javascript or WASM...
It definitely increases ... (Score:3)
... your browsers black box rich client capabilities and I think we can all agree that that is generally a bad thing if you let the general public and dimwitt webagency deciders do too much with wasm in the client.
I personally find transpilation to wasm useful for fancy stuff like live 3D in modern browsers, special effects or some low-level utility stuff like cryptography. ... well, see above.
Other than that I'd stear clear of wasm. It's not needed if you know what your doing. And if you don't
And as a very experienced web deceloper with 20+ years of projects under his belt I'm _very_ sceptical of anyone betting the farm on deeply wasm-centric solutions such as MS Blazor and similar tech-lock-down hacks and proprietary b*llsh*t.
Re: (Score:2)
> I personally find transpilation to wasm useful for fancy ...
The appropriate word here is "compilation".
Nope. (Score:2)
The appropriate word here is "compilation".
Transpiling to wasm and then compiling to bytecode is the procedure.
The relevant part being transpilation, because the least of people will be writing wasm by hand.
Especially not in those toolchains we're talking about. Emphaiszing that this is yet another part of the webdev camp that is prone to inner platform bloat is appropriate. Ergo: "Transpiling" is the term.
Re: (Score:2)
WebAssembly is not a high level language. It is merely a bytecode representation of an imaginary virtual machine that then gets translated to the actual virtual machine it will run on.
Re: (Score:1)
As someone who has so much experience, can I ask a question. .net Winforms and C#.
We customise our ERP system (complex electronic manufacturing) at the moment using
Some of these custom forms are very dense, displaying a dozen interacting tables, graphs and tree views on the one screen. Some are less dense but will highlight cells or rows in the paint events to highlight data.
There is a push to have these forms web based and Blazor looks like a good migration path.
It’s 98% an internal line of business
Why stop there? (Score:2)
MinaInerz (Slashdot reader #25,726) thinks that WebAssembly isn't any more-or-less secure than Javascript. It's clearly the direction that the web is heading, and if you're that concerned about WebAssembly you should probably disable Javascript, images, videos, stylesheets, certificate parsing, and network requests.
Re: (Score:2)
Exactly. WASM does not really give you much more than JS attack-wise.
Re: (Score:2)
And a vocal minority on Slashdot feel that JS alone is an unacceptably large attack surface.
We have gotten better (Score:1, Interesting)
By definition: yes. (Score:3)
An attack surface is merely a section of code. Therefore, if code (in this case) for handling WebAssembly is added to your existing code base then by definition it increases the attack surface. Some code is more dangerous than others, for example, parsers are exceptionally dangerous because they are directly accessible via input.
WebAssembly presents a fairly unique opportunity as languages can be compiled to WebAssembly and nobody has to bother dealing with Javascript. This means large binary blobs will be generated (because compilers) and we have no immediate way of discerning their function. Even minified JS was possible to read but this isn't the case with WebAssembly.
Re: (Score:2)
Even minified JS was possible to read
About as easy to read as disassembled WebAssembly.
Re: (Score:2)
Nah, you just put it through a JS beautifier. Yes, plenty of context is lost from variable names but it's different than registers which get reused as a result of optimization..
Re: (Score:2)
WebAssembly uses a stack machine, but anyways, there is not much difference between minified code and machine code when it comes to readability after you use a beautifier for the minified code and a decompiler for the machine code.
Some minifiers are actually JS to JS compilers, and they perform optimization. Reusing variables is also a common minification trick as it can improve compression ratios.
Re: (Score:2)
Some minifiers are actually JS to JS compilers, and they perform optimization.
I don't think they actually do anything so extreme but I do know they can refactor code.
there is not much difference between minified code and machine code when it comes to readability after you use a beautifier for the minified code and a decompiler for the machine code.
But there is a big difference in it's ability to execute which is very important. A pretty-printer and unminifier (can undo transforms) will produce code that can still be executed. A decompiler rarely produces code that can be compiled which means the output may not properly represent the machine code.
Furthermore, minified code is intended to save bandwidth which generally means the code isn't terribly long or it's an
Hipster's Security (Score:5, Insightful)
Automatic machine language translator that runs remote code with free access to the GPU and no questions asked: OK, let's do this!
Re: (Score:2)
In the case of FTP, the argument makes sense. Because FTP is a plaintext protocol, it's trivial to perform man-in-the-middle attacks against it.
Lots of other people have pointed out in this thread that Web Assembly is not obviously worse than, say, JavaScript in terms of attack surface. Wasn at least has a good theoretical basis for its security model. Any rich client interface will have security concerns based on the native APIs it exposes.
Re:Hipster's Security (Score:4, Insightful)
In the case of FTP, the argument makes sense. Because FTP is a plaintext protocol, it's trivial to perform man-in-the-middle attacks against it.
Being plaintext has nothing to do with the ability to perform man-in-the-middle attacks. Encryption is for privacy, not for authentication. And man-in-the-middle attacks are not really that trivial to perform. Getting a free and anonymous TLS certificate, on the other hand, is trivial.
Lots of other people have pointed out in this thread that Web Assembly is not obviously worse than, say, JavaScript in terms of attack surface.
Code written in C is intrinsically more dangerous than JavaScript code, because C's memory model comes with a whole range of bugs that JavaScript doesn't allow. And being able to remotely generate and execute specific machine language instructions on a target host allows for another range of exploits that JavaScript didn't allow to the same extent.
Wasn at least has a good theoretical basis for its security model.
Compared to what? The alternative that I'm proposing is not to have WebAssembly in the browser at all.
Any rich client interface will have security concerns based on the native APIs it exposes.
Exactly, and lumping together a very exploitable system (GPU drivers) with a system that is at risk of exploits (machine language code) might be a good way of creating a critical mass.
Re: (Score:2)
Which commonly used plaintext protocols support strong (e.g. replay-proof) authentication?
Wasm isn't just compiling C and running it on the client. I'm not sure why you are talking like it is.
Re: (Score:2)
Which commonly used plaintext protocols support strong (e.g. replay-proof) authentication?
HTTP digest authentication.
Wasm isn't just compiling C and running it on the client. I'm not sure why you are talking like it is.
Because it's designed to run compiled C libraries, and therefore it has to support the "memory is an array of bytes" model, without which C libraries wouldn't run.
Re: (Score:2, Informative)
Re: (Score:3)
There are both mechanisms for secure authentication and secure data transfer for FTP.
No browser has ever supported them. FTP support in the browser was only ever a half-baked kludge.
Re: (Score:2)
The solution was to support anonymous FTP but remove authentication support from the browser; which I believe by now was a secure safe client implementation (safe public client, not authentication safe.) HTTP authentication should be disabled too but last I checked that worked after a warning I bet many users just ignore. FTP wasn't a ton of work to continue support.
Unencrypted HTTP is just fine but we have to try to kill that too because google needed to look good after selling out Earth to the NSA.
Re: (Score:2)
FTP wasn't removed because of the browser attack surface. It was removed because it had no fucking business being in the browser in the first place. It was a kludge we fixed by making HTTP transfer reliable and resumable 20 years ago. It's removal was rightly in line with a general attack on any protocol that sends authentication over plain text.
WebAssembly adds capability to the browser that browsers benefit from. FTP in the browser only served to fuck up the FTP protocol as it was never properly supported
only a little bit (Score:5, Informative)
(Former Mozilla Distinguished Engineer here FWIW.)
Parsing WebAssembly modules does represent a small increase in attack surface, and there is additional attack surface if the browser has a dedicated WASM interpreter or JIT compiler. But in Firefox, for example, the WASM optimizing compiler uses the same Ionmonkey infrastructure as the JS engine so there isn't much new attack surface in that JIT compiler. That is very different from say Flash which had its own entirely different compiler.
WASM applications use the same browser APIs as JS does, so there is no new attack surface there. That's a big deal and one of the benefits of WASM's design over say (P)NaCl.
Overall, yeah, WASM adds some attack surface, but not much compared to the rest of the browser. And it's all contained in the sandboxed renderer process(es).
Re: (Score:2)
Exactly. Essentially you get a bit of complexity increase which comes with a bit of attack surface increase, but that is it. There is essentially nothing new that could not have been done in JS before. Some timing-based attacks may be more efficient in WASM than in JS, due to higher speed, but they were already possible in JS.
"a little bit" may magnify risk (Score:1)
> Some timing-based attacks may be more efficient in WASM than in JS, due to higher speed, but they were already possible in JS.
But hackers or crypto CPU thieves may target WASM enabled computers over non-enabled ones for the speed.
It's sometimes said that burglar alarms don't really keep out burglars, they just make the neighbor's house a more attractive target because its less workarounds. Thus, having WASM enabled may make one a bigger target because it's more CPU per hack.
Re: (Score:2)
If we can be comparative for a second, rather than absolute, wouldn't you say that the WASM compiler has a lower potential attack surface than the entire JS engine, just due to the lower complexity?
I am assuming that the sandbox risk is invariant between the two.
I believe the OP is worried that WASM represents a larger attack surface than JS when perhaps he should prefer JS.
Of course "both" may be theoretically greater, at an ecosystem level, the more the industry moves towards WASM the greater our security
Re: (Score:2)
- when perhaps he should prefer JS.
+ when perhaps he should prefer JASM.
Re: (Score:2)
Parent has good points.
Any new feature adds attack surface but WASM isn't currently a problem; not hardly anymore than JS itself. Now JS or any scripting is always a big risk; with feature creep in CSS and OpenFonts we have two more Turing complete programming languages to worry about.
WASM needs other kinds security hardening. I think signing code in an OPEN way (no CA cartels) so we can not only cache it but combine that with 3rd party verification - a web of trust even though users won't know or care ab
Re: (Score:2)
leaving performance to the WASM
The whole point of WASM is that it fits the JIT model better than JS. Without JIT, WASM is as slow as JS, because JS has been compiled to bytecode for many years now.
Performance is a security feature. Users will always choose the faster responding implementations. If one browser gets rid of JIT, it will lose all users to the one that JITs. End users prove to prioritize convenience over security always, if given the choice. So if you want users to use the most secure thing, make sure the most secure thing
Re: (Score:2)
The issue for a lot of this stuff is easy management of rights. This is not an easy problem to solve, but it should be where a huge amount of effort goes.
The idea of running downloaded code has been there for a long time. Even ActiveX had it's day.
There's obviously use cases for it, but the browser's ability to manage it is key. Some registry keys or something somewhere is not enough. I don't think you'll need it at the moment for the average website, do it's probably best it has to be an opt-in. Maybe ther
What about other browsers? (Score:2)
I'm glad to hear Firefox is trying to do it right, but I don't trust Google Chrome et al. They are more interested in mining and controlling users than in security.
How to disable it on Firefox: (Score:5, Informative)
goto: about:config [about]
set: javascript.options.asmjs to false
set: javascript.options.wasm* to false
set: security.csp.wasm-unsafe-eval.enabled to false
Re: (Score:2)
Please someone mod this man up. This is the only practical post worth its weight in salt in this whole discussion.
Malicious uses that aren't hacking attacks (Score:5, Interesting)
Two years ago, security researchers found that more than half of web sites that used WebAssembly used it to mine cryptocurrency in visitors' browsers. Another use of WebAssembly was for obfuscating malvertising. Many of those web sites had been hacked.
In my view, those were, and still are good reasons for having WebAssembly disabled in the web browser by default.
(Link to archived article without infinite scroll [archive.org], Discussion [slashdot.org])
I think that WebAssembly's future instead is on the server and maybe even on the desktop. Not only is it an architecture-neutral, language-neutral software distribution format (with more promise than ANDF ever had), but instances can be started with much low overhead compared to containers.
There are also some research OS:es that use it for regular programs: One approach I've seen discussed is to use a safe programming language such as Rust for the main system but WebAssembly sandboxes for other languages.
Re: (Score:2)
I think that WebAssembly's future instead is on the server
Oh please no. Why is it whenever a language has a horrible track record in the client we should then move it to the server? We have plenty of good server side languages and frameworks. They are far better than the nonsense that runs on the clients. If it isn't good enough for the client, it definitely isn't good enough for the server where the requirements are much harder. NodeJS is a terrible, terrible idea and is only liked by "full-stack" engineers who write non-scalable and non-secure websites for
Re: (Score:2)
In my view, those were, and still are good reasons for having WebAssembly disabled in the web browser by default.
Not really. Just because nefarious actors got onto something to make it popular doesn't mean functionality needs to be disabled. It means it needs to be made manageable.
Re: (Score:1)
Yes, "manageable", and that should include making WASM disabled by default, with a site-specific whitelist. However, having a prompt pop up like the location service is the wrong approach because too many sites abuse it, hoping some accidentally approve. Having a thin bar with a request note would be less annoying in my opinion.
Re: (Score:2)
No, the correct approach would be to make it work exactly like the disable javascript setting. Maybe there's a good reason for javascript to be enabled by default that applies to WASM.
Because JS is ubiquitous, for good or bad (Score:2)
> Maybe there's a good reason for javascript to be enabled by default that applies to WASM.
Most sites assume JavaScript works such that you won't get much traction without it. Ordinary users don't switch JS on and off as needed. JS is too ubiquitous.
WASM is not (currently) at the point where it's often "have it or nothing happens", at least outside of niches. A casual user is not going to know about or care about WASM, but if a site needs it to run, it needs a way to request activation without creating t
Re: (Score:2)
You really want to burden users with deciding what scripting runtime an application uses? Why not ask them on every site if they want to enable the javascript JIT compiler while we are at it.
Re: (Score:1)
> You really want to burden users with deciding what scripting runtime an application uses?
If the alternative is hacking and CPU theft, yes. It's why Java Applets and Flash died.
Publishers would hopefully become more judicious about what services they request if being a pig annoys users and thus reduces customers.
Re: (Score:2)
It's why Java Applets and Flash died.
Java Applets and Flash died because the FAANG companies wanted them dead, each for their own business reasons. Security of the end user was just how they sold the idea to us.
Re: (Score:1)
That's an interesting viewpoint. Do you have specifics to back it up? Are you saying all the security problems client-side Java alleged had are trumped up?
Re: (Score:2)
The security problems weren't fake, for sure, but if you look at the fingerprints on the gun that killed java, they won't be the fingerprints of a security researcher. Security researchers simply don't have enough internal clout to torpedo java in pagerank, or spin up entire teams to make a competing language and runtime like .NET. They weren't the ones who convinced Steve Jobs that he didn't want applets made for windows to find a home in safari. etc.
Re: (Score:1)
.NET was not a competitor to Java applets. Most analysts say JavaScript's speed and abilities caught up with applets such that the need to install and maintain a Java client shrank. And Macs were only roughly 10% of desktops.
Re: (Score:2)
Its literally what silverlight was: .net in applet form.
Re: (Score:1)
Nobody I know of said, "We'll use Silverlight instead of applets". Applets were more proven and had more how-to's than Silverlight; and as time went on, Silverlight proved at least as breachy as applets.
Re: (Score:2)
It happened all the time in enterprise. "our guys already know visual basic, so lets use silverlight instead of java for this UI". Today, we are well past the extinguish phase of the "embrace, extend, extinguish" w/respect to the applet software delivery model. And silverlight, having served its purpose, is dead.
Re: (Score:1)
My observation is a bit different. Yes, Silverlight was used on intranets just because it's Microsoft, but few liked it. Most cross-company work focused on Java applets.
Re: (Score:2)
Ain't no one unseating that monster.
Re: (Score:1)
Oracle's lawsuits might. They'd happily sabotage an open standard to make a few extra bucks.
Re: (Score:2)
JavaScript and Iceweasel (Score:2)
For Java, Oracle owns both the trademark and the copyright. For JavaScript, Oracle owns only the trademark. Oracle's lawyers are aware that should Oracle act up, the community has the option of doing another Iceweasel, switching to "ES6" as the name of the language.
Re: (Score:2)
WASM on the server? Please don't. The JRE and .NET already exist. We don't need to re-invent the wheel again.
Not really (Score:2)
A browser's attack surface is already huge and JavaScript is quite enough to access all of it. Sure, some timing-based attacks may be a little easier to exploit using WASM, but that should essentially be it. The bit about "analyzing the code" is pretty much nonsense, you can obfuscate JS just as well (so source code does not help) and automatic analysis is pretty infeasible at this time except for really simple things. Same for "transport layer security".
All in all, browsers are not really getting any less
Compare to javascript (Score:2)
WebAssembly modules are sent in (unsigned) binary format — without a transport-layer security mechanism — and rely on browser sandboxing for safety
How does javascript compare to WebAssembly modules in these respects? Unsigned javascript code runs constantly in the browser, and TLS is not mandatory (although in practice HTTP/2 forces it, both for javascript and WebAssembly). The only difference is the binary format then; but obfuscated javascript code and WebAssembly modules are both difficult to
nomen et omen (Score:2)
The attack surface of a web browser (Score:4, Insightful)
has been a joke since some bright spark decided a program designed to render HTML pages should also be able to execute random code blindly pulled off the internet. WebAssembly is just the latest nail in that particular coffin.
Apple's lockdown feature (Score:3)
The conclusion is that web assembly increases your attack surface. The question is how paranoid you have to be to turn it off.
Tablizer is still around? (Score:2)