WebAssembly Target

classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

WebAssembly Target

Daniel Gaspary
Hi,

   Is there something planned in this matter for FPC?

   I was reading about the new Firefox making WebAssembly publicly available ("On Tuesday Firefox 52 became the first browser to support WebAssembly") [1] .

  Thanks.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Michael Van Canneyt


On Sat, 11 Mar 2017, Daniel Gaspary wrote:

> Hi,
>
>   Is there something planned in this matter for FPC?
>
>   I was reading about the new Firefox making WebAssembly publicly
> available ("On Tuesday Firefox 52 became the first browser to support
> WebAssembly
> <https://www.bleepingcomputer.com/news/software/mozilla-releases-firefox-52-the-first-browser-to-support-webassembly/>")
> [1] .

Karoly Balogh (Charlie/SGR) is working on this, and as far as I know has already some degree of
success. There is a bounty for initial webassembly support..

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Michael Schnell
On 12.03.2017 00:53, Michael Van Canneyt wrote:
>
> Karoly Balogh (Charlie/SGR) is working on this, and as far as I know
> has already some degree of
> success.
The Silverlight killer meets the C# killer :)

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Karoly Balogh (Charlie/SGR)
In reply to this post by Michael Van Canneyt
Hi,

On Sun, 12 Mar 2017, Michael Van Canneyt wrote:

> >   Is there something planned in this matter for FPC?
> >
> >   I was reading about the new Firefox making WebAssembly publicly
> > available ("On Tuesday Firefox 52 became the first browser to support
> > WebAssembly
> >
> <https://www.bleepingcomputer.com/news/software/mozilla-releases-firefox-52-the-first-browser-to-support-webassembly/>")
> > [1] .
>
> Karoly Balogh (Charlie/SGR) is working on this, and as far as I know has
> already some degree of success. There is a bounty for initial
> webassembly support..

Well, "degree of success" is relative, I have added WASM target to the
compiler so it compiles at least. I even made it output 1 single
instruction... :)

It's based largely on gutted JVM codegenerator code, although since
WebAssembly itself is still a moving target, many things are still
uncertain. There's also the problem, that despite it's name, WebAssembly
is not really an assembly format, but just a stack based bytecode (much
like JVM), and the official textual representation is not yet accepted,
plus the reference compiler LLVM outputs something entirely different to
the semi-official textual formats. And these official textual formats are
quite painful for the traditional structured compiler layers like FPC has.

But the LLVM-style output would be good, but it's undocumented, and as
they say it will go away, and LLVM will output the binary bytecode
directly... (Which is stupid IMO, but hey, a comittee decided, so it must
be right.)

Also, any "assembler" or toolchain is still in its infancy. (I made both
binaryen and wabt segfault in several funny ways already.) So I wouldn't
expect fast results with this whole target. But I will keep working on it
as time allows, so "eventually"... Of course if someone thinks he can
proceed faster and wants to jump in, it's very welcomed.

It's now committed to the webassembly branch in FPC SVN, the compiler
itself should build at least as "wasm" target, but don't expect much.

Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Michael Schnell
On 15.03.2017 17:58, Karoly Balogh (Charlie/SGR) wrote:
> Well, "degree of success" is relative, ...

Anyway, it's great to know that you are watching the proceedings
regarding WebAssembly, and already did some effort to get started !!!!

Just for enhancing your motivation :-) (of course this issue is more
like a project related to the Lazarus or mse designers, but you are
going to pave the way) :

IMHO this will be a great method to create (pure Pascal) applications
that are split in a server based part and a browser based part.

A very desirable way to do so would be to use a GUI based IDE (such as
Lazarus or mse) to create and test an application running locally, and
then define "split points" and use some kind of standard communication
protocol (i. e. rpc) library to split it up appropriately - just with
some definitions, without really writing any additional code.

While the perfect splitting points of course depend on the application
you are doing, one "simple" way would be to provide a server based
application with a browser based remote GUI. (This might usually be
called "Rich Internet Application".)

