CIG, ACG, RCE .. I thought DEP and ASLR was supposed to have already cured RCE. Lets face it, when are they going to admit that the Windows memory model running on Intel hardware is defective. Lets see how long this comment stays up before modded into oblivion.
Strengthening the Microsoft Edge Sandbox
41–50 of 58 posts
Re: Strengthening the Microsoft Edge Sandbox
#42Earlier quoted context omitted.
"Crash Reporting, Metrics," These are not proprietary, actually. " Audio & Video Codecs," Neither is this, last i looked (but i haven't looked in a while).
The "proprietary" codec support is open source but disabled by default in a Chromium build unless you pass proprietary_codecs=1. Why? Patents. AFAIK, Google pays for a license from the patent holders to decode the codecs within Chrome, but not an open-ended license for anyone using the source code. This is not their fault and no different from how many Linux distros don't include MP3 decoding by default. (Incidentall…
Re: Strengthening the Microsoft Edge Sandbox
#43From the comments section: "I want to support MS, I’m a development partner. But I feel like you guys spend way too much time thinking about how to push intrusive ad’s into the OS and trying to get easy ad-based revenue from your browser: Talking very good security talk but not walking a very good security walk." The commenter also makes a comment about how Chrome the older browser was found to be much more secure th…
A Microsoft website requiring a Microsoft account to make comments? The horror!
Re: Strengthening the Microsoft Edge Sandbox
#44Earlier quoted context omitted.
UWP apps from the Windows Store already ban JIT compilation - at least for .NET apps. When .NET UWP applications are uploaded the store pre-compiles them on the server with .NET Native. The user only downloads and executes native code.
Not really, the .NET Native step is performed at build time, the packages the developer uploads to the Store are AOT-compiled
https://blogs.windows.com/buildingapps/2015/08/20/net-native...
One great feature of .NET Native is that the compiler is capable of being hosted in the cloud. When you build your Store package in Visual Studio, two packages are created – one .appxupload and one “test” .appx for sideloading. The .appxupload contains the MSIL binaries as well as an explicit reference to the version of the .NET Native toolchain your app consumes (referenced in the AppxManifest.xml). This package then goes to the Store and is compiled using the exact same version of the .NET Native toolchain. Since the compiler is cloud hosted, it can be iterated to fix bugs without you having to recompile your app locally.
Re: Strengthening the Microsoft Edge Sandbox
#45The earlier post on Code Integrity Guard and Arbitrary Code Guard is also interesting: https://blogs.windows.com/msedgedev/2017/02/23/mitigating-ar... Microsoft should apply these same restrictions to all UWP apps. Yes, that means banning JIT compilation, as Apple does on iOS. And desktop applications shouldn't be able to inject DLLs into UWP applications and system components.
Re: Strengthening the Microsoft Edge Sandbox
#46This blog post looks more like a damage control measure.
[1] http://www.tomshardware.com/news/pwn2own-2017-microsoft-edge...
Re: Strengthening the Microsoft Edge Sandbox
#47The earlier post on Code Integrity Guard and Arbitrary Code Guard is also interesting: https://blogs.windows.com/msedgedev/2017/02/23/mitigating-ar... Microsoft should apply these same restrictions to all UWP apps. Yes, that means banning JIT compilation, as Apple does on iOS. And desktop applications shouldn't be able to inject DLLs into UWP applications and system components.
Sure, it does sound interesting. Now what about all EMET mitigations that Microsoft is deprecating by saying Windows 10 is "secure enough" as is?
The EMET mitigations which are no longer supported have either been depreciated because of better ones (control flow guard) or are not terribly effective (EAF/EAF+, use of debug registers).
[1] https://theryuu.github.io/ifeo-mitigationoptions.txt
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...
Re: Strengthening the Microsoft Edge Sandbox
#48It's nice that they're investing in this. I just wish Edge didn't suck. I have tried using it as my primary browser and it's just not there. It crashes, trying to move tabs around is a pain, sometimes it just isn't performant.
One interesting thing is that Edge feels more sluggish compared to other browsers on a fast system, but performs well on a slow system compared to other browsers.
One huge annoyance with Edge is that it's spelling tool follows the OS language, hard to switch between languages. It is also not that good to give suggestions on mispelled words.
I use it on a slow netbook only because Opera has introduced a memory leak in the last few releases.
Unfortunately the browser experience is constantly degrading cross browsers, in lockstep with bloated single page apps.
Re: Strengthening the Microsoft Edge Sandbox
#49just checked my website visitor log. Only 1% people use Edge. It is not a surprise at all. The best way to secure a browser is just like what chrome and firefox do: open source it.
Your site may be self-selecting for people who don't use Edge somehow. Our session count on a site geared for the average person puts Edge closer to 13%: Chrome - 57.54% IE - 14.12% Edge - 12.88% Firefox - 9.30% Safari - 4.13% Other browsers make up the remainder
Re: Strengthening the Microsoft Edge Sandbox
#50Earlier quoted context omitted.
Chakra is open source. The rest is not. The IE/Edge layout engine has always been a source of infamous trickery. It would be good that they finally open source it.
As Chakra is part of Edge, then Edge is not fully closed source.