Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Spectre and Meltdown Mean for WebKit

webkit.org

Post reply on HN
Print view View original

241–250 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#241

Post by nkristoffersen »

zero_shift wrote: post #188
UweSchmidt wrote: post #185

Earlier quoted context omitted.

See Netflix, spotify. Those or others will come for content when ads are gone.

But then why haven't "Spotify for Journalism" projects ever worked? How does a business go from $2 per paper to 0.2c per article? Why are so many artists so unhappy with their meagre Spotify royalties? I think this falls under my "proven to scale" condition. [In reply to the below - as we have reached the thread limit: there will _always_ be free competition. The problem is: without advertising, the only players left…

Regarding royalties: My understanding from school is that radio royalties are paid out by samplings from radio playlists. If you song was in the sample then you got paid, otherwise, nope!

Don't the current streaming tech pay artists per literal play? If so, wouldn't that mean more money to the artists since all plays are counted?

My understanding is a bit outdated now perhaps, but would like to understand better if someone knows better :-)

Re: What Spectre and Meltdown Mean for WebKit

#242

Post by SquareWheel »

madez wrote: post #32
pizlonator wrote: post #31

Earlier quoted context omitted.

And yet presumably you didn't get pwned in the process of writing that comment. It's true that securing the execution of untrusted code is hard. But it's not impossible.

Commenting here works just fine without JavaScript.

Yes, but at the cost of:

1. Increased complexity on the server side to handle both cases.

2. Degraded experience on the client side (page reloading for simple actions like upvoting).

Re: What Spectre and Meltdown Mean for WebKit

#243

Post by robin_reala »

bennofs wrote: post #169
littlestymaar wrote: post #144

Earlier quoted context omitted.

> No, drop down menus, pre-validation of forms, adaptive rendering are the daily experience. Javascript is just the way we currently achieve that. I argue that a better html would avoid having to do this in javascript, as these are standard features that are needed everywhere. You can certainly standardize a certain set of feature and put them in a non-turing-complete language like HTML, but standardizing all the leg…

> non-turing-complete language like HTML I would be careful about that: It wouldn't suprise me if HTML with CSS (at least with all the new things like animations) is turing complete (it probably is).

‘You can encode Rule 110 in CSS3, so it's Turing-complete so long as you consider an appropriate accompanying HTML file and user interactions to be part of the “execution” of CSS.’

https://stackoverflow.com/a/5239256/453783

Re: What Spectre and Meltdown Mean for WebKit

#244

Post by SquareWheel »

alkonaut wrote: post #97
stcredzero wrote: post #16

A lot of game-related media has reported that a lot of games are largely unaffected by Spectre and Meltdown. My impression is that the most common result is "about 3%." (With some notable exceptions, however.) Does this bode well for Apple code, which seems to tend to pull in innovations from games into the general UI?

The performance issues come from security mitigations when entering/exiting the kernel during syscalls. So I/O heavy workloads such as databases will suffer, whereas heavy compute-oriented tasks such as games should be mostly OK. This is expected. There is nothing any company can do to "take advantage" of the fact that games are cpu/gpu bound in order to mitigate new performance issues in e.g. databases.

Exactly. Though it may encourage different performance best practices now that syscalls are considered more expensive.

Re: What Spectre and Meltdown Mean for WebKit

#245

Post by roywiggins »

cm2187 wrote: post #92

I 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…

I can't help thinking that some large percentage of what Javascript is used for could be replaced with a much less powerful language.

Re: What Spectre and Meltdown Mean for WebKit

#246

Post by netcraft »

cm2187 wrote: post #118
iovrthoughtthis wrote: post #105

Earlier 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.

No, drop down menus, pre-validation of forms, adaptive rendering are the daily experience. Javascript is just the way we currently achieve that. I argue that a better html would avoid having to do this in javascript, as these are standard features that are needed everywhere. And even if Intel comes up with a new design available for sale next month, we will still be stuck for many years with this flaw on all the devi…

If history is any indication, getting browsers to design, agree upon, and implement "better html" would take about as long as fixing cpus.

Re: What Spectre and Meltdown Mean for WebKit

#247

Post by sillysaurus3 »

cm2187 wrote: post #198
krapp wrote: post #167

Earlier quoted context omitted.

> I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages, or not allow anyone to program a GUI unless they can justify the use of canvas space. Yet the web, arguably the most successful and free (as in both beer and freedom) and access…

Random, unexpected, untrusted c/c++ written code doesn't execute on my machine every time I browse a website. The only c/c++ code is code I downloaded and installed or that my OS vendor trusted to include in the OS. It's quite different from javascript where the code is literally executing uninvited, often by 3rd or 4th or 5th parties of the website I visit.

The only c/c++ code is code I downloaded and installed or that my OS vendor trusted to include in the OS.

You never brew install anything? Or brew cask install, or git clone followed by make, or...

Even npm install sometimes compiles C.

It's hard to get away from c/c++ code.

Re: What Spectre and Meltdown Mean for WebKit

#248

Post by tasty_freeze »

pizlonator wrote: post #25
tasty_freeze wrote: post #22

With current CPU design there is only so much that can be done, but the architectural fix seems obvious to me, one that doesn't give up the performance benefits of speculative execution and branch prediction. The data in caches, the TLB, and the state tracked by branch prediction must be segregated by the protected mode bit. That isn't sufficient so solve all the problems, but seems like it solves a number of them.

The problem that JSC is dealing with is that Spectre allows untrusted JS code to read things from the memory of the process that runs it. We don't want to allow that, but I don't think your proposed solution would fix it.

What JSC is doing is addressing a problem that exists in today's CPUs. I'm saying what future CPUs need to do to avoid certain classes of sidechannel attacks. That list isn't sufficient, but if it isn't done it seems like inviting other future attacks.

Re: What Spectre and Meltdown Mean for WebKit

#249

Post by freeone3000 »

SquareWheel wrote: post #240
dingo_bat wrote: post #100

Earlier quoted context omitted.

> There are websites that genuinely need to run some code, like webmails, Not really, not if you think about it. Webmail doesn't need anything more than html( > online trading platforms Ditto. > online games Honestly, I think running webgames in a super-sandboxed flash (or similar) runtime is the best thing to do. Again, no use for js on the web.

>Not really, not if you think about it. Webmail doesn't need anything more than html( Because redownloading the entire page every time you click a button is such a great experience...

The page without the javascript? It likely would be, since that would be much smaller.

Re: What Spectre and Meltdown Mean for WebKit

#250

Post by ancarda »

krapp wrote: post #167
cm2187 wrote: post #92

I 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…

> I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages, or not allow anyone to program a GUI unless they can justify the use of canvas space. Yet the web, arguably the most successful and free (as in both beer and freedom) and access…

>Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages

Isn't that exactly what a lot of people have been saying ever since Rust started taking off? Every time there's a security vulnerability, someone suggests rewriting the program in Rust, if not some other safe program.

Post reply on HN