Thanks, I can very much agree with that.
Re Oppenheimer: I know. My point was that he very much knew what his work was being used for, as should people working at xAI at the moment.
1,613 karma · joined September 12, 2013
Re Oppenheimer: I know. My point was that he very much knew what his work was being used for, as should people working at xAI at the moment.
I don't know why this argument often pops up in these kinds of discussions. Approximately no one is judging people who have done their best effort to avoid doing harm. We are judging people who don't care in the first place.
This is definitely not universally true. E.g. photos are very cheaply printed on demand. Even on-demand books are printed at reasonable prices. Sure, mass production is cheaper (both for books and pictures), but the value difference of the individual product is high enough to bridge the price gap.
For cloth this area has found little exploration. TFA covers production at niche scale. If you would mass produce the looms to reduce the capital expense and heavily lean into customer value, e.g. individual fittings via 3d scans, as my sister comment proposes, or even just letting me customize my sweater with motive, color choice, garment etc., this could radically change the cost to value ratio. The company that has published TFA sells extremely bland apparel in a shop that looks just like any mass produced clothing shop and leaves all of the customer value of custom production on the table.
Last but not least: This "3d knitting" seems to need only a fraction of the labor of traditional sewed clothes. If textile production didn't default to underpaid labor under precarious working conditions in low income countries, it would probably already be cheaper.
I was with you up to this point, but when you say "life is to hard to stay moral" I am thinking about how buying the wrong shampoo contributes to micro plastic in the ocean, or how buying a fitting jeans that is not exploiting labor is an extremely time intensive endeavor, or how avocados may be vegan but often produced unsustainable. Basically I thought you were making this point from The Good Place https://www.youtube.com/watch?v=Lci6P1-jMV8 .
But when you are working in IT, an industry that is generally still very well of, avoiding an employer that is actively making the world a worse place, is a low bar to cross. It's just one decision every few years, which also is comparatively easy to research (you are probably doing it as your normal preparation for the job interview anyway) and the impact of that decision is enormous in comparison to most other decisions you make, so it's well worth it to ponder a bit.
Performative non-conformance might be e.g. helpful to nurture a culture of critical thinking, but if it is just performative, then it is worthless.
(I write this with no intent to criticize you, burningChrome, or Jyn. You might very well do just that.)
(Also, I'm aware that the ability to push back is very unevenly distributed. I'm addressing those that can afford this agency. And also, non-conformance is spectrum: You can also push back a little without choosing the specific point to be the hill to die on. Every bit counts.)
[1] https://idiallo.com/blog/hostile-not-enshittification
[2] https://www.404media.co/heres-a-pdf-version-of-the-cia-guide...
> Clearly power capacity cost (scaling compressors/expanders and related kit) and energy storage cost (scaling gasbags and storage vessels) are decoupled from one another in this design
Lambdaone is differentiating between the costs to store energy (measured in kWh or Joules) and the costs to store energy per time (which is power, measured in Watts). If you want to store the whole excess energy that solar panels and wind turbines generate on a sunny, windy day, you need to have a lot of power storage capability (gigawatts of power generated during peak power generation). This can be profitable even if you only have a low energy storage capability, e.g. if you can only store a day worth of excess solar/wind energy, because you can sell this energy in the short term, for example in the next night, when the data centers are still running, but solar panels don't produce power. This is what batteries give you -- high power storage capabilities but low energy storage capacities.
Of course, you can always buy more batteries to increase the energy storage capacities, but they are very expensive per energy (kWh) stored. In contrast, these CO2 "batteries" are very cheap per energy (kWh) stored -- "just" build more high pressure tanks -- but expensive per power (Watts) stored, because to store more power, you need to build more expensive compressors, coolers etc. This ability to scale out the energy storage capability independently of the power storage capability is what Lambdaone was referring to with the decoupling.
For what is this useful? For shifting energy over a larger amount of time. Because energy storage costs of batteries are so high, they are a bad fit for storing excess energy in the summer (lots of solar) and releasing it in the winter (lots of heating). I'm not sure if these "CO2" batteries are good for such long time frames (maybe pressure loss is too high), but the claim most certainly is that they can shift energy over a longer time frame than is possible with batteries in an economically profitable fashion.
I think the wrong assumption you're making, is that there is supposed to be a simple answer, like something you can describe with a thousand words. But with messy reality this basically never the case: Where do you draw the line of what is considered a taxable business? What are the limits of free speech? What procedures should be paid by health insurance?
It is important to accept this messiness and the complexity it brings instead of giving up and declaring the problem unsolvable. If you have ever asked yourself, why the GDPR is so difficult and so multifaceted in its implications, the messiness you are pointing out is the reason.
And of course, the answer to your question is: Look at the GDPR and European legislation as a precedent to where you draw the line for each instance and situation. It's not perfect of course, but given the problem, it can't be.
That is the point, though: Correlated outages are worse than uncorrelated outages. If one payment provider has an outage, chose another card or another store and you can still buy your goods. If all are down, no one can shop anything[1]. If a small region has a power blackout, all surrounding regions can provide emergency support. If the whole country has a blackout, all emergency responders are bound locally.
[1] Except with cash – might be worth to keep a stash handy for such purposes.
> Yes, free markets and monopolies are not incompatible.
How did you get from "efficient markets" to "free markets"? The first could be accepted as inherently value, while the latter is clearly not, if this kind of freedom degrades to: "Sure you can start your business, it's a free country. For certain, you will fail, though, because there are monopolies already in place who have all the power in the market."
Also, monopolies are regularly used to squeeze exorbitant shares of the added values from the other market participants, see e.g. Apple's AppStore cut. Accepting that as "efficient" would be a really unusual usage of the term in regard to markets.
I was of the impression that this was the majority opinion. Is there any serious party that doesn't advocate hybrid schemes where you need to break both well-worn ECC and PQC to get anywhere?
> The standard line is around store-now-decrypt-later, though, and I think it's a legitimate one if you have information that will need to be secret in 10-20 years. People rarely have that kind of information, though.
The stronger argument, in my opinion, is that some industries move glacially slow. If we don't start pushing now, they won't be any kind ready when (/if) quantum computing attacks become feasible. Take industrial automation: Implementing strong authentication / integrity protection, versatile authorization and reasonable encryption into what would elsewhere be called IoT is just now becoming an trend. State-of-the-art is still "put everything inside a VPN and we're good". These devices usually have an expected operational time of at least a decade, often more than one.
To also give the most prominent counter argument: Quantum computing threats are far from my greatest concerns in these areas. The most important contribution to "quantum readiness"[1] is just making it feasible to update these devices at all, once they are installed at the customer.
[1] Marketing is its own kind of hell. Some circles have begun to use "cyber" interchangeable with "IT Security" – not "cyber security" mind you, just "cyber".
(And my highest preference would be for vendors to be forced to publish both server and client code as free software, if they don't continue selling their service for reasonable prices. Not only for games, but for all services and connected devices. Getting political support for such regulations is, of course, extremely hard.)
You need to know how git works and GitHub's API. I would say I have a pretty good understanding about how (local) git works internally, but was deeply surprised about GitHub's brute-forceable short commit IDs and the existence of a public log of all reflog activity [1].
When the article said "You might think you’re protected by needing to know the commit hash. You’re not. The hash is discoverable. More on that later." I was not able to deduce what would come later. Meanwhile, data access by hash seemed like a non-issue to me – how would you compute the hash without having the data in the first place? Checking that a certain file exists in a private branch might be an information disclosure, but gi not usually problematic.
And in any case, GitHub has grown so far away from its roots as a simple git hoster that implicit expectations change as well. If I self-host my git repository, my mental model is very close to git internals. If I use GitHub's web interface to click myself a repository with complex access rights, I assume they have concepts in place to thoroughly enforce these access rights. I mean, GitHub organizations are not a git concept.
Second, your implicit premise is likely wrong. Different people have different talents and different challenges. Concrete example: In German we say eight-and-fighty for 58. Thus 32798 gets two-and-three-thirty-seven-hundred-eight-and-ninety where you constantly switch between higher and lower valued digits. There are many people, me included that not-seldomly produce "Zahlendreher" – transposed digits – because of that, when writing those numbers down from hearing alone, e.g. 32789. But then, there are also people for whom this is so much of a non-issue that when they dictate telephone numbers they read it in groups of two: 0172 346578 becomes zero-one-seven-two-four-and-thirty-five-and-sixty-eight-and-seventy. For me this is hell, because when I listen to these numbers I need to constantly switch them around in my head with active attention. Yet others don't even think about it and value the useful grouping it does. My current thesis is that it is because of a difference between auditory and visual perception. When they hear four-and-thirty they see 34 in their head, whereas I parse the auditory information purely auditory.
What I want you to take from my example, is that these issue might not be training problems alone. I have learned the German number spelling from birth and have worked in number intensive field and yet I continue to have these challenges. While I have not been deeply into history, I suspect that my troubles with Xth century versus x-hundreds might persist, or persist for a long time, even if I get more involved in the field.
Focusing on short term repercussions for consumers has significantly hurt long term consumer interests and there is evidence that it hurt the economy in general. In the decades preceding the 1980s it was generally understood that competition itself is a necessity for effective free markets and that extreme power concentration (as we e.g. see today in the IT sector) is hard to reconcile with efficient markets and political freedom.
See [1] for details, here is an excerpt:
> An emerging group of young scholars are inquiring whether we truly benefitted from competition with little antitrust enforcement. The mounting evidence suggests no. New business formation has steadily declined as a share of the economy since the late 1970s. “In 1982, young firms [those five-years old or younger] accounted for about half of all firms, and one-fifth of total employment,” observed Jason Furman, Chairman of the Council of Economic Advisers. But by 2013, these figures fell “to about one-third of firms and one-tenth of total employment.” Competition is decreasing in many significant markets, as they become concentrated. Greater profits are falling in the hands of fewer firms. “More than 75% of US industries have experienced an increase in concentration levels over the last two decades,” one recent study found. “Firms in industries with the largest increases in product market concentration have enjoyed higher profit margins, positive abnormal stock returns, and more profitable M&A deals, which suggests that market power is becoming an important source of value.” Since the late 1970s, wealth inequality has grown, and worker mobility has declined. Labor’s share of income in the nonfarm business sector was in the mid-60 percentage points for several decades after WWII, but that too has declined since 2000 to the mid-50s. Despite the higher returns to capital, businesses in markets with rising concentration and less competition are investing relatively less. This investment gap, one study found, is driven by industry leaders who have higher profit margins.
[1] https://archive.is/HEik3#selection-1737.0-1737.346 (original: https://hbr.org/2017/12/the-rise-fall-and-rebirth-of-the-u-s... )
For that reason, quite a few mathematicians view the real numbers as a useful, but ultimately absurd set. Much more sane is the set of computable numbers, that is the set of numbers for which you can find an algorithm that computes the number to arbitrary precision. (More formal: A number x is computable if there exists a Turing machine that gets as input a natural number n, terminates on all inputs, and outputs a rational number y such that |x-y|<10^-n .) Every number you ever thought of is computable, but as a mathematician, working with the set of computable numbers is much more tedious than working with real numbers.
They argue that if you actually look into the details, especially into the "dry" political, legal and social ones, trying to settle mars or the moon likely actually increases our risk of existential crises (at the current point in time at least). Think conflicts between nuclear powers over the (surprisingly few) good spots on the moon, or rocks (=asteroids) flung to earth by space settlers (there is a lot of deadly potential energy floating above all our heads).
Furthermore, there are loads of open space biology questions that quickly become ethical questions when permanent settlements are considered. Can you have babies in low/micro gravity? How can you do it without too much harm to your child? The responsible approach is to do a few more decades of targeted research first.
Regardless of the downers it delivers, it's actually a fun read and I can recommend it wholeheartedly.
It's probably pretty rare nowadays, since it's off by default and rather hidden in the settings dialog ("Search for text when you start typing"). I had it activated up until (quite) a few years ago, and I think I switched it off, because of bad JavaScript interactions.
- Search: https://www.phind.com/search?cache=s4e576jlnp1mpw73n9iy4sqc
- Chat: https://www.phind.com/agent?cache=clsyev95o0006le08b5pjrs14
The search was heavily diluted by authentication methods that don't make any sense for machine-to-machine authentication, like multi-factor or biometric authentication, as well as the advice to combine several methods. It also falls into the, admittedly common, trap of assuming that certificate based authentication is more difficult to implement than symmetric key (i.e. pre-shared key) authentication.
The chat answer is not perfect, but the signal-to-noise ratio is much better. The multi-factor authentication advice is again present, but it's the only major error, and it also adds relevant side-topics that point in the right direction (secure credential storage, secure boot, logging of auth attempts). The Python example is cute, but completely useless, though (Python for embedded devices is rare and in any case you wouldn't want a raw TLS socket, but use it in a MQTTS / HTTPS / CoAP+DTLS stack, and last but not least, it provides a server instead of client, even though IoT devices mostly communicate outbound).
Isn't it funny, how the "less secure app or device" is completely on par with OAuth-capable apps regarding security just by using a server-side mechanism Google could have promoted since… forever? Almost as if it technically isn't a feature of the app at all.
(Yeah, I get it, "apps where the secure workflow is less convenient" doesn't have the same ring to it, so the simplification is justifiable for easy communication – you will say. The greater problem is that it is kind of Google's thing to always interpret security concerns in such a way that it furthers Googles agenda and this puzzle piece is no exception.)
From a practical perspective, there are lots of applications out there which are perfectly reachable from the outside and which use an OAuth2/OIDC library as a standard component where they could forward an update from the identity provider with a simple library call. And think about how much edge cases in front-end applications could eliminate, if you wouldn't have to be ready to get a new token at any moment, because the current one has just expired. [1]
In my opinion, pushing updates to clients should be the default of identity protocols which you only opt-out of, if you have special needs. And then hopefully documentation tells you very clearly to have very short token expirations.
[1] And yes, you technically still have to be prepared for that at any time, but you can push the trade-off of making that case less user friendly much further, if it occurs only seldom.
As a whole, reading this biking thread is an amazing example in failure to understand how a lot of small lifestyle decision lock you in a particular mode of living. I know that much of northern America is not really bike friendly. But, damn, looking at it from a German urban perspective, it does not seem like you were even trying. (And I can't blame you for that because you were missing the role models to follow.)
Half of my friends don't own a car, many of them have children. They started out by not ever having a car in the first place. We chose the cities we live in, the jobs we work for, the daycare facilities we commute our children to, all with the implicit assumption that owning a car is not desirable.
A second factor that is really underappreciated is habit. After about one and a half years of commuting to work by e-bike in various tolerable weather situations, I encountered the first really harsh road conditions. Not just snowy, but icy ground everywhere (which was definitely not fun for cars either). But because I was so used to dealing with bike challenges by then, overcoming yet another (though harder) bike challenge was so much more comfortable to me than working out the alternatives. Same with the day I was somewhat sick and there was intense, icy rain. (Nowadays I would have the decency to stay home when being sick, even though they "need" me at work).
So basically the answer to "How could biking ever work?" is "We make it work" – like with everything in life. And in the right environments, the upsides are enormous.
And you are right, nothing that they would realistically have said would have satisfied me. But that is because they have set themselves up for failure long before. Quoting from GordonS above [1]:
> I get what you are saying, but I gave little sympathy for their situation - they used the VC tactic of "give it away to gain and monopolise the market, then do the old switcheroo once we're #1", so they had to know what was coming.
The real question is how many services are able to access the data live and how many support and debug interfaces (indirectly) allow you to read it. Measure GitHub's success in securing the secrecy of private repos in how few employees can breach it without causing alarms. Even without cynicism I would be surprised if it was their main concern. Data integrity is far more important for code. (There are notable exceptions, of course. If applicable, don't put it in the cloud!)
> Which ones?
Take Utimaco Security Server and you'll get 10k+ RSA signatures per seconds. Yes, you'll definitely need dozens of them, but you'll probably want several for high availability and low latency anyway.
> For SSH? Only by having the same private key in all of them, which means it's still around somewhere.
End-to-End encrypted key transfer between HSMs is well established. Ops for such a setup is definitely going to be a pain and lots of manual (and thus expensive) work but it is doable. The banking industry has been operating like that since forever – with symmetric cryptography only. Imagine two people being sent letters with XOR halves of a transport key and physically meeting at an HSM and entering the halves on a PIN pad (not a hexadecimal but a decimal PIN pad, mind you, where you need to press shift for A-F). From a modern perspective it's totally bonkers, but it works.
If I was tasked with building something for large scale companies like GitHub, I would probably pass up on HSMs and use commodity measured boot on a minimal Linux for my trusted key servers. Outside of these key servers the SSH key would only be stored split up with Shamir-Secret-Sharing with few trusted employees which will only restore the key on ephemeral offline systems. Is that overkill? Very much depends on your threat model. Investing in the security of their build chain runners and data-at-rest integrity might have higher pay off. But then again, GitHub has become such a big player that we should also hold them to very high standards. And the setup can be re-used for all their secret management, e.g. TLS certificate private keys.