I predict a rash of eventual FireEye, Cisco, and other vendor zero days in the near to mid future. If you are a nation state actor what better way to find zero days then to get the source code and find the bugs to exploit. This is the only thing that makes sense that would be worth the risk of attacking companies such as FireEye and Microsoft.
This is pretty silly. Source code for Cisco and Microsoft products has been circulating since the dawn of the Internet. Meanwhile, Microsoft has some of the most meticulously reverse engineered code on the planet. People who want to illicitly mint zero days out of Microsoft products already have the tools to do so.
And therefore, the "rash of exploits" has already happened and is still ongoing. I think it's just so inconvenient/scary to most people to understand how much is hacked/hackable that they refuse to believe it.
In my opinion the smooth operation of our infrastructure relies less on its security as it does on the discretion of the hackers that have already compromised it.
tplacek's point isn't that source is worse than disassembler output, it's that governments already have and have had access to source for a while (by design as Microsoft does provide source access to many customers, partners, etc). The tooling to dissemble built versions and craft exploits has also existed for a long while.
If source access enabled a rash of zero days, that point in time would have come long in the past.
Nation state hackers with Microsoft source code 'on my'.
Even commercial-wise I doubt it's much concern for making products. Source code doesn't equal a software business, every business knows that. Unless there's some unreleased AI source code sort of thing.
This is a genuine question (and a very tangential one that will hopefully not generate discontent): Has Microsoft ever explored the idea of open sourcing Windows? I don't know much about the propritary side of software but it seems like Microsoft has been pivoting toward SaaS, Azure, etc and with the inclusion of WSL it seems like Microsoft is less concerned about competition from other OS's in the traditional sense, or am I grossly underestimating how much licensing Windows earns Microsoft. Not advocating, I am just curious.
> Has Microsoft ever explored the idea of open sourcing Windows?
Good question. I have zero insight to the matter.
However, I have worked at a vendor when they decided to open source their code. It was a much smaller code base than what Windows probably is. It is quite a big effort. There can be all kind of dirty stuff in the code that you need to clean up. Either for legal reasons because you have purchased the code many years ago, but you are not allowed to publish it. So you need to dig out old contracts and have legal to check what was written when nobody even remotely thought that you could ever open source. And there might be engineering reasons that some code is so bad that you can just not show it.
Wasn't there this story some years ago that Microsoft had some odd DLL in Windows(?) that they couldn't even rebuild themselves anymore, because it required a compiler that has gone out of support years ago. I don't remember the details, but I am sure a code base with the history and size of Windows has some dark spots. Unless someone can tell me convincingly that Microsoft nowadays has a CI this that builds really everything from source in a fully reproducibly manner. I guess if they do they would have proudly reported at a software conference about it. I am not aware that they would have done that, but I am not actively following that field.
I think at this point in time it's either breaking backwards compatibility (definitely not desired by Microsoft's enginners) or breaking license agreements on the parts of code not owned by Microsoft (definitely not desired by Microsoft's lawyers).
You're only reading half of my comment. The other half points out that people who don't care about the law have had access to high-level Microsoft source code for as long as there has been an Internet. Microsoft's trees circulate just like everyone else's.
Companies like Microsoft and Cisco have made their source code available to governments for years, for whatever that is worth. The US government has full access to all the MS source code.
Why would this actually be true? If it’s easier to find in source, Microsoft probably would have found it. Ever single feature there goes through multiple security reviews and there is tons of code linting. All the penetration testers I have met don’t even bother looking at source. They just start trying things they think will flummox the software.
>They just start trying things they think will flummox the software.
This works...until you go against a target that's heard of fuzzing before and has the time and money to do it to their own code.
The really interesting Windows exploits require a combination of "throwing stuff that will flummox the software" and a deep level understanding of structures hidden to the average developer. Look at Yardin Shafir's really wonderful blog post about developing a kernel bug to a PoC - there's a lot of moving parts and security checks in modern windows, and having the source is a HUGE help.
I also found another hint about their findings in this PDF written by Yarden's co-researcher Alex Ionescu: https://www.usenix.org/system/files/woot20_slides_ionescu.pd.... One of the slides specifically mentions the use of fuzzing tools to find these issues.
If there are other, better links I don't know about, please kindly share. :)
the only interesting part of this whole debacle in my mind is that it highlights what was already fairly obvious. the security of a given environment is only as secure as its weakest link. the entire supply chain for every bit of code that is installed on a machine is a potential vector. if that code happens to run at privilege (like administration software) that vector is shorter. (and that's only if you're considering software) when you think about it, it's staggering.
i suspect we'll be seeing a lot more attention on reproducible and cryptographically secure build environments, similar to the gitian stuff in bitcoin land.
> the only interesting part of this whole debacle... security [...] is only as secure as its weakest link
I agree that it is a staggering debacle; I disagree that the weakest link is the only point of interest.
SolarWinds did not vet its build process and outputs; no antivirus, no government entity, no so-called intelligence agency, no mighty software corporation caught the compromise... for more than six months.
The set of characteristics of this compromise is notable and there are many sobering conclusions.
Also mentioned in this other, brief HN discussion.
> This means we do not rely on the secrecy of source code for the security of products, and our threat models assume that attackers have knowledge of source code. So viewing source code isn’t tied to elevation of risk
I don't know how much of this is true. Wouldn't it be helpful for bad actors to understand how Windows defenses work looking at the code thereby increasing the risk?
It is generally accepted in the security community that hiding source code does not provide security.
The principles for developing secure software were identified in the 1970s by Saltzer and Schroeder, and they're still true today. One of those principles is "open design", that is, don't depend on design secrecy for security of the system. Instead, depend on secrecy of things that are trivially changed (like private keys and passwords). Then, when the secret is exposed (or you think it might be), you quickly change all the secrets and there's no problem. One source of this paper: https://www.cs.virginia.edu/~evans/cs551/saltzer/
In the case of Windows, the source code is not really secret anyway. Most governments have continuous access to the source code, typically through the Microsoft Government Support Program (GSP) https://www.microsoft.com/en-us/securityengineering/gsp
Many businesses and universities also have access to Windows source code. You can see various programs to provide such access in different cases via https://www.microsoft.com/en-us/sharedsource/ In addition, Microsoft employs a huge number of employees who have access to its source code, and you can't really keep a secret long when a large number of people know the secret. Efforts like bribes, appeals to patriotism, etc. will eventually successfully get someone to reveal a secret if there's a large enough group, especially since it's relatively easy to identify who works for Microsoft or otherwise might have such access.
If that's not enough, Microsoft distributes executables, and disassembers & decompilers can provide enough information for static analysis anyway. So you could re-derive what you need to attack Windows if you needed the source code for some reason.
Anyone who depends on secrecy of code to provide security is in trouble. Typically the real reason to keep (some) code secret is to support certain proprietary business models and to meet certain legal obligations, and are not really about security.
Note that Microsoft understands this; they're quite clear in stating that the security of Windows does not depend on keeping its source code a secret.
It's not just governments - if you give them enough money they'll send you the source, and all the tools required to build it. Device manufacturers in particular need this - you think SeaGate is using the online windows docs when they write SSD drivers?
(The point is correct, but SSDs are probably a bad example: it is very standardised whether it is in consumer or enterprise space. Maybe nVidia and AMD with regards to graphics card would be a better example?)
Open design is basically a generalization of Kerckhoffs's principle.
Kerckhoffs's principle is usually stated as "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." Note that Kerckhoffs's principle only refers to cryptosystems. The open design principle is a generalization that applies to all systems, whether or not they are cryptosystems.
> It is generally accepted in the security community that hiding source code does not provide security
Yes. But with not enough eyes carefully reviewing the code security vulnerabilities will remain also in open source code. And once a bad actor finds it it will be easier to implement an exploit.
It's not opening the source that makes the software more secure. It's enough reviewers or white hats looking at the code. Security vulnerabilities in Linux (both kernel and user space) show that regularly.
Of course with closed source your external reviewers are zero, so that's not the solution.
"It's not opening the source that makes the software more secure. It's enough reviewers or white hats looking at the code. Security vulnerabilities in Linux (both kernel and user space) show that regularly."
Thank you for that additional point, it's worth being said and helps us model the closed source alternative.
Microsoft shares source code with lots of partners. It would be asinine to admit that source code leaks, accidental or otherwise, would compromise their security. If they did that, it would create headaches for their massive contracts where source sharing is a prerequisite. So they toe the party line and say no, in fact, source code leaks do not compromise security.
Many years ago when I worked at Microsoft I asked for the source code to Solitaire. A few days later I received a stack of CD-ROMs with the entire source code of Windows NT (4.0 maybe).
I just thought of something. At the time blank CD-R's were about $15 each and the fastest burners at the time were 2x burners. I'm sorry I wasted so much of time the person who burned these and the cost of the media!
NT 4 code was already leaked almost full back in 2004. You can still find it with relative ease if you know where to look, or search for certain keywords in the code.
UX, speed, simplicity, lightness. Applications ran without talking to the internet, asking if it's ok to run it, telling me it's probably unsafe to run it, telling me I need to update for security reason, telling me I should play candy crush, letting me search my files without adding recommended noise somewhat supposed to be relevant to what I did 3 days ago. I could go on. I just want to stare at a blue flat colour knowing tomorrow it will be just the same. /s
Depending on the "Distro" and compile options/build flags/included libraries MATE is as fast and light, since at least 6 years, actually. I think the first distribution which showed that to a general audience was LMDE a.k.a. Linux Mint - Debian Edition.
The source code is already out there, so any compromises have already been found and exploited. Leaking it further won't create more vulnerabilities, and more likely will cause existing vulnerabilities to be found by white hats
I'd imagine the answer is yes, viewing the source code would increase the risk relative to an attacker that did not have access to the source code, but the statement is saying that whatever risk assessment Microsoft does already assumes attackers have knowledge of source code. EG, they are conservative and do not rely on source code secrecy when making any security evaluations.
For what it's worth I'm familiar with Microsoft's security team (both for their infrastructure and code) first hand and they are some of the most competent individuals I've ever had the pleasure to know.
I'm personally not a huge fan of Windows, and it definitely has flaws but the amount of considerations taken into account, and the speed with which issues are identified and repaired in a code base of that size, especially while maintaining a disgusting amount of backwards compatibility is crazy impressive.
That aside, having access to the source code does make finding issues easier. It sounds like that knowledge is assumed in their risk assessments which would make that a fair statement.
This puts them on the same level of Linux - when doing Linux threat assessment we can count the attacker has the source code for everything.
In any case, it's silly to think otherwise. It's always safer to assume everyone that we wouldn't want to know something already knows that, whatever it is.
It's the same assessment level but may or may not be the same exposure level.
While Microsoft does not assume that attackers haven't seen the source code, we cannot say how many people who are capable of spotting security issues have reviewed the code.
That being said, it's worth also saying it's a hard comparison to make overall; it's possible there are important parts of the Linux code base that have in fact had less eyes on them than Microsoft has had on theirs; without numbers it's hard to be certain.
Whether or not it would be helpful to attackers, this is still the correct threat model for Microsoft to operate with. Sufficiently motivated attackers can reverse anything they distribute publicly anyway.
Nobody seems to mention an important aspect: megacorps like Microsoft, Amazon, Google or Oracle hire thousands of engineers each year. It's not particularly hard for a bad actor to get an agent hired into their target and gain access, for nefarious purposes, in the legit way.
windows sandboxing btw. is barely at use. every program can basically read everything in user profiles, that is imo the same on linux.
only windows applications that do not run in full trust mode, like store apps won't do that. and even without store apps you can use something like msix or app-v to package your apps in a "small" sandbox, but you can breakout from the sandbox via runFullTrust
Regardless of what mitigations Windows has in place, when you run closed source programs, without competent security auditing you never know what it's doing. Once you click run your precious user files are always in jeopardy. Even with GUI isolation, a point of contention in the article, it's trivial with a few bytes of code to implement some other form of keylogging which the user will run without much thought because hey, it's Windows, it's "secure" while having no real idea what the program is doing in the background. To reiterate, any execution of closed programs will result in execution of closed processes.
With the Windows model, you don't check your guests at the door. You can't search all guests so you assume all guests are hostile and with it you're always taxed with playing security theater which can not only be expensive in terms of hardware resources but mental resources as well as losing more control over your own environment. Because you let unaudited people in your home, before long you have to lock down most parts of it, even from yourself. In gaining control you've lost control because you don't control for openness in the first place. For the few binaries I run on Linux I sandbox them in a VM anyway. But different models, different hosts, each has their weaknesses.
Most importantly, how do you check the binary you are running is actually built from the source code the vendor says it is if the source is not open ?
They might sincerely thing so, not knowing they were targeted and now all the binaries they ship are also containing a payload added by the attacker.
With open source software and especially the Linux distro model where one set of people writes the software and another buikds it from source and integrates it is much harder if not impossible to pull off such an attack affecting all users of a piece of software.
Linux isn't any more secure or safer than a lock on my door will prevent someone from just breaking the window. Hackers do in fact target linux machines, just not average desktop users. They typically go after servers since they run basically everything. And chances are, standard linux users know what they're doing so a ransomware attack isn't really much to frighten a linux user as much as it is to just piss them off but still recover in like 24 hours or less.
A lot of times stuff like undocumented APIs and bugs are easier to find taking apart the binary anyway. Goofy stuff tends to be obfuscated in source as engineers add so much abstraction around the goofy pieces, but it's clear in the final binary.
Yeah, right. Everything is so open about all MS binaries that they don't even need to be closed source! It takes a lot of time and effort to find these poking the binaries, and then experimenting them. The source code makes this task obviously easy.
That’s not nearly comparable to commented source code repo. “Decompiling” leaves you with a barely readable facsimile of the original code, and most likely won’t even compile again.
The true value in source code at this level are the comments and symbols. Microsoft provides most ofthe symbols, the comments you can’t recover from a binary.
Agreed. They’re using that argument to frame their breach as a win. The reality is that open source is easier to reverse engineer and find vulnerabilities in because you have the source. Our researchers do this every day and closed source makes that harder. Advocacy debates in favor of open source have muddied this conversation - but that is the cold hard reality.
Now that an adversary has MS’s source code, it is indeed easier for them to do vulnerability research. So this is a net loss for MSs overall security posture, not a win.
Practically speaking, being a bad guy with access to Microsoft source code for a short time has very little impact or real-world relevance. They do thousands of updates a day, the build processes are lengthy and poorly documented, the overall direction of the code is subject to myriad political groups inside the company, and they're making massive improvements in multiple branches that will render that snapshot irrelevant within minutes.
The "best" market for any such code would be... what... China? Other than the possibility of figuring out potential hacks who could make use of the code in in its sheer mass? By the time you figure out something clever your version of the code is hopelessly out of date.
Vulnerabilities have lurked for years and even decades in the Windows codebase. I'd not be so certain that having a snapshot today wouldn't help you find exploits for a long time.
Yea, how long was OpenSSL’s heartbleed an issue? And that was open source that was supposed to have millions of eyeballs on it. I agree, I don’t really buy that MS rewriting everything hourly and there is nothing to get from source.
Very curious as to the details they aren't releasing.
If you read between the lines they are saying that accounts were compromised, but not through token stealing, which means the attackers got the passwords to the accounts, and likely skirted MFA requirements because they were already inside, or there were none.
While there are many avenues to steal passwords once you have the foothold the attackers did, it would be interesting to know the details as to how these particular accounts were compromised.
With a large and sophisticated Corp like Microsoft, wouldn’t they have a Zero Trust kind of security model which means certs and MFA regardless of location, behavior, etc.
I've worked in big companies like Microsoft, so can only comment from that perspective. Due to their size, they often do not have MFA regardless of location. Many didn't even use MFA. Most have been moving there, but it was long, multi-year projects. So I wouldn't be surprised if Microsoft doesn't have MFA for everything.
MSFT employee here: I don't know of an internal service that I use that doesn't have MFA.
I am not going to make a broad statement saying they don't exist, I'm just saying I haven't found one yet. It's really annoying because I rarely have my phone on me when I'm at home so I have to go track it down. I'd be so happy if they let me use a yubikey :(
What I am saying is that these credentials can be stolen from MITM attacks, log files stored on random servers, or even basic mistakes like literally writing the password where other people can see it.
Knowing what kind of operational mistakes Microsoft made that led to account compromises would help others from becoming victim to similar attacks.
If they were the ones responsible for leaking the XP source not long ago, then they deserve much thanks from the underground retrocomputing and software preservation community --- MS would've likely never opened that source themselves. In the same way that those who leak schematics and service information to enable third-party repair are also to be commended. "An enemy of an enemy is a friend."
Though this is bad for Microsoft, does it make the situation substantially worse from a security perspective? Assuming they’re following good practices like not storing access keys, passwords, etc, in their source control system(s), this seems like more of an IP protection issue.
I could be wrong about that, though, and I’d be curious to learn and understand more.
If SolarWinds was compromised and the attackers could use that as a backdoor into Microsoft's datacenter, the problem isn't really about protecting source code. The problem is whether attackers were able to leverage that into stealing data from or sabotaging Microsoft customers. After all, that customer list contains many parts of the US government and civilian infrastructure in general, plus major international corporations.
There are two aspects to the comment though:
1. Did they access services/data as part of this?
2. Can/did they use what they got to impact customers/gain access to customer data.
The comment in the article speaks to #1. And of course, we have to take that with a grain of salt. I doubt any company impacted by this would be fully honest if there was a customer breach. Regardless, you also can't prove a negative. So all they can really say is what they did. Which doesn't mean services/data weren't compromised. Given the size of Microsoft, I find it hard to believe that every service running there has the logs/audit trail to know whether they were inappropriately accessed.
But I took the OPs comment to be focused on #2 as well. There is a very real possibility that having access to the source code could help the attackers attack customers. Having access to the source code can help in locating vulnerabilities that allow future attacks against customers/services.
Please note: the source code of Windows 10 can be requested if you are a large enterprise or a government already (as long as you agree that you won't release it). The only possible significant difference here is the lag - you can read the source code of the internal builds, whereas you can only access the corresponding source code for stable builds officially. So, if you are a government, you can actually request it for a legitimate purpose and pass it into the other side of that government if you want to.
The "risk" mentioned in the quote a few comments up, and in the context of the post by MSRC, isn't about the risk of leaking Microsoft IP. It's about the risk that Microsoft customers might have been affected. Whether or not MSRC found evidence of a breach of customer accounts/data is a related but separate question.
Please note: the source code of Windows 10 can be requested if you are a large enterprise or a government already (as long as you agree that you won't release it). The only possible significant difference here is the lag - you can read the source code of the internal builds, whereas you can only access the corresponding source code for stable builds officially. So, if you are a government, you can actually request it for a legitimate purpose and pass it into the other side of that government if you really want to.
Every state actor already has MS source code, because Microsoft is giving them access (including china).
And this doesn't look like something bored 15 year old would pull, So I doubt it was to access their source.
If I had to guess, they were either trying to find something specific, about one of MS's customers (some gov org) or the target was Azure. Lots of corps keep a lot of data there.
Right. One place I worked would probably benefit from attackers getting access to the source code. It would cost them weeks of productivity trying to figure it out.
> Despite the above, the quality of the code is generally excellent. Modules are small, and procedures generally fit on a single screen. The commenting is very detailed about intentions, but doesn't fall into "add one to i" redundancy.
yup, similar sentiments are always given whenever MS code leaks, whether the MS DOS 6 that MS officially released, or the more recent Windows XP leak. Nobody who looked into it claimed any of the code was "messy" or anything but excellent engineering.
Is the source code buildable, or is it mainly for documentation purposes? I’m guessing the build system and tool chains required for building windows are massively complex. Are these distributed with the windows source code as well?
Also I’m guessing that there are a lot of other proprietary vendor-supplied pieces that get built with Windows. What happens if these are not available?
Internal builds barely work with millions of dollars and man power invested. I can’t imagine anyone else outside of Msft being able to build Windows lol
I don't know if I missed it in the article, but did they say anything explicit about write access? Seeing the source may give access to new zero days, but it would be much worse if the attackers were able to seed a large number of commits into the code that introduce subtle vulnerabilities.
Sounds like the attackers did not have write access. From the original blog post:
> The account did not have permissions to modify any code or engineering systems and our investigation further confirmed no changes were made. These accounts were investigated and remediated.
I would also hope that direct commits don’t go immediately to a production system without some sort of review. At my workplace we have branch protections for all “main” branches that would result in a deployment. At least one other person has to review changes and all of our automated checks have to pass before anything can even get close to running through a deployment pipeline.
Whew, that's good to hear. I assume anyone trying to inject malicious code is going to try to do so in a way that doesn't go through normal code review channels.
True. However, hopefully that’s being mitigated through things like not allowing authors to review their own commits, not using the same accounts to push code changes and do deployments (i.e. having a read-only account for deployments), etc.
However, if it were an admin account that were breached that would definitely make it possible to circumvent any number of protections in place.
At least for the projects I work with at Microsoft, nearly no user accounts have direct write access to source repos. Checkins are done by a service account only after a pull request has successfully been built and run tests, and has been signed off on by appropriate users -- e.g. I can't sign off on my own PR.
EDIT: Sorry, somehow I missed the reply by thatsamonad or I would have replied to it instead of its parent.
I meam it sounds like a good security mesuare but also like a pain to work with? I have recurring nightmare that management realize that submits can be blocked if they generate CI warnings and there will be no warnings anymore.
Tools that generate warnings can be configured to only do so on new or modified code. We do the same for our code. It can be a difficult, but ultimately some codebases require it.
This reminds me of The Linux Backdoor Attempt of 2003[0], when someone (maybe a three-letter agency, maybe not) was able to insert a subtle bug in the Linux kernel.
We can look at why it was caught (people paying attention to commits, policy of requiring commits to be properly signed off), and conclude that it would be difficult to add anything without being caught. Or, put differently, if you believe that bad actors can get around that level of precautions, you might as well give up because everything else would be equally compromised.
> But some people didn’t like BitKeeper, so a second copy of the source code was kept so that developers could get the code via another code system called CVS. The CVS copy of the code was a direct clone of the primary BitKeeper copy.
Reading this, the question that immediately pops in my head is:
Could a hack like this one go undetected for so long in a widely used free/open-source project developed in the open, such as the Linux kernel?
While I have no doubt that something like this could happen to the Linux kernel source code (because security is Capital-H Hard), my perception is that something like this is less likely to happen to the Linux kernel -- and, were it to happen, it would likely be detected sooner, due to the inherent transparency of widely used open-source code.
This hack wasn't really a failure of code construction but a failure of institutional practices. The same thing could have happened if SolarWinds had a garbagy sys admin tool that happened to also be open source but still otherwise followed the procedures of SolarWinds.
Giant bureaucracies have a bunch of tasks they need to accomplish. Giant bureaucracies hire poorly trained people to accomplish those tasks and buy software to aid it's those people in accomplishing those tasks. The software is sold "by the feature" so it is colloquially "garbage" that is itself produced as cheaply as necessary to achieve these features. Naturally, such garbage is constantly updated and all these giant bureaucracies are sieves with these updates running through them. Sure, if these bureaucracies hired competent people, downloaded open source tools, tested the tools themselves and essentially had their own quality control in-house, this might not have happened. But that wouldn't be the out-sourcing-based, cut costs and skills to the bone, neoliberal paradigm that's near and dear to the high level managers' heart, now would it?
Now, you would think that an event like this would create a realization "what we do is too important for outsourcing, for bargain-basement, neoliberal style operations". But the Office of Personnel Management hack [1] was what should have created this realization and didn't.
The exploit in this case had access to the build (and presumably signing) system. That wouldn't have helped. The protection against this would have been the comparatively new efforts at reproducible builds. A modified binary, in theory, could be detected by current Fedora and Ubuntu releases (not sure about Debian or other distros). I don't think we've had an attack in practice though.
On the other hand, Debian broke OpenSSL generation and didn't detect it for almost 2 years. That appears to have been a legitimate mistake, but it is quite conceivable that a malicious actor gets a change merged that contains a backdoor that looks like an innocent mistake and goes undetected for a long time.
I suspect adding bugdoors to Linux is far easier than it is than for Windows, but there are already so many bugs it's easier and more viable to just look for them than to try to insert them.
Why would you need to back door Linux when you can find a company like Solarwinds that is already in most networks with greater access to the network as a whole than a Linux server.
Considering how long bugs can go unfixed and undetected even in large open source projects, I think it can totally happen. Just create a backdoor that looks like an honest mistake, submit it in a PR that adds some feature or fix, and exploit it at will as people update. Heartbleed took over 2 years to find and fix.
As others (and Microsoft) mentioned, it was read only access. The only points of concern here would be if that statement somehow was not true and they were able to add undetected changes, or if their security audit process was severely lacking.
But yeah, to your point - being able to read and analyze the Linux kernel source is considered a feature, not a liability :)
I think you're connecting two points he made that weren't connected.
On the one hand, open source projects make for an environment where bad actors could propose changes to the software that include these bug/backdoors. The benefit to the open source arena is that these changes can easily be analyzed and tested.
In Microsoft's case, the source being visible but not editable is still a real risk (assuming the bad actor is able to extract the data they're viewing for further analysis), because they can use the source to determine avenues for attack.
The fact that is was read-only does help ensure that no new attack vectors were created, but it still increases the chance of new attack vectors being found/used in the future.
I do security research and bug bounties on side sometimes and had read/write access to a couple of large open source projects in the past, incl. being able to impersonate employees from well known companies that work on open source stuff.
Most common issue was access tokens found in public places.
Would be interesting to know what happens when code is updated - which I obviously wouldn't do. Wonder how long it would take until caught.
Since open source projects probably dont do "red teaming" (to use a fancy buzz word) I wonder how they could practice this?
A kernel breach happened on iirc an SVN server in 2013 but was detected almost immediately.
If I were a nation state I wouldn’t try to poison mainline kernel - there would be far easier sources along the stack for both local and remote attacks which would more easily go unnoticed. Tools that come to mind are systemd, openssh, http/ftp services, GNU tools and common non-gnu shell utilities. Failing that, distribution level kernels would be my next bet purely because any commits would be less scrutinised.
The attack surface is so large, I'm surprised we're not dealing with backdoors much more often (not just nation states, but also commercial hacker groups).
Yeah, a tweet said this is the beginning of a decade of those sorts of attacks which I agree with. It’ll start with pip, npm, etc, then move to bigger targets.
For that reason I’ve moved away from those managers and stuff like react (I trust facebook but dependency trees are huge) - the worst part is you can’t not patch, but you might be doomed by any upgrade.
I think eventually it’ll snuff out innovation in medium sized businesses and government - large businesses can afford the cost of manual review and startups will ignore the risk, but middle-tier will be screwed.
I’d love to see a crowdsourced review model, but I just don’t think it can be viable without getting abused.
There's a very old homily that applies exactly to this flaming debacle: don't put all your eggs in one basket.
WP says that SolarWinds "had about 300,000 customers as of December 2020, including nearly all Fortune 500 companies and numerous federal agencies."
Everyone who thought that was a good idea, for whatever reasons - given the history of security - obviously screwed up badly. When -so many people- go -so wrong-, the problem is clearly bigger than the loss of 'too many secrets'.
I would love to have access to NT source code, hopefully it leaks. The most recent leaks are way out of date and have basically been exhausted of their usefulness.
Of course, it absolutely HAS to be a nation-state. There's just no way anybody not being paid millions of dollars could possibly break their ironclad blah blah whatever you get it
Many comment threads here discussing the (in)ability of an attacker to modify the source-code that Microsoft builds from, or use it to more easily discover vulnerabilities.
What I've not seen anyone discuss is the potential for an attacker to take the source-code of a single Windows core component (a system DLL for example), add in a backdoor, build it and then distribute the binary via a compromise such as the SolarWinds update mechanism.
In other words, insert a modified core Windows DLL into some other popular Windows driver or application package updater published and signed via a 'trusted' channel other than Microsoft itself.
Not all of them. msimg32.dll has no certificate and many system processes attempt to load that. There are more dlls in system32 if you look. Neither does Wldap32.dll, which gets loaded into lsass and is part of the knowndlls...
I wonder if incidents like this will push MS towards open sourcing windows.
IDK what their revenue looks like, but I'm guessing that selling the OS isn't as front and center as it used to be (from the way they are changing in terms of supporting things like linux).
Even if they keep a pretty tight license around the source, releasing it to the public would earn a lot of good will while potentially finding and fixing security problems.
I don't think Windows will be open-sourced precisely because it's not as important as it used to be. It'd be a ton of work to root out vendor code incompatible with OSS licensing, remove internal dependencies etc. That's not worth it unless we have big plans for Windows to stay relevant, which I have no knowledge of but suspect that we don't.
Probably we'll see the most relevant pieces be opened up, like the driver model awhile back.
So while not the whole thing, seems like they could open source core pieces like the kernel. That will probably take some code reorg to achieve though so maybe that's why it'll never happen. Last I heard on HN, windows was pretty much just a giant repo with everything in it. That'd have to change for them to release core pieces (If it hasn't already).
As far as community trust goes, MS has been killing it for the last several years. They've done a 180 in terms of being good software citizens. I'm really hopeful that core pieces (such as the kernel) end up hitting the public eye.
"...Versions of Internet Explorer before version 7 stated "Based on NCSA Mosaic" in the About box. Internet Explorer 7 was audited by Microsoft to ensure that it contained no Mosaic code,[39] and thus no longer credits Spyglass or Mosaic."
I've heard that one of the major obstacles to open sourcing Windows is that a lot of code in the Windows codebase may be proprietary and owned by companies other than Microsoft.
Apparently its also an obstacle for many other closed source programs when it comes to considering a transition to open source
I always thought the reason they charged for their OS was due to their anti-trust lawsuit so as to state that they weren't actively trying to dominate the market or something along those lines? Also, OEM operating systems are kind of circumventing that.
The reason I always heard was that there’s tons of binary blobs in Windows they bought from vendors that’d have to be reimplemented (the zip library is the most notable example).
>I wonder if incidents like this will push MS towards open sourcing windows.
What I am thinking as well. Unimaginable if it was 10 years ago, but modern Microsoft seems to be taking a different approach. And Apple desperately need some competition to keep Tim Cook honest.
On the whole this does not affect my perception of Microsoft. In fact it probably tilts it in their favor. They were able to conduct a thorough investigation and figure out the attackers had access to the source. The reality is that while it makes future attacks easier it has already been taken into account for a large majority of risk assessments.
People trash Microsoft a lot but some of the people there are the best in their respective fields.
So true. There’s this funny line in one of Paul Graham’s essays where he says something like “making the wrong technology decision can doom your business - like choosing Windows in the 90s” I got such a kick out of that because I worked for CyberTrader in the 90s; we built our whole platform around Windows and wiped the floor with our competitors. We ended up the top day trading company in the US and were acquired by Charles Schwab for just shy of $500m. But at the time, you pit Windows NT with IOCP against anything else and it was game over in the low latency trading space.
Reading the old NT debugging blogs and Raymond Chan’s stuff was very eye-opening. Microsoft has incredibly talented engineers ready to help Solve Problems, not just toss you the source code and wish you luck.
That does not happen, even with the beta grade Linux version on Arch (as I run it)
You may have a rubbish internet connection. If you are using a VPN with a slow internet connection, investigate a split tunnel. Teams traffic involves only three IP ranges so it is easy to split out and route direct to shave a fair bit of latency.
Other issues will require more investigation but they are local to you.
I'm only 50 and been messing around with them for about 40 years.
My point was that even on a precariously supported platform (my Arch Linux computers), the software works fine - ie as proscribed. MS Teams is used by a vast number of people and has a habit of working OK for them.
Same freezing problem, company issued laptop 100mbit internet connection. Same feedback from hundreds of people. Half a gigabyte RAM or more even when Teams inactive. Other softwares have solved this problem so I will agree with the opinion that Teams team should put their act together. I will postpone prioritizing Teams ips to the routers.
It might depending on platform. On my windows laptop, I can videoconference without GPU accelleration. Windows 10 has an impressive software fallback for gpu rendering (WARP), they could be using that.
Agree if your computer resources are being utilized over 70 percent teams becomes a nightmare. They could have written it in c++ in the same amount of time and had that thing running smoothly.
> Rewriting it in C++ to magically solve problems. Good job, engineer.
Well it's a lot easier to make an app perform well in C++ than electron.
They should at least have for the VS Code team to help. That's one of the best performing Electron apps, it's strange MS never adopted those practices company wide.
Hmm when I compare the two in terms of CPU / Memory usage and speed, Teams is one of the worst performing electron apps on my system, and VS Code one of the best. I don't think this is just network related (and I have a 600/600 connection anyway).
Either way, even if this was the reason it would prove that Electron is not a good fit for an app like this.
The issue with teams is performance. Teams is a relatively simple application. C++ is extremely common and well known, would have been a better tool for the job. That’s called engineering when you actually care about the quality of the product.
This still holds for C# and the .NET ecosystem today, especially amongst SV startups. If only they knew how much faster and better they could be building instead of avoiding it for ideological reasons.
"I don't trust, based on their past behaviour, that these people will pick a path that is consistent with mine" is a perfectly rational reason based on ideology.
Ok, so what path is interfering with the ability to build faster and better exactly?
Looking at their current behavior from open-source to VSCode to .NET 5 shows that it's a more compelling choice today than ever before. This is actually rational.
Only since 2016, and it wasn't really usable until a couple of years ago. Most third-party .Net libraries still assume you're in a Windows world. The reality is that .Net is very competitive in terms of development speed if you deploy on Windows; elsewhere you'll likely have to figure out stuff and suffer from being on a second-class platform.
IMHO selling .Net to unix devs is a bit like trying to sell icecream in Siberia.
> The reality is that .Net is very competitive in terms of development speed if you deploy on Windows; elsewhere you'll likely have to figure out stuff and suffer from being on a second-class platform.
That's nowhere near reality, .NET 5 (FKA .NET Core) has flawless first-class support for Linux, the whole deployment experience is even better on Linux since you have access to the entire Linux tools + ecosystem. Which I've been deploying to for years, I still develop on Windows but only ever deploy our .NET (Core) Apps to Linux (since the same App runs flawlessly on Windows + Linux).
The Windows-only .NET Framework (excl Mono) is now considered legacy, it's continually supported but all new development + features are being invested in the .NET 5+ cross-platform runtime which is now what ".NET" refers to.
This fear is unfounded, the primary value proposition of .NET (FKA .NET Core) is that it's a high-performance cross-platform runtime that has first-class support for Linux.
It's been designed to be "cloud-ready" from the start where it's adopted a high-performance core with a leaner, modular runtime that supports side-by-side installations since Microsoft wants it to run well in the Cloud of which all cloud providers (inc. Azure) predominantly deploy to Linux VMs, whose trend will continue to dominate.
You can view the supported Linux distributions on their installation page which includes Linux binaries for x64, Arm32 + Arm64 including package managers for its supported Linux distributions (Alpine,CentOS,Debian,Fedora,openSUSE,RHEL,SLES,Ubuntu) [1]. As well as maintaining multiple Docker configurations for popular Distros [2].
With Linux now being a supported platform means if you have run into an issue you can report it where their full-time resources will resolve it. The old days of using .NET to push Windows is gone, the future is the cloud and Azure doesn't care if you run Linux or Windows VMs, it's all the same to them, they're still collecting rent for usage of their servers by the hour.
Azure runs more Linux than Windows, including its own services. Linux and mobile are first-class platforms. Everything is compatible unless you specifically use Windows-only APIs. Do you have any examples of 3rd-party libraries that aren't supported?
.NET Core (now .NET 5) has changed the entire ecosystem and has been production-ready for years, and is even making cutting-edge advancements like Blazor which offers the first real alternative to Javascript on the frontend. The reality is that .NET is a top choice for both development speed and application performance across all platforms today.
SQL Server isn't part of .NET, and no different than using any other proprietary database. I'm not sure what you mean by 3rd-parties but .NET works with all the major open-source projects so you're not missing anything.
Funny enough in 'founders at work' it sheds light on the early days of paypal. It seems to point towards one of the reasons Elon got fired as CEO of Paypal is because the broader team disagreed with Elon about whether to build around windows or linux and Elon argued that there was more tooling in windows at the time.
I worked on a big distributed system with C# and windows servers. Was rock solid I miss it so much. I'm not drowning in Java/Spring/Linux app its such a horrible mess, security is the worst nightmare but even stuff like NFS is regularly breaks. Windows was great.
Well, things have a tendency to come full-circle again. Maybe with the cloud offerings, we'll realize that open-source isn't so great and go back to more proprietary offerings.
C# is basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows. You can write architecture astronaut shit in C# just as much as Java.
The nice thing about Java is the deployment and management tooling. It's cross-platform and mature. C# is not nearly as good in this respect, although with the open-source it is finally free to move with that.
> C# is basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows.
C#/.NET hasn't been tied to windows for a number of years now. .NET Core/.NET 5 is cross-platform and great to work with. All of our CI/CD runs on Linux agents too.
The branding has been churned like crazy. As far as I can tell, the first .NET version that officially supported (almost?) the complete API on Linux was released last month, so we’d have to sign up for being an early adopter.
"the complete API" is a bit of a misnomer, since there have been new APIs and runtime capabilities that aren't available to the Windows-only, older runtime (The .NET Framework). This has been the case since at least .NET Core 2.1 but has continued ever since.
The remaining APIs are (mostly) AppDomains, Remoting, Web Forms, WCF server, and Windows Workflow, most of which is either an acknowledged "this was the wrong way to do it so we won't bring it forward" (e.g., Remoting) or tied to Windows anyways (e.g., WCF).
> C# is basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows
C# is not tied to Windows, some new features in the latest C# 9.0 doesn't even support running on the Windows-only classic .NET Framework.
All new .NET development + C# features is being invested into .NET 5+ (FKA .NET Core), i.e. the high-performance cross-platform runtime.
> The nice thing about Java is the deployment and management tooling. It's cross-platform and mature. C# is not nearly as good in this respect, although with the open-source it is finally free to move with that.
Citation needed, I deploy my .NET 5 Apps with Linux tools, either rsync, Docker as well as AWS ECS. All clean + simple, only requires a single command to publish your App ready for distribution, that you can either rsync across or include it in the runtime image of your Docker build.
Tried to publish a Java package last week and the whole experience was a shit show, by far the worst experience of all languages where the recommendation to publish a package is to push it to bintray first, make it available to jCenter than sync it to Maven, where you need to get manual approval to include it in jCenter then you need to create yet another account/credentials with a 3rd Party which requires a manual request via a damn Jira ticket. Then each package manager has different requirements as to what a package needs, I could publish it to bintray but couldn't get it to jCenter without uploading a POM which new Kotlin projects aren't created with, then MavenCentral requires a stricter POM and Java Docs but there's no standard way to publish to a repository as bintray needs their own non-compatible task, so now I have duplicated generated POM's in my gradle build to satisfy different repositories, for bintray I needed to hook into their bintrayUpload task and generate the POM just just before it uploaded the package which I needed to decompile its sources to find out where exactly the POM file needs to be written to, no examples of which existed for Kotlin build.gradle.kts scripts that new Kotlin projects are created with. Then there's the case that every build.gradle example uses configuration that is already deprecated and Java/gradle seems to be the only one requiring uploading binary .jar's with your source projects.
Every other language has a single repository you can publish to that you don't need to jump hoops to get, published using standard tools, simple, clean, straight-forward & well documented.
Something C# never was, given that it always JITs before execution and AOT compilation to dynamic libraries has been available since version 1.0 via NGEN.
Plus lots of additional AOT alternatives like Windows 8.x Bartok compiler, .NET Native and CoreRT.
This on top of third party offerings like Mono AOT or IL2CPP, and the research compilers from Singularity and Midori projects.
Whereas for Java, while AOT has been available since around 2000, it has been for the most part only available on commercial JDKs, and free beer AOT only came with the release of GraalVM community, the addition of J/Rockit JIT caches into OpenJDK, and IBM releasing OpenJ9 as FOSS as well.
Agreed C# and Java are virtually identical. However the cultuer is completely different. The plethora of libraries to me ends up being a handicap. We have had a bunch of different Java developers on our project and each one does things differently so we end up with a huge mess. I didn't see such problems in C# world where maybe we just had better devs that concentrated on clean models instead of incorporating fashionable libraries and other moving parts.
How so, I had nothing but issues when trying to deploy cross-platform Java because of the Java ecosystem itself being bad compared to C# or Golang where you just compile stuff and run it.
Do people still trash Microsoft? Maybe it's just because I'm in Seattle, but I feel like their reputation has really turned a corner in the past year or two.
There's still a lot of cruft from who they used to be, but I feel like most people I know echo the sentiment that Satya has been a revolution. Things like them embracing Linux, acquiring and not ruining NPM and Github, contributing to open source projects, and all the work they've done with Dotnet Core seem to really have bought them a lot of goodwill, at least with the people I know.
Yes, people still thrash Microsoft because many of their business practises and products are thrashy, even if it needn't be.
Windows is a great example - forced updates, forced ads, forced data-ming and spying, stupid UI changes etc. all make an otherwise decent OS a real pain to use and a must-avoid for the privacy conscious. These are easy to fix for a company like MS, but they do not.
I don't understand whinning about that when you have bilions of people using your OS, so shitton of people who are newbies at computers then you want to help them to stay as secure as possible.
"at best(worst?)" this thing is "not nicest", but it's totally reasonable.
you have reasonable control over updates on non-home versions, imo.
It's very jarring for an inanimate object that you are trying to wield as a tool, to suddenly have its own agency and its own priorities that it treats as more important than yours. "No, I'm busy for the next 40 minutes" and "Sorry, I have to go now" are things you hear from your friend, not from your hammer or or your toaster.
I don't mind Chrome's forced auto-updates, because they've never gotten in my way.
This was a huge, huge, huge pain in the butt in a big enterprise. Nothing like a creeping "users can no longer access the internet" spreading across the environment.
Serious question, do you actually use Windows 10? I use it daily and I've never had it force an update on me in the middle of the day. I turn it off every night and it applies the updates then, as it should.
It happened to me a couple of times this year. It was really annoying to go make coffee, and come back to an updating screen. Even better, one of these failed and spent another 30 minutes rolling back the update.
That makes sense, if you've got a laptop and you never reboot it then you're creating an impossible situation for the updater. I still don't understand the constant whinging in that case, though. Of course it's going to update while you're using it if, from its perspective, you are always using it.
People complain about forced updates because updates have come down that inexplicably break things. For example there was one update in 2020 that caused appeared to delete any files placed in the users Desktop folder (although the files weren't really deleted) and another which caused running chkdsk to corrupt users filesystem in a fashion that typically required fixing the filesystem offline.
Furthermore such updates which usually require a reboot can easily interrupt important work or a long running task.
Just yesterday my Windows install which exists solely to run steam and steam games updated and then committed suicide in a fashion that can't be automatically repaired and requires a reinstall with zero explanation. For reference the hardware is fine as is the Linux install on another drive. The windows drive is a ssd less than 6 months old. I can even mount the ntfs filesystem which appears to be just fine.
There is absolutely no excuse for not letting users pick when or if they would like to update their OS especially when their QA has completely gone to shit and they cannot realistically promise that their update wont break your install.
ltsc is the solution, and even though all the MS sychophants will tell you it's for ATMs/medical equipment only: I've been running it on my 2019 gaming box for a year, and had no issues at all
My laptop running Windows hangs periodically requiring a hard reset... if I watch Hulu on Chrome. At least twice a week and sometimes multiple times a day.
At least Windows in the 90s had the decency to put up a blue screen — now it just hard crashes without any display or debugging information.
Telemetry and forced updates are a slap in the face on top of the quality regressions.
At least Windows in the 90s had the decency to put up a blue screen
This sounds like back then there were only crashes with a blue screen (and dump), and currently there's only hard crashes without blue screen. Both of them are not true. I.e. there are apparently types crashes for which it hasn't been possible in the past decades to come up with a bluescreen, othiing new there. It is just as likely, maybe even moe so, the difference in your particular case is your hardware/driver. It's of course possible there were effectively changes at the OS level in how hard faults are dealt with, but I wouldn't just assume so.
That sounds like a hardware or driver thing, specifically related to GPU, rather than a Windows issue. You can try to disable hardware acceleration in Chrome.
My testing pointed towards a DRM problem, since it doesn’t happen with other video streaming or with rendering outside the particular Chrome + Hulu combination.
My point is two-fold:
1. Even if the driver crashes, the OS should blue screen (like it used to) rather than just hard freeze the machine.
2. Using an HP laptop with Windows and Chrome to view Hulu is so mainstream it should “just work” — so it’s a sign of industry breakdown it doesn’t.
Especially, as Windows updates, given basically infinite combination of hardware (often broken) and software (broken even more often) are super rock solid.
> Especially, as Windows updates, given basically infinite combination of hardware (often broken) and software (broken even more often) are super rock solid.
Apart from breaking SSDs [0] less than two weeks ago. And deleting your certificates in November [3]. And breaking Kerberos in November [4]. And moving your files to another user in February [1]. And breaking their own reset feature in February [2].
All of those are massively disruptive and breaking changes. And all of them have Windows Update to blame (especially the moving files bug) - not some buggy underlying hardware that Microsoft had to work around.
So true. I just yesterday, on a lark, took a win10 SSD from a new Dell and stuck it in a 10 year old HP, and within about a minute it booted much to my surprise.
For quite a while, Windows was the holdout. MacOS wouldn't even flinch if you moved it to another machine; Linux might have needed a little help finding its root volume or NIC but would otherwise be happy. Windows, however, would fall over with a BSOD.
Don't try that with Arch Linux. That distro lost me forever because I didn't log into a computer for six months (in 2012) and the OS was recoverably broken.
From experience, I highly doubt it was actually unrecoverable. I did something similar many times & all it takes is to read archlinux.org news section & apply .pacnew config diffs where needed. Arch is a bleeding edge distro constantly marching ahead; that's one of its primary advantages, so it's best to update regularly. That being said it is very much possible to not update for months, just requires a bit of extra care when you finally do due to the large number of accumulated changes.
I even did an online, in place switchover from SysV to systemd in 2011 and despite that being a scary amount of changes at once still got a working system.
The trade off there is that Apple can then perform a major architectural shift in a single fell swoop because it’s not carrying around silly amounts of legacy cruft. Endless backwards compatibility isn’t always a benefit imo.
The latter. Usually when my Microsoft Surface Book 2 (the flagship consumer device, for context) BSODs for the third time in a day because MS couldn't be assed to fix compatibility/thermal issues with the graphics card that was one of the highlight features of the device, or the tablet undocking (another highlight feature) fails, or their "Modern Standby" drains the battery from 100% to 0% overnight (Is it the 3AM wake-up to phone home? Weird ancient USB controller issues? Who knows!), I tend to just go to reddit or the Microsoft support forums and see how many other people are complaining without finding any solutions. No time to blog.
People who are newbies at computers wouldn't be able to find the
switch to turn off updates anyway, so why not include the
opt-out setting for users who care?
Forced updates are unnecessary and a bad idea, even more so in
rolling-release models.
I dislike the forced windows update because they shove crap down your throat with the updates, try to force edge on you, and repeatedly try to get you to accept their privacy stuff.
>I don't understand whinning about that when you have bilions of people using your OS, so shitton of people who are newbies at computers then you want to help them to stay as secure as possible.
But they do a great deal of backporting anyway. Enterprise and Education users can run a slow path that gets bug fixes and security updates only, for feature updates as far as 30 months back. This is not offered for any other editions of Windows, meaning feature updates are forced on them earlier than they need to be.
General consumers are now the beta testers for Microsoft Windows. With Windows built-in spyware features, they don't even need any user interaction to collect data from your computer.
I think he meant frequent and unpredictable forced reboots. But the updates are also a disaster. Microsoft trying to shoves their shitty apps down our throat every time, resetting the default applications regularly.
The thing that finally got me to abandon Windows was when a forced update wiped away the system settings that I had spent days figuring out to get a trackpad to work the way I wanted to.
I wonder how many people who complain about forced updates also complain(ed) about having to support users running decade-old versions of the OS/browsers?
It really wasn't that long ago that most commercial software still had to support IE8 (released 2009), for example, because that's where the user base was and they didn't upgrade.
I actually looked at BYOD computers and it only happens when a certain non-Microsoft software cough AV that sounds like coffee cough tried to modify the start tiles/menu for no good reason (corrupting the file in its process and forcing Windows to reset it).
Note: I'm not in the US. It seems that Americans tend to complain about this more. I don't know if it was deliberately done or not in that case.
Hasn't happened to me. My start menu always remains the same after updates. Maybe use an alternate start menu if that's the problem. There are no ads anywhere else IIRC.
As far as I recall pinball had no micro transactions.
For what it's worth I always enjoyed the "stock" games like pinball, solitaire, freecell and minesweeper. But I liked them tucked away under the clear label of the games sub menu, and without any pressure to use them
Micro transactions do suck, and I wish the trend of them would just die, but that doesn’t make a game an ad. You also have a point of the games being tucked away with the option of bringing them out if you wanted. Microsoft should’ve done that.
They are doing this to survive, not because they love open source and Linux. MS is still every ounce of the company they were in the 90s, they just saw the writing on the wall and decided to play for the new generation of developers. I don't trust them any better.
We're fortunate that Microsoft shareholders think catering to developers is good for business. Not every megacorp thinks so. I mean, take a look at Swift's documentation and tell me with a straight face that Apple cares about developers.
While Windows 10 i pretty good and stable system, the bundled programs that are default for photos etc are truly awful. In corporate environments it's often hard or impossible to install 3rd party programs, so when the default bundled software suck, it is frustrating to deal with...
It's funny because Linux did just that to Unix. Embrace (new OS that does everything Unix does, and free!), extend (Linux has features not found in classic Unixes), extinguish (Linux is now the de facto standard, so anyone who wants to use Unix is laughed at).
Microsoft gets mocked for embrace/extend/extinguish, but really, it means just do a better job than the competition. Embrace: "do what others are doing", extend: "do a better job at it, have more features than the competition", extinguish: "sell customers on those features and improvements". How anyone could be against competition, simply because it's framed in a cheesy phrase, is beyond me.
You can compete without working to convert an ecosystem from standardized to proprietary. If that happens it becomes much harder for anyone else to compete, and the end result is reduced competition.
It's much less of an issue if you make your own new thing be proprietary. It causes problems when you co-opt an existing market. It really causes problems when you're devoting external resources to conquering the market and once you do so you stop caring very much about improving any more.
Commercial Unix extinguished themselves without much help from Microsoft. The Halloween documents were about Linux after all (over 20 years ago!).. the commercial Unix players have only themselves to blame. Unless we’re going to blame all the mistakes of DEC, HP and IBM on Microsoft. Like geez.... even if that’s true then frankly Microsoft deserved to win.
Commercial Unix suffered from a lack of vision. They could have made version to run on x86, but they basically conceded to the low end to Linux. They were too busy making money from selling super-expensive RISC-based machines.
Solaris had a good version, which I used for a time, while I was running a data center full of Sparc equipment. All the user space stuff was happening in Linux-land. Solaris x86 had a nice repo for various packages, but there was always something you wanted that wasn't there. It got really close, though.
If one of the bigs would have gotten serious about packaging up, say, Debian's userland stuff, they could have put a serious dent in Red Hat, and maybe things would have played out differently.
> How anyone could be against competition, simply because it's framed in a cheesy phrase, is beyond me.
Because you've entirely misunderstood what EEE means. It absolutely does NOT mean to "do a better job." That phased was coined SPECIFICALLY because it was how Microsoft either absorbed competitors, or put them out of business. They spent decades doing JUST ENOUGH to persuade people to use their stuff, even when it was NOT as good -- given the advantage of their monopoly position and vertical integration -- in order to starve the competition of oxygen.
Microsoft is a big company. Some things it does will always be trashy - like fighting tooth and nails to keep Linux desktops and truly-open formats out of European public-service procurement. That's still going on, 20 years and 2 CEOs later, and will probably never stop, because screw public interest when there is so much money on the line!
But sure, in some areas they behave better now. They had no choice, after losing a whole generation of developers and seeing their cash-cows (Windows, Office, and AD/Exchange) under siege from SaaS insurgents. I've still to see something where their efforts are not fundamentally tied to their immediate self-interest, though.
Could be my neck of the woods too but where I am Microsoft has the best reputation among the Major tech companies (not a privacy nightmare, great research division, has started supporting open source, remains fairly apolitical)
> and all the work they've done with Dotnet Core seem to really have bought them a lot of goodwill, at least with the people I know.
Microsoft has done some good things with .NET Core, but they still don't have a very friendly OSS or partner strategy.
AppGet is a pretty good example; there was an existing Open source solution that filled a need, and Microsoft decided to create their own replacement, not bothering to give any credit (until there was an internet ruckus) to the original despite the very striking similarities and relative level of obviousness that they were at bare minimum 'inspired' by the tool; after all, they interviewed him for a role and even warned him the day before it came out... [0]
Octopus is another example. I -hate- TFS Release pipelines. Octopus Deploy was (until they ruined their pricing model) a far superior product overall. You can really tell the way TFS Release pipelines were done, they tried to 'checkbox-copy' Octopus Deploy's features without making it too much like Octopus to be obvious.
But the checkbox-copy strategy is inferior in many ways. In Octo you can have a stage that runs in all environments (but certain steps on/off per env) and configure server groups that way. In TFS Release, You have to have to 'copy' the steps for every stage. It's like their data model is missing a 1-many relationship or two somewhere.
And the impacts in the case of their behavior has a second-order effect; I am curious whether TFS Release eating into Octopus's market share was a factor in their price hikes a couple years ago; in that regard, I can't blame them if that's the case.
Microsoft is like the government... everyone has a relationship with them, and those experiences vary from high trust / strategic down to a sort of taxman.
If your work is such that scaling to bazillions of servers or other artifacts isn’t an issue, Microsoft is a smart choice. If you are building Facebook, it is a dumb choice.
I only wish more of those tools would be cross platform. I know it's not happening, but it'd be nice if I could develop WPF stuff right on my macbook without a VM.
Brands can turn money into goodwill, given enough money, time, and skill.
I don't think this is some fundamental shift in Microsoft or its values: simply a shift in their market positioning and brand value/identity.
Their products are still proprietary spyware, designed to get as many people locked into the Windows (or now Azure) licensing ecosystem as possible. Even the best parts of VS Code, often cited as one of their best new releases, are either spyware or proprietary. Windows remains a tire fire.
GitHub and NPM are prime examples of this concept that one can turn money into goodwill. I assume money also changed hands for the first-class support that Docker has for windows.
A lot of people don't update their opinions because it takes work. I know because I've made it habit of checking my assumptions and I still forget. For example, people still trash PHP and post a "A Fractal of Bad Design" when PHP 8 is now on par with any other language and not an amateur minefield. Some things get better, some things get worse. It's best to check in once in awhile. Microsoft is much better than it was 20 years ago.
Good point and maybe true for PHP, but not for Microsoft or its products. They've continued to "update" their bad practices too, and it's not just old criticisms that are rehashed again against them.
And no, to me Microsoft is actually worse than before as they have turned Windows into a spyware. The forced updates (not just security updates) make it even worse.
There is some correlation between selling good products and valuation. Intel's valuation for example went down 25% in 2020 in contrast to the NASDAQ US Composite index (of which Intel is a part) which went up over 40%.
Who decides it is a good product? Seems to me it is rather "selling a lot". Lots of people do not think Apple make good products and prefer Dell or Huawei etc. That doesn't change the valuation of Apple.
My problems with microsoft really aren't around their security practices (these days).
It's more around the ads in the start menu, the telemetry they send, and their tendency to reset my telemetry settings around updates.
I don't feel like I'm in full control when I'm using a computer running windows. Which, y'know, is probably fine for 95% of computer users, they want more of an appliance than a general computing experience.
It does if it has to go through the Windows Defender check. Enough that sometimes I end up launching the same thing multiple times because I get gaslit into assuming I haven't launched it.
If you've been following this story you'll realize that someone at Reuters really has it in for Microsoft. This despite the backlash they've seen in the community for their rather tenuous leaps of logic (see for instance this gem: https://in.reuters.com/article/global-cyber-usa/suspected-ru...).
You'll note that they buried the byline in this piece at the bottom, crediting "Reuters staff" at the top.
You're saying Reuters shouldn't report severe security breaches at Microsoft? Or that they are doing it because someone there dislikes Microsoft? For the latter - does the motivation really matter?
I was responding to a comment about why Reuters didn't link their source for the article by pointing out that it's consistent with their coverage of trying to sensationalize a pretty boring story. If they linked the Microsoft blog post, people might realize that the story isn't what Reuters is trying to spin it as.
Their motivation of generating click-bait at Microsoft's expense matters as it means you should seek clarifying information from other sources. Or just ignore Reuters and hope the drop in traffic drives them to more closely tell the whole story.
Technically true as far as it goes, the important bit about the piece is what it doesn't say; no modifications or builds. To understand how important that is, and why Microsoft included it in big letters in their post, just see how many people here are asking/worrying about that possibility. Read isn't cool, nefariously wrote is cool.
Technically true but highly misleading is a dangerous route to go, and it makes me sad how often stories tread that path in the name of clicks.
My gut feeling is that it's more about an instinct not to drive traffic offsite from their customers online properties, perhaps combined with a now hilarious print-defensive attitude ("URLs don't work in print and our reports must work equally well both online and in print").
Breached is a legal term... they were compromised but probably didnt suffer a breach. The MSRC blog post is exactly there to cover those legal grounds I guess.
Because the goal of news should be to inform, especially when talking about court filings, and we as viewers should not give traffic to sites that don't do basic linking work.
I believe parent was being rhetorical and or facetious.
What we believe organizations should do and what they actually do in is often misaligned based on problematic underlying driving forces/goals.
Profit motives have tended to overcome all other incentives in our (the US) economic structure. It may be a broader problem globally due to power and influence of the US.
The same can be said about consumer motives. I probably should shop locally more often, but I may not be able to afford local rates and have to pass the costs down the line if I want to continue supply more basic underlying goals (eating, staying sheltered, etc).
At some point we have to have the difficult conversations of choosing the tradeoffs we do and don't want to support, otherwise we may let flawed underlying goal structures guide us to the paths of least resistance, which may ultimately not be good for humanity (or it may be, who knows).
Given a lot of current directions, I find it hard to believe our underlying system structures are great for human well being. It may have been a good run for awhile but that may be a short temporal anomaly. We may have to more throughly consider long term consequences of goals we set that may run counter to their actual intent.
It's easy for some to simply ignore the underlying problems and play the game optimally for oneself. Personally, I've never been happy with that option (the option which OP sort of alludes to).
Them Covington High Schoolers would like to have a word. It took me under 10 minutes to do what CNN didn't bother to do: confirm the claims of one man. It cost them dearly, and rightfully so.
> Microsoft said the account did not have the ability to monitor any Microsoft code. The blog post further added it has found no evidence of access “to production services or customer data.”
The article is in contradiction with the headline, isn't it?
The reuters link posted here is click-bait junk. This section from the Microsoft blog provides better context.
>We detected unusual activity with a small number of internal accounts and upon review, we discovered one account had been used to view source code in a number of source code repositories. The account did not have permissions to modify any code or engineering systems and our investigation further confirmed no changes were made. These accounts were investigated and remediated.
>At Microsoft, we have an inner source approach – the use of open source software development best practices and an open source-like culture – to making source code viewable within Microsoft. This means we do not rely on the secrecy of source code for the security of products, and our threat models assume that attackers have knowledge of source code. So viewing source code isn’t tied to elevation of risk.
Not untrue. Internal orgs adopt a monorepo structure - the source for the majority of the infra is readable from almost any developer within the company.
> To distinguish, they even have a different name for it - inner source.
Yeah, I recognize MBA speak when I see it. That's why I chuckled. They were hacked and somebody saw their code. Now some guy in upper management has to spew some bullshit to protect the company's "image".
Work at MS, that term has been used for a long time internally, certainly longer than I have worked here. It really is very useful to be able to go find the code for a product when you want to understand how something works.
This seems like a very serious breach. Expect zero-days to run rampant the next 10 years.
I don't know if to pat Microsoft on the back or give the ma scolding.
If you are up against a military intelligence hell bent on discovering attack vectors produced by the private commercial industry then this is a losing battle-whoever has infinite resources win.
In this case the governments of the world can print unlimited money and has to access to the top of the creme, we are talking 0.0001% of the population working on discovering the next zero day vulnerability.
How does a for profit corporation go up against an adversary with infinite resources?
> How does a for profit corporation go up against an adversary with infinite resources?
The largest corporations are wealthier than some nations. Governments do not have unlimited resources. When national security depends on corporate security, governments can subsidize it with some other parts of their own "infinite resources".
Not saying I disagree with your point overall, but this rhetoric rubs me the wrong way.
Who owns the money printers? Is it microsoft or is it the governments recognized by the USGOV?
Who has control over the monetary supply? Is it microsoft or is it the governments who control respective central bank?
Who has control over deciding whether microsoft is a monopoly or not? Again, its not the corporation.
Sure you can have corporations richer than most developing nations but that has no relevance on the policy/power balance between government and a corporation.
Even if all of the corporations in America formed a coalition, it is the government which has monpoly over violence that can decide out of whim if you are suddenly against them or with them.
Why would basic facts rub you the wrong way? Do you believe that corporations can control the military, police and paramilitary forces in the Western world?