I know that mse features a tool called "ifi" to convert a normal "local"
application into a remote-controlled application with a remote GUI.
Here, the GUI part is an application created by mse/fpc, and able to
connect to any backend application done with "ifi". Building on top of
"ifi" it might be possible do have the "ifi-Browser" run in a
Web-Browser using WebAssembly. ms like a very viable goal to me.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Lukasz Sokol
In reply to this post by Karoly Balogh (Charlie/SGR)
Hi,

On 15/03/17 16:58, Karoly Balogh (Charlie/SGR) wrote:

> Hi,
>
> On Sun, 12 Mar 2017, Michael Van Canneyt wrote:
>
>>> Is there something planned in this matter for FPC?
>>>
>>> I was reading about the new Firefox making WebAssembly publicly
>>> available ("On Tuesday Firefox 52 became the first browser to
>>> support WebAssembly
>>>
>> <https://www.bleepingcomputer.com/news/software/mozilla-releases-firefox-52-the-first-browser-to-support-webassembly/>")
>>>
>>
[1] .

>>
>> Karoly Balogh (Charlie/SGR) is working on this, and as far as I
>> know has already some degree of success. There is a bounty for
>> initial webassembly support..
>
> Well, "degree of success" is relative, I have added WASM target to
> the compiler so it compiles at least. I even made it output 1 single
> instruction... :)
>
> It's based largely on gutted JVM codegenerator code, although since
> WebAssembly itself is still a moving target, many things are still
> uncertain. There's also the problem, that despite it's name,
> WebAssembly is not really an assembly format, but just a stack based
> bytecode (much like JVM), and the official textual representation is
> not yet accepted, plus the reference compiler LLVM outputs something
> entirely different to the semi-official textual formats. And these
> official textual formats are quite painful for the traditional
> structured compiler layers like FPC has.
>
> But the LLVM-style output would be good, but it's undocumented, and
> as they say it will go away, and LLVM will output the binary
> bytecode directly... (Which is stupid IMO, but hey, a comittee
> decided, so it must be right.)
>
> Also, any "assembler" or toolchain is still in its infancy. (I made
> both binaryen and wabt segfault in several funny ways already.) So I
> wouldn't expect fast results with this whole target. But I will keep
> working on it as time allows, so "eventually"... Of course if someone
> thinks he can proceed faster and wants to jump in, it's very
> welcomed.
>
> It's now committed to the webassembly branch in FPC SVN, the
> compiler itself should build at least as "wasm" target, but don't
> expect much.
>
> Charlie


Just because of curiosity: since Firefox  52 apparently boasts (to be the first browser with)
WebAssembly support -
- i know, i know, just because one vendor claims it, it doesn't mean anything yet -
-maybe something concrete could be derived from that fact? Even if it's just a
'how do they do it' style of fact.

(in the press release they say something about Emscripten being the reference implementation, if that helps)

-L.
(rs,ianad)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Lukasz Sokol
In reply to this post by Karoly Balogh (Charlie/SGR)
To all who received my previous message through mailing list:
please disregard. posted without reading thoroughly. apologies.

-L.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Graeme Geldenhuys-6
In reply to this post by Daniel Gaspary
On 2017-03-11 23:23, Daniel Gaspary wrote:
> WebAssembly
> <https://www.bleepingcomputer.com/news/software/mozilla-releases-firefox-52-the-first-browser-to-support-webassembly/>")

I love how they say multiple times in the video:

   "... and completely secure."


Umm, didn't they say the exact same thing about Java Applets, Flash,
Silverlight etc. :)  I guess time will tell, but if history is anything
to go buy, security issues *will* pop up.

Saying all that, I really respect Mozilla for what they have done
regarding the web. Firefox is the only browser I ever use.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Graeme Geldenhuys-6
In reply to this post by Karoly Balogh (Charlie/SGR)
On 2017-03-15 16:58, Karoly Balogh (Charlie/SGR) wrote:
> It's now committed to the webassembly branch in FPC SVN, the compiler
> itself should build at least as "wasm" target, but don't expect much.

