As with most things in security, it's a trade-off between competing goals and principles.
2,400 karma · joined August 26, 2010
As with most things in security, it's a trade-off between competing goals and principles.
> “What do we think they might do with more cash on hand than they expected?” Scott asked in her June blog post. “Hire a few extra team members they know they can pay for the next five years. Buy chairs for them. Stop having to work every weekend. Get some sleep.”
My wild ass guess is that she’s hoping her firehose of money will do more good in a shorter amount of time versus spending a lot of time fine tuning the giving.
I think a lot of billionaire philanthropists see their giving as almost like a kind of investment, and some of them want to see a return on that investment that is above the average return from the average non-billionaire giver. That in turn causes the recipient to spend at least some time thinking about how to make that billionaire feel like they got a good return.
It sounds like McKenzie-Scott’s idea of giving is more hands off, identifying teams that had a history of doing good work, and giving them both resources and mental space to execute.
Something for effective altruists to consider.
Give it some time
Literally one of the best customers of NSO tools is Saudi Arabia (SA), where money literally bursts out of the ground in the form of crude oil. The market cap of Saudi Aramco is 3x that of Apple's. Good luck making it "uneconomical" for SA to exploit iPhones.
I'll even posit that there is literally no reasonable amount where the government of SA cannot afford an exploitation tool. The governments that purchase these tools aren't doing it for shits and giggles. They're doing it because they believe that their targets represent threats to their continued existence.
Think of it this way, if it costs you a trillion dollars to preserve your access to six trillion dollars worth of wealth, would you spend that? I would, in a heartbeat.
> Positive Technologies is a Russian IT security firm that supports Russian Government clients, including the FSB. Positive Technologies provides computer network security solutions to Russian businesses, foreign governments, and international companies and hosts large-scale conventions that are used as recruiting events for the FSB and GRU.
But at the same time, I am sympathetic to arguments that aggregated platforms have efficiencies that are passed down to the everyday consumer, or network effects that make the platforms more competitive against similar platforms elsewhere in the world (e.g., data for training ML models).
Now I personally don't know what all of those limits should be. But I think there needs to be more open discussion from all corners of American society about that. I also think that the platforms should approach this problem with open arms.
As an example of one situation that needs to be limited is that a platform like Google is allowed to ban someone entirely from their services, with 1) no appeal to an independent party and 2) no ability to (quickly) recover data stored with that platform. Every so often, someone posts to HN saying that they lost all access to decades of email and photos because Google's algorithms banned them, and they have no idea how to talk to a human to explain or correct the situation. I think that kind of action from Google needs to be regulated out of existence.
But Facebook (and Google, Apple, and many other "platforms") are such an indispensable part of our lives that we should have difficult conversations about what individual rights look like in these quasi-public private spaces. (It's worth noting that the explicit business model of many of these companies is to create gigantic platforms/walled gardens.)
I personally do not believe that many of the norms and common law relating to physical public/private spaces should be transferred to the modern age of digital oligopoly.
And they returned to the Chinese market several years later.
> Because of this, I will now have to ban all future contributions from your University.
Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota.
EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures.
In the commit traffic[2], I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018. In 2018, Wenwen Wang was submitting patches; during this time he was a postdoc at UMN and co-authored a paper with Liu[4].
Prior to 2018, commits involving UMN folks appeared in 2014, 2013, and 2008. None of these people appear to be associated with Liu in any significant way.
[1]: https://github.com/torvalds/linux/search?q=%22umn.edu%22
[2]: https://github.com/torvalds/linux/search?q=%22umn.edu%22&typ...
From what I can tell, there seems to be increasing consolidation in the industry:
* AMD -- Xilinx -- ATI
* Nvidia -- ARM -- Mellanox
* Intel -- Altera -- Habana/Nervana -- Mobileye
But one thing I want to highlight is the fact that this story appears to be based off a report written by a consulting firm, Capgemini. For that reason alone I would bet that this report identifies hypothetical risks, not actual instances of unauthorized access.
* https://www.washingtonpost.com/national-security/china-hyper...
* https://www.washingtonpost.com/national-security/biden-admin...
The TL;DR is that one of the sanctioned companies, Phytium, designs chips used in a Chinese supercomputer that the PLA's researchers use to simulate hypersonic weapons. The chips are designed using tools from Cadence and Synopsys (both American companies) and fabricated at TSMC.
This seems like a high-labor and error-prone way to detect a possible integrity compromise of your build infrastructure. Maybe they've done this, but what software shops need to do is better control the integrity of their build infrastructure and the confidentiality of their code signing keys.
Ideally, build infrastructure would be immutable (resistant to unauthorized change), burnable (defeats persistence), and auditable (changes need to authorized and logged). The build infrastructure itself would produce auditable artifacts from the build, including hashes of input files, compilers, etc.