Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Houston, We Have a (Potential) Problem.......

Off-Topic discussions about science, technology, and non Debian specific topics.
Post Reply
Message
Author
millpond
Posts: 698
Joined: 2014-06-25 04:56

Houston, We Have a (Potential) Problem.......

#1 Post by millpond »

https://medium.com/mozilla-tech/why-web ... _name=6451


Hmmm.... Foreign *BINARY* code piped directly into our browsers.

Is it just me, or does anyone else see the enormous security hazard being presented to us????????

User avatar
acewiza
Posts: 357
Joined: 2013-05-28 12:38
Location: Out West

Re: Houston, We Have a (Potential) Problem.......

#2 Post by acewiza »

As with most anything of this nature, it depends alot on the implementation. But safely controlling active content being delivered on your browser is nothing new. ActiveX was the first big blunder in that arena back in the late 90s and probably the main reason for Internet Explorer's downfall.

We'll just have to wait and see.
Nobody would ever ask questions If everyone possessed encyclopedic knowledge of the man pages.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Houston, We Have a (Potential) Problem.......

#3 Post by bw123 »

Well, it's nothing new, the whole concept of "browser" is a misnomer, because these apps (browsers) that we run now are virtual operating sytems on their own. They do much more than what they should do IMO, which is render TEXT in a readable way.

HTML is dead. First they steal the words, then they steal the meaning.
resigned by AI ChatGPT

User avatar
Danielsan
Posts: 659
Joined: 2010-10-10 22:36
Has thanked: 5 times

Re: Houston, We Have a (Potential) Problem.......

#4 Post by Danielsan »

millpond wrote:https://medium.com/mozilla-tech/why-web ... _name=6451


Hmmm.... Foreign *BINARY* code piped directly into our browsers.

Is it just me, or does anyone else see the enormous security hazard being presented to us????????

I am not an expert but webassembly should be better than having npapi-plugins like Flash... Anyway maybe with the sandboxing system we should have some kind of protection, isn't it?

Magnusmaster
Posts: 168
Joined: 2010-06-12 22:50

Re: Houston, We Have a (Potential) Problem.......

#5 Post by Magnusmaster »

Danielsan wrote:
millpond wrote:https://medium.com/mozilla-tech/why-web ... _name=6451


Hmmm.... Foreign *BINARY* code piped directly into our browsers.

Is it just me, or does anyone else see the enormous security hazard being presented to us????????

I am not an expert but webassembly should be better than having npapi-plugins like Flash... Anyway maybe with the sandboxing system we should have some kind of protection, isn't it?
Yes, it should be better. It's a step backwards in the software freedom sense, but everybody minifies and obfuscates Javascript nowadays, so it's not that much different from decompiling JVM or .NET code.

millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: Houston, We Have a (Potential) Problem.......

#6 Post by millpond »

The thing is, I am able to turn JS *off* , default on most site (NoScript). I can pretty much nullify Flash by blocking Adobe and wiping its LSOs (Ghostery). ActiveX I have always disabled. Java itself has always been an option. And I would remove it from my system if I didn not need some utils based upon it.

The problem I see with *executable* bytecode streaming into the system is how to filer it. How do users decide precisely what access to the file system that the code will have. Typical access, such as the file downloading function is now done client side. I always try to turn off anything remotely resemblig the Win BITS function for background transfers. I even turn off any and every auto-update I can find.

I see this progression as simply ominous. Why does media need to to have direct access? Interactivity is already handled by databases on remote servers. In fact there is an enormous pressure to turn desktops into useless thin clients and use the cloud for all code execution. This is in fact necessary for the toy mobile devices. Just try putting Siri on a desktop....

A while back Chrome added the functionality for complete file system access to its browser. Firefox at the time held back. If indeed this new bytecode is only supposed to run in VM jails, then what is its purpose? If it does not interact with the host system, then it has no purpose being on it. Think of it this way: If Mozilla had control of your VBox install of Win10, why would it need to even be on your system? They could host it and provide remote access. M$ is already doing that with cloud services.

Personally, i have little use for streaming. If I want to view something I download it, with my youtube extensions or RTSP grabbers, scan it and take it from there. But streaming data should only be DATA and not accessible to the code section pointer.

Unfortunately the ultimate decisions are made by typical consumers who nothing about the enormous differences between CODE and DATA.

s2pido
Posts: 18
Joined: 2011-12-20 00:08
Has thanked: 1 time

Re: Houston, We Have a (Potential) Problem.......

#7 Post by s2pido »

For the time being, we have the option to disable WASM via firefox prefs
javascript.options.wasm = false

FWIW, firefox52-esr ships with this pref set to false.

I am not mentioning the above to be dismissive. I too am very mistrustful of the way-beyond-browsing inbuilt components and their capabilities. WASM though, in and of itself, I don't regard it as being especially worrisome. Right, wrong, or sideways... the inbuilt google-authored (FileOpen) filesystem browser is more worrisome. That smacks of NaCL -- native client -- as mentioned in millpond's post.

Looking ahead, I expect that by year's end we will notice quite a few "broken" sites if we run with wasm set disabled. Not just sites that will _need_ its functionality, but sites that serve content conditionally, based on user-agent. If "modern" browser version is detected, we will be presumptively served latest/greatest rather than a fallback version of content pages. I'm already noticing this. Example: when I visit a github project page and click "Graphs" then "Network", I'm presented with an eternal spinner image instead of a graph. I suspect this is probably due to my having disabled "features" like webworkers, websockets, etc. If I fire up old firefox v24 or TorBrowser 3.6.x and visit github... the graph renders just fine. I have not attempted to visit using ff52 while sending older versionID via spoofed request headers; doing so might be an interesting test.
If indeed this new bytecode is only supposed to run in VM jails, then what is its purpose
Predictably, the mass media articles are both sensationalizing and dumbing-down the presentation of "what is wasm". Its purpose is to be device-agnostic, platform-independent... and to provide a datastream which is more easily/quickly (by an order of magnitude, or more) processed by the app. Whether or not the component(s) processing wasm -encoded data is jailed, that's an just implementation detail.

User avatar
Danielsan
Posts: 659
Joined: 2010-10-10 22:36
Has thanked: 5 times

Re: Houston, We Have a (Potential) Problem.......

#8 Post by Danielsan »

From there: http://webassembly.org/
Safe
WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.

millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: Houston, We Have a (Potential) Problem.......

#9 Post by millpond »

Danielsan wrote:From there: http://webassembly.org/
Safe
WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.
Err... *WHOSE* sandbox???

A critical question.

Espcially since if the JS sandbox were safe there would be no reason for NoScript, and half the booger vendors would starve.

Exploits are a major business these days. A well positioned dev could make a large fortune by having his cousin Yigor selling off exploits for him.

Always remember: Mozilla CORPORATION.

User avatar
Danielsan
Posts: 659
Joined: 2010-10-10 22:36
Has thanked: 5 times

Re: Houston, We Have a (Potential) Problem.......

#10 Post by Danielsan »

millpond wrote:Always remember: Mozilla CORPORATION.
Actually before to be a corporation Mozilla is a non-profit foundation that leads the own corporation... Anyway I prefer Mozilla to Google...

Post Reply