Thanks for the update Charlie. Lets just say you are a brave man in my
eyes to tackle something like that. :) I wish you all the best with the
task at hand.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Graeme Geldenhuys-6
In reply to this post by Daniel Gaspary
On 2017-03-11 23:23, Daniel Gaspary wrote:
> I was reading about the new Firefox making WebAssembly publicly
> available ("On Tuesday Firefox 52 became the first browser to support
> WebAssembly


My system (FreeBSD) is compiling Firefox 52 in the background as we
speak. I’m very curious to see how the Zen Garden demo runs here.

  https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

I’ll be pleasantly surprised if it works - after all, so many browser
features often only work for OSX and Windows, even though the browser
and web is supposed to be “cross-platform”.  I’ll report back later. ;-)

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Graeme Geldenhuys-6
On 2017-03-16 10:56, Graeme Geldenhuys wrote:
> I’ll be pleasantly surprised if it works - after all, so many browser
> features often only work for OSX and Windows, even though the browser
> and web is supposed to be “cross-platform”.  I’ll report back later. ;-)


And I am pleasantly surprised! :)  That demo worked perfectly on my
system. Sound, animation, graphics all silky smooth. Impressive indeed.

Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Michael Schnell
In reply to this post by Graeme Geldenhuys-6
On 16.03.2017 11:46, Graeme Geldenhuys wrote:
>
> Umm, didn't they say the exact same thing about Java Applets,
No idea
> Flash,
While it's depreciated right now it did last for a long time and was
_very_ useful.
> Silverlight
While technically it did look nice, it was a single-company thingy and
doomed as this company did not succeed with taking over on the mobile
market.
> etc. :)
As Microsoft, Google, and Mozilla had been in the boat it looked a lot
more promising.
> I guess time will tell, but if history is anything
> to go buy, security issues *will* pop up.
Hopefully they did consider this in the textbook

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Karoly Balogh (Charlie/SGR)
In reply to this post by Graeme Geldenhuys-6
Hi,

On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:

> I love how they say multiple times in the video:
>
>    "... and completely secure."
>
> Umm, didn't they say the exact same thing about Java Applets, Flash,
> Silverlight etc. :)  I guess time will tell, but if history is anything
> to go buy, security issues *will* pop up.

Yes, but it is important to know there's a difference with Java Applets,
Flash and Silverlight - WebAssembly is not a plugin. It runs in the same
VM which runs everything Javascript in the browser. So the browser vendors
have full control on the code which runs there.

Also, WebAssembly is a descendant of asm.js, which was basically striped
down Javascript with some integer/pointer type tagging. As far as I know,
the main problem with JS from a computing point of view, that it handles
all numbers as floats for "simplicity", but with some code in other
languages, this can have real side effects (for example some integers
cannot be exactly expressed as floats, which means slight differences in
computation results accumulate over time, etc), and it's much slower on
most CPUs. This is why I'm a bit relucant to accept High Level language
translators to JS - there could be too many sideeffects hidden in any
algorithm, just because of this one thing.

This is the main problem asm.js, and now WebAssembly is addressing. It can
work with the same integer and float types the hardware underneath is
using, and can avoid all the float handling and various range/index etc
checks. This is what provides the performance part. And obvously a lot of
other "shortcuts" to work around JS language requirements, which another
language might not need.

And it fits in the process, how they gradually opened up the underlying
hardware to the browser. Another great example is WebGL, which is also a
very thin layer on top of the hardware, to skip through the billion "who
cares about that" CSS and JS canvas layers, and go directly to the GPU, to
get some decent performance...

So all in all, despite its problems, it's still the best effort to provide
some sane bytecode standard for the web. (If a web bytecode can be
anywhere near sane, that is.)

Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Benjamin Jan Alexander Rosseaux-2
The ECMAScript standard uses 64-bit double-precision floating point numbers, and a double-precision floating point value can represent absolute integer values up to of less than or equal to 2^53, without any loss of accuracy, since an IEEE 754 64 bit double-precision floating point number has a mantissa with a size of 52 bits (plus 1 bit implied).

On Thu, Mar 16, 2017 at 2:07 PM, Karoly Balogh (Charlie/SGR) <[hidden email]> wrote:
Hi,

