Live data from Hacker News

Strengthening the Microsoft Edge Sandbox

blogs.windows.com

41–50 of 58 posts

Re: Strengthening the Microsoft Edge Sandbox

#41

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.

"Please don't bait other users by inviting them to downvote you or proclaim that you expect to get downvoted." https://news.ycombinator.com/newsguidelines.html

Re: Strengthening the Microsoft Edge Sandbox

#42
post #23

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

The last MP3 patent already expired a week ago actually.

Re: Strengthening the Microsoft Edge Sandbox

#43
post #35

From 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!

[deleted]

Re: Strengthening the Microsoft Edge Sandbox

#44
post #32
post #22

Earlier 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

You can .NET Native on your own machine for testing but the package uploaded to the store contains MSIL. The final .NET Native version is then compiled in the cloud.

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

#45

The 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?

Re: Strengthening the Microsoft Edge Sandbox

#47

The 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?

Most of them are just built into Windows now and are accessible through both the registry[1] and at runtime[2][3]. The latter requires recompiling with source code changes but the former can be applied to any application.

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

#48
post #11

It'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.

When Edge was released, it was quite awful. GUI itself didn't work properly when resizing etc. However the last few releases is has become usable.

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

#49
post #4

just 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

Maybe your site is visited from these "enterprise" computers where people are forced to use the default browser. Or you can assume the lack of tech knowledge about people who use IE/Edge by will.

Re: Strengthening the Microsoft Edge Sandbox

#50
post #38

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

Edge is closed source. You have no way of verifying the build of Chakra used is the same as the open source version. Well it might be possible to reproduce a build of Chakra to do a binary comparison but i am not aware of anyone doing it.
Post reply on HN