From ash...@ Wed May 2 13:18:44 2018 From: ash...@ (Ashley Gullen) Date: Wed, 2 May 2018 21:18:44 +0100 Subject: [Public WebGL] Moving WEBGL_shared_resources to rejected status In-Reply-To: References: Message-ID: > > Multiple visible canvases can be created with the '2d' rendering context, >> and an invisible WebGL-rendered canvas drawn to them using >> CanvasRenderingContext2D.drawImage. >> > > Afaik this would be pretty slow as it'll perform a readback to obtain > pixel data to put into the 2D canvas buffer does it not? > It appears to be hardware accelerated in Chrome, but it is indeed slow in Firefox and Safari: https://bugzilla.mozilla.org/show_bug.cgi?id=1163426 https://bugs.webkit.org/show_bug.cgi?id=177132 It's slow enough to not really be useful, as in you probably can't hit 30 FPS if you simply draw the webgl canvas every frame. Not much action on either report so far unfortunately. The new imagebitmap context might provide another way, but that's not implemented outside of Chrome yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed May 2 14:11:36 2018 From: jgi...@ (Jeff Gilbert) Date: Wed, 2 May 2018 14:11:36 -0700 Subject: [Public WebGL] Moving WEBGL_shared_resources to rejected status In-Reply-To: References: Message-ID: This is on the roadmap for being fixed. On Wed, May 2, 2018 at 1:18 PM, Ashley Gullen wrote: >>> Multiple visible canvases can be created with the '2d' rendering context, >>> and an invisible WebGL-rendered canvas drawn to them using >>> CanvasRenderingContext2D.drawImage. >> >> >> Afaik this would be pretty slow as it'll perform a readback to obtain >> pixel data to put into the 2D canvas buffer does it not? > > > It appears to be hardware accelerated in Chrome, but it is indeed slow in > Firefox and Safari: > https://bugzilla.mozilla.org/show_bug.cgi?id=1163426 > https://bugs.webkit.org/show_bug.cgi?id=177132 > > It's slow enough to not really be useful, as in you probably can't hit 30 > FPS if you simply draw the webgl canvas every frame. Not much action on > either report so far unfortunately. > > The new imagebitmap context might provide another way, but that's not > implemented outside of Chrome yet. > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jri...@ Fri May 4 21:02:35 2018 From: jri...@ (James Ritts) Date: Fri, 4 May 2018 21:02:35 -0700 Subject: [Public WebGL] Moving WEBGL_shared_resources to rejected status In-Reply-To: References: Message-ID: >> On a technical note, you can use glFenceSync in lieu of glFinish to guarantee data updates are propagated correctly. Ken, is there a reason fences couldn't be used to synchronize resource updates between WebGL contexts, as Jeff suggested? On Wed, May 2, 2018 at 2:11 PM, Jeff Gilbert wrote: > > This is on the roadmap for being fixed. > > On Wed, May 2, 2018 at 1:18 PM, Ashley Gullen wrote: > >>> Multiple visible canvases can be created with the '2d' rendering > context, > >>> and an invisible WebGL-rendered canvas drawn to them using > >>> CanvasRenderingContext2D.drawImage. > >> > >> > >> Afaik this would be pretty slow as it'll perform a readback to obtain > >> pixel data to put into the 2D canvas buffer does it not? > > > > > > It appears to be hardware accelerated in Chrome, but it is indeed slow in > > Firefox and Safari: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1163426 > > https://bugs.webkit.org/show_bug.cgi?id=177132 > > > > It's slow enough to not really be useful, as in you probably can't hit 30 > > FPS if you simply draw the webgl canvas every frame. Not much action on > > either report so far unfortunately. > > > > The new imagebitmap context might provide another way, but that's not > > implemented outside of Chrome yet. > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat May 5 02:31:46 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 5 May 2018 11:31:46 +0200 Subject: [Public WebGL] Moving WEBGL_shared_resources to rejected status In-Reply-To: References: Message-ID: You can see how it's kind of a problem if you can't use a capability because it's not optimized, but have no way to query if the capability has been optimized right? On Wed, May 2, 2018 at 11:11 PM, Jeff Gilbert wrote: > This is on the roadmap for being fixed. > > On Wed, May 2, 2018 at 1:18 PM, Ashley Gullen wrote: > >>> Multiple visible canvases can be created with the '2d' rendering > context, > >>> and an invisible WebGL-rendered canvas drawn to them using > >>> CanvasRenderingContext2D.drawImage. > >> > >> > >> Afaik this would be pretty slow as it'll perform a readback to obtain > >> pixel data to put into the 2D canvas buffer does it not? > > > > > > It appears to be hardware accelerated in Chrome, but it is indeed slow in > > Firefox and Safari: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1163426 > > https://bugs.webkit.org/show_bug.cgi?id=177132 > > > > It's slow enough to not really be useful, as in you probably can't hit 30 > > FPS if you simply draw the webgl canvas every frame. Not much action on > > either report so far unfortunately. > > > > The new imagebitmap context might provide another way, but that's not > > implemented outside of Chrome yet. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu May 10 20:15:20 2018 From: kbr...@ (Ken Russell) Date: Thu, 10 May 2018 20:15:20 -0700 Subject: [Public WebGL] Moving WEBGL_shared_resources to rejected status In-Reply-To: References: Message-ID: On Fri, May 4, 2018 at 9:03 PM James Ritts wrote: > >> On a technical note, you can use glFenceSync in lieu of glFinish to guarantee > data updates are propagated correctly. > > Ken, is there a reason fences couldn't be used to synchronize resource > updates between WebGL contexts, as Jeff suggested? > Jeff's right, in ES 3.0 fences can be used instead of glFinish. The fact remains that this extension would be a large and intrusive change to the WebGL API and would be difficult to use. We are going to pursue other, guaranteed ways that applications can quickly render to multiple canvases from one WebGL context. -Ken > > > On Wed, May 2, 2018 at 2:11 PM, Jeff Gilbert wrote: > >> >> This is on the roadmap for being fixed. >> >> On Wed, May 2, 2018 at 1:18 PM, Ashley Gullen wrote: >> >>> Multiple visible canvases can be created with the '2d' rendering >> context, >> >>> and an invisible WebGL-rendered canvas drawn to them using >> >>> CanvasRenderingContext2D.drawImage. >> >> >> >> >> >> Afaik this would be pretty slow as it'll perform a readback to obtain >> >> pixel data to put into the 2D canvas buffer does it not? >> > >> > >> > It appears to be hardware accelerated in Chrome, but it is indeed slow >> in >> > Firefox and Safari: >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1163426 >> > https://bugs.webkit.org/show_bug.cgi?id=177132 >> > >> > It's slow enough to not really be useful, as in you probably can't hit >> 30 >> > FPS if you simply draw the webgl canvas every frame. Not much action on >> > either report so far unfortunately. >> > >> > The new imagebitmap context might provide another way, but that's not >> > implemented outside of Chrome yet. >> > >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun May 13 08:31:46 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 13 May 2018 17:31:46 +0200 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: On Fri, Apr 6, 2018 at 12:50 AM, Ken Russell wrote: > We can not currently discuss why the extension has been disabled. We > should be able to do so in about a month. > It's now been a month and a week since this statement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ale...@ Sun May 13 09:48:40 2018 From: ale...@ (Aleksandar Rodic) Date: Sun, 13 May 2018 17:48:40 +0100 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: My guess is the extension has been disabled due to recently discovered " GLitch " rowhammer attack vector. > EXT_DISJOINT_TIMER_QUERY is an OpenGL extension developed to provide developers with more detailed information about the performance of their applications [46]. This extension, if made available to the system by the GPU driver, is accessible from both WebGL and WebGL2, and provides the JavaScript runtime with two timing sources: (1) TIME_ELAPSED_EXT and (2) TIMESTAMP_EXT. Such timers allow an attacker to measure the timing of secret operations (e.g., memory accesses) performed either by the CPU or the GPU. On Sun, May 13, 2018 at 4:32 PM Florian B?sch wrote: > On Fri, Apr 6, 2018 at 12:50 AM, Ken Russell wrote: > >> We can not currently discuss why the extension has been disabled. We >> should be able to do so in about a month. >> > > It's now been a month and a week since this statement. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun May 13 10:50:59 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 13 May 2018 19:50:59 +0200 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: 20 years on writing hardware accelerated code we have no way to measure the performance of the programs we write, on the machines our users use to run these programs. You've got to be fucking kidding me man. On Sun, May 13, 2018 at 6:48 PM, Aleksandar Rodic wrote: > My guess is the extension has been disabled due to recently discovered " > GLitch " > rowhammer attack vector. > > > EXT_DISJOINT_TIMER_QUERY is an OpenGL extension developed to provide > developers with more detailed information about the performance of their > applications [46]. This extension, if made available to the system by the > GPU driver, is accessible from both WebGL and WebGL2, and provides the > JavaScript runtime with two timing sources: (1) TIME_ELAPSED_EXT and (2) > TIMESTAMP_EXT. Such timers allow an attacker to measure the timing of > secret operations (e.g., memory accesses) performed either by the CPU or > the GPU. > > On Sun, May 13, 2018 at 4:32 PM Florian B?sch wrote: > >> On Fri, Apr 6, 2018 at 12:50 AM, Ken Russell wrote: >> >>> We can not currently discuss why the extension has been disabled. We >>> should be able to do so in about a month. >>> >> >> It's now been a month and a week since this statement. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri May 18 02:53:39 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 18 May 2018 11:53:39 +0200 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: The glitch paper suggests that: To protect the system against both GPU and CPU sidechannel attacks, > currently the only practical solution in the browser is disabling all > possible timing sources. > You see the issue with this is that it breaks our ability to measure time. That's a big deal. This is one of the early marine chronometers. It's the device that enabled precise naval navigation because now not only could you determine latitude (from the stars) but you could also pinpoint longitude fairly precisely. As the name suggests "real-time" rendering has a time component (that's the time, in "real-time"). You might infer from that fact that "time" is a rather important quantity in "real-time", and you'd be absolutely correct. Breaking time alone wouldn't be a problem if everybody had the same hardware. But that's in fact, surprisingly, not the case. Developers need to write software for hardware whose real-time performance can differ up to a factor 1000x at the extremes, up to 100x between major device categories and up to around 10x within a device category. Measuring time is therefore rather important if you want to keep it "real". Not just your time, and not just the time of individual samples of hardware you luckily happen to have access to, but time as broadly as possible. We can't do that now can we anymore? No we can't. > With Site Isolation enabled, the amount of data exposed to side-channel > attacks is reduced as Chrome renders content for each website in a separate > process The glitch paper does not suggest that "putting stuff into a process" is a mitigation strategy. Accordingly, they will remain disabled in Chrome until Site Isolation is on > by default > When is site isolation going to be on by default? When do other UAs have this? at which point they will be re-enabled with sufficiently reduced precision > to mitigate GLitch attacks What does that mean exactly? So imprecise we can't practically use them anymore to measure any performance or what? ----------- This whole episode is so unacceptable at so many levels. You're breaking the tools we need to build applications. Native applications don't have this problem (they just ignore it, any natively installed game can now steal your whatevers). You're breaking the empirical method. Now there's nothing left but blindly stabbing in the dark. Well done you, well done. On Tue, May 15, 2018 at 2:54 PM, Nicolas Capens wrote: > As mentioned here , > the WebGL timer extensions "will remain disabled in Chrome until Site > Isolation is on by default, at which point they will be re-enabled with > sufficiently reduced precision to mitigate GLitch attacks". > > > On Sun, May 13, 2018 at 1:51 PM Florian B?sch wrote: > >> 20 years on writing hardware accelerated code we have no way to measure >> the performance of the programs we write, on the machines our users use to >> run these programs. You've got to be fucking kidding me man. >> >> On Sun, May 13, 2018 at 6:48 PM, Aleksandar Rodic < >> aleksandar.xyz...@> wrote: >> >>> My guess is the extension has been disabled due to recently discovered " >>> GLitch " >>> rowhammer attack vector. >>> >>> > EXT_DISJOINT_TIMER_QUERY is an OpenGL extension developed to provide >>> developers with more detailed information about the performance of their >>> applications [46]. This extension, if made available to the system by the >>> GPU driver, is accessible from both WebGL and WebGL2, and provides the >>> JavaScript runtime with two timing sources: (1) TIME_ELAPSED_EXT and (2) >>> TIMESTAMP_EXT. Such timers allow an attacker to measure the timing of >>> secret operations (e.g., memory accesses) performed either by the CPU or >>> the GPU. >>> >>> On Sun, May 13, 2018 at 4:32 PM Florian B?sch wrote: >>> >>>> On Fri, Apr 6, 2018 at 12:50 AM, Ken Russell wrote: >>>> >>>>> We can not currently discuss why the extension has been disabled. We >>>>> should be able to do so in about a month. >>>>> >>>> >>>> It's now been a month and a week since this statement. >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri May 18 08:33:34 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 18 May 2018 17:33:34 +0200 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: On Fri, May 18, 2018 at 11:53 AM, Florian B?sch wrote: > any natively installed game can now steal your whatevers > Why aren't you disabling access to timers and synchronization queries across the board at a driver level? I certainly haven't seen an update on Android, Windows or iOS that does this. You're aware that it breaks all the sandboxes aren't you? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri May 18 18:08:11 2018 From: kbr...@ (Ken Russell) Date: Fri, 18 May 2018 18:08:11 -0700 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: EXT_disjoint_timer_query could not only be used to launch the GLitch attack, but act as a high-precision timer to carry out Spectre-like attacks. Reducing the timers' precision was sufficient to mitigate the GLitch attack, and as it turns out, Chrome's implementation of EXT_disjoint_timer_query already returned sufficiently lower-precision results. However, Site Isolation is the long-term defense against Spectre, and it's close to being turned on in Chrome by default. At that point, the EXT_disjoint_timer_query WebGL extension will be turned back on in Chrome. Other browsers have mitigations in progress for Spectre, and once those land, useful features like EXT_disjoint_timer_query and SharedArrayBuffer will be re-enabled in those browsers, too. -Ken On Fri, May 18, 2018 at 2:53 AM Florian B?sch wrote: > The glitch paper suggests that: > > To protect the system against both GPU and CPU sidechannel attacks, >> currently the only practical solution in the browser is disabling all >> possible timing sources. >> > > You see the issue with this is that it breaks our ability to measure time. > That's a big deal. > > > > This is one of the early marine chronometers. It's the device that enabled > precise naval navigation because now not only could you determine latitude > (from the stars) but you could also pinpoint longitude fairly precisely. > > As the name suggests "real-time" rendering has a time component (that's > the time, in "real-time"). You might infer from that fact that "time" is a > rather important quantity in "real-time", and you'd be absolutely correct. > Breaking time alone wouldn't be a problem if everybody had the same > hardware. But that's in fact, surprisingly, not the case. Developers need > to write software for hardware whose real-time performance can differ up to > a factor 1000x at the extremes, up to 100x between major device categories > and up to around 10x within a device category. > > Measuring time is therefore rather important if you want to keep it > "real". Not just your time, and not just the time of individual samples of > hardware you luckily happen to have access to, but time as broadly as > possible. We can't do that now can we anymore? No we can't. > > >> With Site Isolation enabled, the amount of data exposed to side-channel >> attacks is reduced as Chrome renders content for each website in a separate >> process > > > The glitch paper does not suggest that "putting stuff into a process" is > a mitigation strategy. > > Accordingly, they will remain disabled in Chrome until Site Isolation is >> on by default >> > > When is site isolation going to be on by default? When do other UAs have > this? > > at which point they will be re-enabled with sufficiently reduced precision >> to mitigate GLitch attacks > > > What does that mean exactly? So imprecise we can't practically use them > anymore to measure any performance or what? > > ----------- > > This whole episode is so unacceptable at so many levels. You're breaking > the tools we need to build applications. Native applications don't have > this problem (they just ignore it, any natively installed game can now > steal your whatevers). You're breaking the empirical method. Now there's > nothing left but blindly stabbing in the dark. Well done you, well done. > > On Tue, May 15, 2018 at 2:54 PM, Nicolas Capens wrote: > >> As mentioned here , >> the WebGL timer extensions "will remain disabled in Chrome until Site >> Isolation is on by default, at which point they will be re-enabled with >> sufficiently reduced precision to mitigate GLitch attacks". >> >> >> On Sun, May 13, 2018 at 1:51 PM Florian B?sch wrote: >> >>> 20 years on writing hardware accelerated code we have no way to measure >>> the performance of the programs we write, on the machines our users use to >>> run these programs. You've got to be fucking kidding me man. >>> >>> On Sun, May 13, 2018 at 6:48 PM, Aleksandar Rodic < >>> aleksandar.xyz...@> wrote: >>> >>>> My guess is the extension has been disabled due to recently discovered " >>>> GLitch " >>>> rowhammer attack vector. >>>> >>>> > EXT_DISJOINT_TIMER_QUERY is an OpenGL extension developed to provide >>>> developers with more detailed information about the performance of their >>>> applications [46]. This extension, if made available to the system by the >>>> GPU driver, is accessible from both WebGL and WebGL2, and provides the >>>> JavaScript runtime with two timing sources: (1) TIME_ELAPSED_EXT and (2) >>>> TIMESTAMP_EXT. Such timers allow an attacker to measure the timing of >>>> secret operations (e.g., memory accesses) performed either by the CPU or >>>> the GPU. >>>> >>>> On Sun, May 13, 2018 at 4:32 PM Florian B?sch wrote: >>>> >>>>> On Fri, Apr 6, 2018 at 12:50 AM, Ken Russell wrote: >>>>> >>>>>> We can not currently discuss why the extension has been disabled. We >>>>>> should be able to do so in about a month. >>>>>> >>>>> >>>>> It's now been a month and a week since this statement. >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat May 19 00:29:16 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 19 May 2018 09:29:16 +0200 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: On Sat, May 19, 2018 at 3:08 AM, Ken Russell wrote: > EXT_disjoint_timer_query could not only be used to launch the GLitch > attack, but act as a high-precision timer to carry out Spectre-like attacks > This isn't only true of a browser. How is this not a problem for all applications? > Reducing the timers' precision was sufficient to mitigate the GLitch > attack, and as it turns out, Chrome's implementation of > EXT_disjoint_timer_query already returned sufficiently lower-precision > results. > How much precision was reduced? However, Site Isolation is the long-term defense against Spectre, and it's > close to being turned on in Chrome by default. At that point, the > EXT_disjoint_timer_query WebGL extension will be turned back on in Chrome. > This is gonna happen when? > Other browsers have mitigations in progress for Spectre, and once those > land, useful features like EXT_disjoint_timer_query and SharedArrayBuffer > will be re-enabled in those browsers, too. > And this is gonna happen when? -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sat May 19 03:36:15 2018 From: khr...@ (Mark Callow) Date: Sat, 19 May 2018 19:36:15 +0900 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: <919DFFC6-6587-45D6-B5B7-E0C954B440DA@callow.im> > On May 19, 2018, at 10:08, Ken Russell wrote: > > act as a high-precision timer to carry out Spectre-like attacks I thought the OS?s already had mitigations for Spectre. Why do the browsers need additional ones? Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 528 bytes Desc: Message signed with OpenPGP URL: From kbr...@ Sat May 19 09:35:41 2018 From: kbr...@ (Ken Russell) Date: Sat, 19 May 2018 09:35:41 -0700 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: On Sat, May 19, 2018 at 12:29 AM Florian B?sch wrote: > On Sat, May 19, 2018 at 3:08 AM, Ken Russell wrote: > >> EXT_disjoint_timer_query could not only be used to launch the GLitch >> attack, but act as a high-precision timer to carry out Spectre-like attacks >> > > This isn't only true of a browser. How is this not a problem for all > applications? > Spectre allows reading of all memory in a process's address space. In an app it's assumed that you already have access to the full address space, but this is not true in the browser, where usually a single process will contain data from multiple web domains. > >> Reducing the timers' precision was sufficient to mitigate the GLitch >> attack, and as it turns out, Chrome's implementation of >> EXT_disjoint_timer_query already returned sufficiently lower-precision >> results. >> > > How much precision was reduced? > Chrome has always been returning microsecond resolution for these queries rather than nanosecond resolution. In discussion with the GLitch researchers, it seems likely that this reduction in precision is sufficient ? and since no WebGL developer ever complained about low resolution of Chrome's timer queries, there's no need to make any changes to the precision. However, Site Isolation is the long-term defense against Spectre, and it's >> close to being turned on in Chrome by default. At that point, the >> EXT_disjoint_timer_query WebGL extension will be turned back on in Chrome. >> > > This is gonna happen when? > I don't know exactly. Site Isolation is being rolled out now in Chrome. It's a large enough feature that if you watch the Chromium and Chrome blogs you'll definitely see the updates. > > >> Other browsers have mitigations in progress for Spectre, and once those >> land, useful features like EXT_disjoint_timer_query and SharedArrayBuffer >> will be re-enabled in those browsers, too. >> > > And this is gonna happen when? > I don't know, but all browsers have a vested interest in turning SharedArrayBuffer back on, in particular. -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat May 19 09:36:03 2018 From: kbr...@ (Ken Russell) Date: Sat, 19 May 2018 09:36:03 -0700 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: <919DFFC6-6587-45D6-B5B7-E0C954B440DA@callow.im> References: <919DFFC6-6587-45D6-B5B7-E0C954B440DA@callow.im> Message-ID: On Sat, May 19, 2018 at 3:36 AM Mark Callow wrote: > > > On May 19, 2018, at 10:08, Ken Russell wrote: > > act as a high-precision timer to carry out Spectre-like attacks > > > I thought the OS?s already had mitigations for Spectre. Why do the > browsers need additional ones? > Please see my reply to Florian. -Ken > > Regards > > -Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: