[deleted]
What Spectre and Meltdown Mean for WebKit
171–180 of 294 posts
Re: What Spectre and Meltdown Mean for WebKit
#172Earlier quoted context omitted.
Unless you're considering client-side encryption, I don't think webmails qualify either (squirrelmail, for example, works pretty well without JS).
Indeed because auto-complete of recipient address from my contacts is useless, right ? Same could be said for retrieving new emails without reloading the page I guess … Had JavaScript not existed, the web would be dead a long time ago already.
Both good points (although the second one could be handled through a meta refresh I guess). But I'd like to point out we were discussing where javascript is absolutely needed, not where it's convenient.
Re: What Spectre and Meltdown Mean for WebKit
#173Earlier quoted context omitted.
running untrusted code is a fundamental part of our daily experience. If you kill the webs ability to do that, people will build something else. The we have to go through the rigmarole of securing this whole new platform with the same bugs but in different ways. Instead of neutering the web, let's build secure cpus.
The notion that there are so many users of digital devices and services because we are running untrusted, unaccounted code that is automatically executed is plain wrong. Hardware advanced in ways we didn't imagine in the past, and interfaces got better. Society learned about computers as they got cheaper and knowledge spread, while better software tools formed, accelerating the growth of the ecosystem. Nothing of tha…
> HTML (or whatever standard we come up with) can be expanded to add the needed features
I think it is hubris to think we can ever build a spec with all the needed features.
> JavaScript is used to lock us in, exactly what the web shouldn't do.
While I agree the web shouldn't lock us in I would like to understand how you think JavaScript does that?
Re: What Spectre and Meltdown Mean for WebKit
#174Earlier quoted context omitted.
running untrusted code is a fundamental part of our daily experience. If you kill the webs ability to do that, people will build something else. The we have to go through the rigmarole of securing this whole new platform with the same bugs but in different ways. Instead of neutering the web, let's build secure cpus.
> Instead of neutering the web If you took JSW off of most websites, it wouldn't be neutering the web it'd be making it better.
> If you took JSW off of most websites, it wouldn't be neutering the web it'd be making it better.
Neutering animals is seen as making them better pets, it's still neutering.
Re: What Spectre and Meltdown Mean for WebKit
#175Isn't Intel and AMD shipping new fence instructions that prevent speculative execution from progressing beyond a certain point? Why doesn't Webkit use those?
The fence instruction that Intel recommends (lfence) is way slower than the techniques described here. We measured a 5x slowdown on Web Assembly trying to use it. Also we have been working on these mitigations since well before Intel made their suggestion.
Have you considered arr[max(i, arr.len)] instead of AND?
Re: What Spectre and Meltdown Mean for WebKit
#176Earlier quoted context omitted.
Yes in the context of iOS, Android and UWP native apps.
You must run in much better circles than I do. Nevermind a naive user, the average users I know wouldn't know how to disable javascript, or whitelist sites, or that there even were sandbox settings in the OS. Some of the older people I know can't even correctly choose between between writing a text message, and a facebook post. If you think you are a typical example of a naive user, I would hate to see what you expec…
You completely misunderstood me.
iOS, Android and UWP sandboxes for native apps are always enabled, there isn't any configuration for naive user available.
You just allow or not the access to specific actions and that's it.
On UWP you cannot even access files directly, the user has to select them for your application.
You can only change the way sandboxes behave via developer settings, but that is only in the context of debugging, which naive users will never do anyway.
Re: What Spectre and Meltdown Mean for WebKit
#177One of the most brilliant features in the latest versions of Safari are per-website settings for ad blockers, notifications, location, etc. Between those two vulnerabilities and the general obnoxious useage of JS on websites, I’d love to see the addition of a per-website setting for JS. I would personally turn it off by default and only whitelist a handful of websites.
This is what I already get with FF + NoScript. And yes, I am bored by sites that I visit for the first time that will not show me any meaningful content until I enable layer upon layer of JS. Just not necessary, nor is it safe.
Same here (with noscript as well). Although I'll say it's hard to blame web developers for not considering the case where JS is disabled beyond a simple "you need Javascript to see this page" message (though even that tends to be the exception, not the rule), because noscript/umatrix users are probably in the low, low minority.
Re: What Spectre and Meltdown Mean for WebKit
#178I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of…
> An ecommerce, a newspaper or a blog should have no reason to execute client side code to render. The main reason is advertising, which is ultimately how this web content is paid for. But there could be alternatives. We could create static img elements that could securely and discretely record whether they were viewed by a human (to prevent ad fraud). We could support simple animations and interactivity in a secure,…
Static img elements with built-in surveillance and tracking, unblockable and intransparent, on a browser level? You have to be kidding.
The ad-based web economy had produced the current publishing dystopia in the first place and prevents the development of a sane business model.
Re: What Spectre and Meltdown Mean for WebKit
#179Earlier quoted context omitted.
Again, not paying attention to the news. http://teavm.org/ https://forums.adobe.com/thread/2432179 http://www.mono-project.com/news/2017/08/09/hello-webassembl... https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFut... https://github.com/Microsoft/xaml-standard/issues/197
I think we are talking about different things. Half your links have nothing to do with Flash or Java Applets (.net, XAML?). You seem to be talking about new platforms that may derive some part from the old. I'm not saying WebAssembly won't be used for new platforms as that's sort of the whole point of it. What I'm saying is that WebAssembly won't bring back people making Flash .swfs or writing classes derived from ja…
TeaVM allows any Java application to be ported into WebAssembly, be it an applet or not.
As3-WebAssembly is a compiler for porting Action Script 3, Flash's programming language, into WebAssembly. Already integrated into Flash Develop.
Microsoft and Xamarin efforts to port Mono into WebAssembly, will allow making Silverlight apps again.
You are free to believe this won't turn out into anything, I rather think we will end up in WebAssembly + Canvas/WebGL in a couple of years.
Re: What Spectre and Meltdown Mean for WebKit
#180I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of…
> An ecommerce, a newspaper or a blog should have no reason to execute client side code to render. The main reason is advertising, which is ultimately how this web content is paid for. But there could be alternatives. We could create static img elements that could securely and discretely record whether they were viewed by a human (to prevent ad fraud). We could support simple animations and interactivity in a secure,…
>The danger to killing online advertising is that it creates a world where the only people who can afford to publish are those with other interests - plutocrats, politicians, churches - and who will inevitably bankroll news only to further political ends.
You say that as if server space is super expensive, but it isn't, certainly not compared to other forms of media. It's entirely possible to publish to the web without being an elite, people and businesses did it for years before advertising on the web became a thing.