On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:

> I love how they say multiple times in the video:
>
>    "... and completely secure."
>
> Umm, didn't they say the exact same thing about Java Applets, Flash,
> Silverlight etc. :)  I guess time will tell, but if history is anything
> to go buy, security issues *will* pop up.

Yes, but it is important to know there's a difference with Java Applets,
Flash and Silverlight - WebAssembly is not a plugin. It runs in the same
VM which runs everything Javascript in the browser. So the browser vendors
have full control on the code which runs there.

Also, WebAssembly is a descendant of asm.js, which was basically striped
down Javascript with some integer/pointer type tagging. As far as I know,
the main problem with JS from a computing point of view, that it handles
all numbers as floats for "simplicity", but with some code in other
languages, this can have real side effects (for example some integers
cannot be exactly expressed as floats, which means slight differences in
computation results accumulate over time, etc), and it's much slower on
most CPUs. This is why I'm a bit relucant to accept High Level language
translators to JS - there could be too many sideeffects hidden in any
algorithm, just because of this one thing.

This is the main problem asm.js, and now WebAssembly is addressing. It can
work with the same integer and float types the hardware underneath is
using, and can avoid all the float handling and various range/index etc
checks. This is what provides the performance part. And obvously a lot of
other "shortcuts" to work around JS language requirements, which another
language might not need.

And it fits in the process, how they gradually opened up the underlying
hardware to the browser. Another great example is WebGL, which is also a
very thin layer on top of the hardware, to skip through the billion "who
cares about that" CSS and JS canvas layers, and go directly to the GPU, to
get some decent performance...

So all in all, despite its problems, it's still the best effort to provide
some sane bytecode standard for the web. (If a web bytecode can be
anywhere near sane, that is.)

Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Mattias Gaertner
In reply to this post by Karoly Balogh (Charlie/SGR)
On Thu, 16 Mar 2017 14:07:51 +0100 (CET)
"Karoly Balogh (Charlie/SGR)" <[hidden email]> wrote:

>[...]
> Also, WebAssembly is a descendant of asm.js,

Maybe historically. Technically asm.js is higher lvl than webassembly.


> which was basically striped
> down Javascript with some integer/pointer type tagging. As far as I know,
> the main problem with JS from a computing point of view, that it handles
> all numbers as floats for "simplicity", but with some code in other
> languages, this can have real side effects (for example some integers
> cannot be exactly expressed as floats,

JS uses Double, which can express integers correctly from
-$10000000000000 to $fffffffffffff.
That should be enough for most browser programs, don't you think?


>[...]
> So all in all, despite its [webassembly] problems, it's still the best effort to provide
> some sane bytecode standard for the web. (If a web bytecode can be
> anywhere near sane, that is.)

+1

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Graeme Geldenhuys-6
In reply to this post by Karoly Balogh (Charlie/SGR)
On 2017-03-16 13:07, Karoly Balogh (Charlie/SGR) wrote:
> Yes, but it is important to know there's a difference with Java Applets,
> Flash and Silverlight - WebAssembly is not a plugin. It runs in the same
> VM which runs everything Javascript in the browser. So the browser vendors
> have full control on the code which runs there.

And this brings me to my next worry. As far as I understand, WebAssembly
is C (for now - other languages to follow) compiled into WebAssembly
bytecode. So now we have C code with all its pointer access, buffer
overflow issues etc running in the web browser space - at least Java
Applets were a lot safer in that regards, and Java Applets require
explicit signed executables and granted permission by the end-user (per
app, per domain etc). WebAssembly just runs - no questions asked.

Then we have the issue of code being obfuscated when compiled into
bytecode. So now it is even harder to detect malicious code.

The more I look at this, the more of a nightmare (security wise)
WebAssembly looks. Now we will have a cross-platform incubator for
malicious viruses, free to run in the web browser space, access to
low-level hardware, and all without explicit asking for or being granted
permission to run (ie: like Java Applets).

It seems I am not alone in thinking this way. Just read the comments
posted at the link listed in the first message of this thread.


Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Karoly Balogh (Charlie/SGR)
In reply to this post by Mattias Gaertner
Hi,

On Thu, 16 Mar 2017, Mattias Gaertner wrote:

> > which was basically striped down Javascript with some integer/pointer
> > type tagging. As far as I know, the main problem with JS from a
> > computing point of view, that it handles all numbers as floats for
> > "simplicity", but with some code in other languages, this can have
> > real side effects (for example some integers cannot be exactly
> > expressed as floats,
>
> JS uses Double, which can express integers correctly from
> -$10000000000000 to $fffffffffffff.
> That should be enough for most browser programs, don't you think?

No, to be honest, I don't think so. I already tracked down bugs in native
client side software caused by this, because of stupid NodeJS backends.
Because someone thought it will be "good enough". It wasn't. Not to
mention the cases I got "NaN" string as value in an integer field, but
that's just JS in general for fun.

Although NodeJS wasn't running in the browser, admittedly. But I think the
more complex apps you bring to the web, on top of JS, the more such issues
will appear, and the harder it will be to track it down.

Bottom line: It's not good enough if you want to guarantee the same
results as on other platforms, for all integer arithmetics with all
standard types, including 64bit ones. Which is a must for any self
respecting multiplatform compiler, IMO. (There are ways to do it
nevertheless even w/o WebAssembly, but with a clear performance hit.)

But I guess this is drifting away from the WebAssembly target itself, so
we should continue on fpc-other. :)

Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Karoly Balogh (Charlie/SGR)
In reply to this post by Graeme Geldenhuys-6
Hi,

On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:

> And this brings me to my next worry. As far as I understand, WebAssembly
> is C (for now - other languages to follow) compiled into WebAssembly
> bytecode. So now we have C code with all its pointer access, buffer
> overflow issues etc running in the web browser space - at least Java
> Applets were a lot safer in that regards, and Java Applets require
> explicit signed executables and granted permission by the end-user (per
> app, per domain etc). WebAssembly just runs - no questions asked.

Yes. Much like your average Javascript snipet. But even if it's compiled
from C (or Pascal, eventually... :P), it doesn't mean it can just poke
pointers whereever it feels like, there are several protection layers
between the bytecode and the native code, the JIT engine itself, the
browser, and the OS. Also, most browsers run most pages in isolation
anyway. I agree though that some kind of code signing would be benefical.

Also, the major problem with Java and other plugins security faults were,
that the organizations behind them moved with glacial speed, and sometimes
(Flash, Silverlight) they were even closed source, which made it
impossible for browser vendors to act quickly and patch things up. None of
this is true for WebAssembly.

> Then we have the issue of code being obfuscated when compiled into
> bytecode. So now it is even harder to detect malicious code.

There are already decompiler tools for WebAssembly, which translate the
bytecode back into the AST or even some JS-alike syntax. It's not that
much less human readable, than a deobfuscated JS code, which someone ran
through an obfuscator before, IMO.

> It seems I am not alone in thinking this way. Just read the comments
> posted at the link listed in the first message of this thread.

I think there's still a master switch to disable this in the browsers. I'm
sure there'll be tricky attacks, but these happen with normal JS anyway.
But I don't think it'll be such a disaster as people predict. (And I'm
usually quite pessimistic about such things.)

Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Graeme Geldenhuys-6
On 2017-03-16 14:45, Karoly Balogh (Charlie/SGR) wrote:
> I think there's still a master switch to disable this in the browsers.

So far Firefox 52 has none. Not in the Preferences, and not in
about:config either.

But yeah, it is early days, so hopefully security will tighten up in the
near future.

Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WebAssembly Target

Michael Van Canneyt


On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:

> On 2017-03-16 14:45, Karoly Balogh (Charlie/SGR) wrote:
>> I think there's still a master switch to disable this in the browsers.
>
> So far Firefox 52 has none. Not in the Preferences, and not in
> about:config either.
>
> But yeah, it is early days, so hopefully security will tighten up in the
> near future.

It should be opposite. Start with very tight security, and loosen up if
deemed safe...

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
1234
Loading...