[HN Gopher] Anduril and Palantir battlefield communication syste...
___________________________________________________________________
Anduril and Palantir battlefield communication system has flaws,
Army memo says
Author : gok
Score : 191 points
Date : 2025-10-03 15:46 UTC (7 hours ago)
(HTM) web link (www.cnbc.com)
(TXT) w3m dump (www.cnbc.com)
| dmix wrote:
| > The assessment, seen by Reuters and first reported by Breaking
| Defense, comes just months after defense drone and software maker
| Anduril was awarded a $100 million to create a prototype of NGC2
| with partners including Palantir, Microsoft and several smaller
| contractors.
|
| > Army chief information officer and Chiulli's supervisor, said
| in a statement to Reuters that the report was part of a process
| that helped in "triaging cybersecurity vulnerabilities" and
| mitigating them.
|
| So it's a brand new prototype and this is a run of the mill
| cybersecurity review while it undergoes some internal testing?
| rohan_ wrote:
| yeah i don't understand - they spent a few months building a
| prototype... do people not understand what a prototype is?
|
| This sounds like a nothingburger.
| DaveZale wrote:
| Yup, that's the job of the folks at Fort Carson: find the
| flaws in the prototype. I often hear and feel the booms when
| they are testing. The percussive shocks travel many miles
| through the shale to under my house.
| TimorousBestie wrote:
| Bolting on security after the fact is not exactly the
| preferred strat.
|
| Especially when the cost of busted security in this context
| is "exceptionally grave damage."
| zdragnar wrote:
| I think btown's sibling comment has it right. It's not even a
| prototype if it isn't demonstrating some aspect of its core
| capabilities.
|
| Given this line from the article: Despite
| the early September memo's scathing critique, Leonel Garciga,
| Army chief information officer and Chiulli's supervisor, said
| in a statement to Reuters that the report was part of a
| process that helped in "triaging cybersecurity
| vulnerabilities" and mitigating them.
|
| and Other deficiencies highlighted in the
| memo include the hosting of third-party applications that
| have not undergone Army security assessments. One application
| revealed 25 high-severity code vulnerabilities. Three
| additional applications under review each contain over 200
| vulnerabilities requiring assessment, according to the
| document.
|
| it seems like there was a SIGNIFICANT mismatch in
| expectations between the team delivering the prototype and
| the people receiving it. Everyone's time was wasted as a
| result.
| btown wrote:
| > The report says the system allows any authorized user to
| access all applications and data regardless of their clearance
| level or operational need. As a result, "Any user can
| potentially access and misuse sensitive" classified
| information, the memo states, with no logging to track their
| actions.
|
| Given that segmentation of data access is a core part of the
| pitch (see e.g. https://www.palantir.com/docs/gotham) - if
| security controls were intentionally omitted from the prototype
| scope, that seems like a reckless scoping decision to make. And
| if security controls were unintentionally bypassed, this speaks
| to insufficient red-teaming of the prototype before launch.
|
| I couldn't be more pleased that this is coming to light,
| though. Perhaps it opens decisionmakers' eyes to the dangers of
| over-centralizing military operations on a system that
| simultaneously allows operators to diffuse accountability to a
| semi-autonomous target-calling system, _and_ is foundationally
| connected to surveillance-state systems tracking U.S. citizens.
| Entire genres of movies posit the negative outcomes of this
| kind of system on civilians and military personnel alike; they
| are cautionary tales to Not Create The Torment Nexus. Sometimes
| decentralized, human-in-the-loop, need-to-look-the-target-in-
| the-eyes operational coordination is a feature, not a bug.
| mrtnmrtn wrote:
| << Enterprise security
|
| We reject the notion of gating, pay-walling, or upselling
| core security controls like audit logging, single sign-on,
| and multi-factor authentication. Whether you're a small
| business or a federal agency, you get access to every core
| enterprise security feature in our standard offering:
|
| Mandatory encryption of all data, both in transit and at
| rest, that uses robust, modern cryptography standards. Strong
| authentication and identity protection controls, including
| single sign-on and multi-factor authentication. Strong
| authorization controls, including mandatory and discretionary
| access controls. Robust security audit logging for detecting
| and investigating potential abuse. Highly extensible
| information governance, management, and privacy controls to
| meet the needs of any use case. >>
| Spooky23 wrote:
| The real question is: did the product manager shave his
| beard?
| jandrewrogers wrote:
| I've worked on similar types of operational systems in the
| past. The access control is always extremely limited in the
| prototypes.
|
| It is important to understand that the customers don't have a
| clear view of the types of access controls they want until
| they start field exercises. By having relatively limited
| access controls in the prototype, they discover in real use
| cases that allowing some data access which never would have
| occurred to them is highly valuable which can then be refined
| into specific types of data sharing. In a default locked down
| environment, these beneficial interactions would never be
| discovered because they can't occur. All of the ways the
| users access and use data in the prototypes is logged and
| studied.
|
| Similarly, other types of data sharing expose real risks that
| can be reduced to specific scenarios developed during
| operational exercises. The problem with an exhaustive access
| control model is that it simply has too many degrees of
| freedom to be usable for most people.
|
| During development, the universe of all possible uses of
| access control is reduced to a much simpler and more
| understandable model of the key data it is important to
| restrict and the key data it is important to share, grounded
| in real-world operational learnings. These models are simpler
| and more precise to implement, and also easier to verify the
| correctness of, than a default "access control all the
| things" approach.
| robertlagrant wrote:
| > insufficient red-teaming of the prototype before launch
|
| There's been no launch. It's a prototype.
| logsr wrote:
| developing secure software is very difficult. you have to
| start from a foundation of immutable data storage. then you
| need reproducible compilation from source code, to all
| executables, to bootable images. then you need out-of-band
| hardware that can verify signatures on the images being
| booted. all access to the system must take place through
| accounts with hardware tokens where all data access (r/w) is
| digitally signed and logged. then you need all developer
| access to the system to take place through this system. then
| at the application layer all data must be encrypted with
| unique keys, and the ownership and assignment of access to
| these keys must all be logged. this isn't something you can
| "bolt on later." it has to be a part of the platform
| architecture before development even begins.
| derektank wrote:
| I was sort of inclined to agree coming into reading this (my
| understanding is that this is a prototype round, and other
| contractors have received awards, prior to a downselect round
| where one contractor will be selected for full production) but
| if it's true that, "We cannot control who sees what, we cannot
| see what users are doing," that seems like a bearish signal.
|
| Access control and user level logging seem like kind of basic
| feature requirements for a military C2 system? And Lattice
| isn't a completely immature product either IIRC.
| Seattle3503 wrote:
| Does anyone have a link to the memo?
| jpace121 wrote:
| I would be very surprised if it was publicly available.
| moron4hire wrote:
| Yeah, there's no way anyone would ask or it'd get approved
| for public release. Not because it's necessarily controlled
| information (though suspect it probably is), but what would
| be the point? Things get released to the public only when
| there is a particular need to tell the public something and
| everything else defaults to sitting on some janky ass
| SharePoint site until everyone forgets about it.
| wbl wrote:
| FOIA is a law for a reason
| DonHopkins wrote:
| Given these blustering charlatans' track record with
| security, I would be very surprised if it was NOT publicly
| leaked, sitting somewhere on an open cloud server, put there
| by some petulant incel child who calls himself Big Balls.
| kspacewalk2 wrote:
| A prototype doesn't have fine-grained access control. Is that
| pretty much the story here?
| asadotzler wrote:
| Security as a later add-on is failure.
| lysace wrote:
| Build one to throw away.
| Quarrelsome wrote:
| that would be best practice but that wouldn't be what I
| often see happen.
| relaxing wrote:
| In fact, build one to throw away is the default in the
| defense space.
|
| Odds are this one will join the scrap heap of projects
| that never make it to operation, like thousands of
| systems before it.
| kspacewalk2 wrote:
| Like all excessively categorical one liners, yours is of
| little use in practice.
| jandrewrogers wrote:
| What's the issue? Everything about this is normal and expected
| when prototyping new capabilities for DoD.
|
| DoD intentionally pushes hard to get testable capabilities as
| early as possible to shorten feedback loops, understanding that
| features ancillary to the capability will be limited, stubbed
| out, or implemented using a stopgap that you would never use in
| production. This will all be cleaned up in the production
| implementation once everyone is happy with how the capability
| works. Basically an agile customer development approach, similar
| to what is used in startups.
|
| In my experience, the fine-grained control and security features
| are _never_ implemented in the prototypes. This can be extremely
| fussy and slow development that isn 't needed to evaluate
| capability. It also requires a lot of customer involvement, so
| they usually aren't willing to invest the time until they are
| satisfied that they want to move forward with the capability. The
| security architecture is demonstrably the kind of thing that can
| be mechanically added later so DoD takes the view that there is
| no development risk by not implementing it in the prototype.
|
| There may be fair criticisms of the system but it looks like the
| article is going out of its way to mislead and misrepresent.
| ranadomo wrote:
| This is an absurd statement to make about a DOD program.
| Securing communication is communication in the most adversarial
| environment imaginable. There are thousands of problems that
| only emerge once cryptographic authentication and authorization
| are enabled. This isn't a b2b sass app where you can just add
| an "auth layer" once the api is built out. It's passing
| mission-critical messages through signal-jamming and
| unimaginably hostile imitation scenarios. Many DOD programs are
| built as prototypes that don't ever factor security in the
| architecture, and then have massive problems and delays trying
| to implement it later. DOD cyber acquisition is run by the most
| incompetent clowns on earth. The only reason they don't know
| how terrible their software is, is because they're not capable
| of detecting how fundamentally compromised their systems are,
| and China and Russia are not exactly white-hats looking for a
| bounty.
| wyldberry wrote:
| It is not absurd, this is the standard for rapid prototyping
| in the DoD. Given that Palantir already has a strong track
| record for authn/z inside their systems used across the DoD,
| LEO, and Intelligence Agencies. It's not an untread,
| uncharted path for these organizations.
| jandrewrogers wrote:
| I have first-hand experience with the problems of designing
| systems for adversarial denied environments. These are
| largely orthogonal to the problem of access controls. The
| low-level communication security and channel capacity is
| handled almost exclusively by external trusted modules,
| systems built on top of them only have to concern themselves
| with the behavior of these modules.
|
| There is a separate concern around denied data environments
| in the software realm but that is not on many people's radar.
| Most software devs would not know where to even start to
| protect systems from this.
|
| A tension with access controls is that if you implement it to
| the level of granularity the most demanding parts of DoD say
| they want, it never actually gets used because it is too
| complicated for users to reason about and manage. Or worse,
| they make mistakes and leak data _because_ it is complicated.
| A simpler model is always implemented on top of it. At the
| same time, fine-grained and scalable access controls impose a
| high operational cost in the software even if they are not
| being used and some parts of DoD care a lot about software
| performance. Many parts of DoD are realistic enough to not
| want to pay for access controls they 'll never actually use.
|
| On top of this, security architecture is designed to be
| somewhat pluggable because different users will have mutually
| exclusive design requirements for the security architecture.
| It would be nice if this wasn't the case but it is what it
| is.
| bitwalker wrote:
| > There is a separate concern around denied data
| environments in the software realm but that is not on many
| people's radar. Most software devs would not know where to
| even start to protect systems from this.
|
| The concept of a denied environment is pretty clear to me
| when it comes to physical space, or radio communications -
| but could you clarify what you mean by a "denied data
| environment"? I have some notion of what you _might_ mean,
| but I can't find a clear definition of the idea anywhere.
| toss1 wrote:
| >>The Army should treat the NGC2 prototype version as "very
| high risk" because of the "likelihood of an adversary gaining
| persistent undetectable access," wrote Gabrielle Chiulli, the
| Army chief technology officer authorizing official.
|
| >>One application revealed 25 high-severity code
| vulnerabilities
|
| What part of the above two quotes are hard to understand?
|
| >>"The security architecture is demonstrably the kind of thing
| that can be mechanically added later so DoD takes the view that
| there is no development risk by not implementing it in the
| prototype."
|
| Are you actually serious about this? Because to me, that is the
| most nonsensical thing said in a post of nonsensical things.
|
| ARCHITECTURE is the FIRST thing that needs to be determined --
| what is the structure of the modules, how they communicate, and
| what underlying tech will be used? Sure, if you are making a
| true proof-of-concept prototype you can skip it but no one
| would be discussing the above kinds of issues evaluating a POC.
| Tacking on some afterthought of a 'security architecture' at
| the end of a development project is a recipe for disaster in
| countless ways.
|
| And yes, you said "fine details" added later; agree. But even a
| prototype of a secure communications system the thing must AT
| LEAST show some security architecture; I mean at least show you
| can keep Joe-user from accessing Root privs... here, they said
| anyone can access anything. That is not fine details, that is
| simply not even close to meeting the spec.
|
| (and yes, I do DOD work, and your account is not even close to
| how I've seen it work)
| dkarl wrote:
| > no one would be discussing the above kinds of issues
| evaluating a POC
|
| Um, yeah, they would be communicating that it's a bad idea to
| put sensitive data into it. You have to make that stuff
| explicit, or somebody will misuse it.
|
| I'm looking for the scandal here. Did the contractors
| misrepresent the prototype systems as being secure in ways
| they're not? Is the project behind schedule, and proper
| authorization controls were supposed to be implemented by
| now? Is the prototype system being improperly used to share
| sensitive data? Any of those would be concerning, but the
| article doesn't make any of those claims.
|
| All I see is, a prototype version of software doesn't have
| all the capability that it will need when it's finished.
| toss1 wrote:
| The scandal here is that multilevel security MUST be a core
| of the product from the outset
|
| The evaluations quoted in my previous comment shows it is
| VERY obvious the Army _expected_ to see at least the
| capabilities to prevent "an adversary gaining persistent
| undetectable access", _expected_ to see capabilities
| preventing low-level users from accessing higher-clearance-
| level materials, and did _not expect_ 25+ high-severity
| code vulnerabilities, and all of those expectations were
| failed by the suppliers.
|
| True, the article did not cite info about the exact
| specifications and expected operational readiness level at
| this date detailed in the contracts.
|
| However, we _can_ safely assume the Army officers who wrote
| the scathing memo _do_ have access to and understand the
| contractual expectations, and wrote the report in the
| proper context of the contractual expectations.
|
| Instead, you want to do a rhetorical sleight-of-hand to
| claim since the article necessarily is not a complete
| report (it's a short news article), the missing bits mean
| the Army officers are just speaking out of context and
| there is no scandal. That is wrong
| dkarl wrote:
| Can we even safely assume that the memo was scathing?
| That's an interpretation by the reporter. You would think
| that they would be able to quote some damning fact or
| accusation from it, or at least some harsh language, if
| it really was "scathing."
| toss1 wrote:
| Yes, we can safely assume that, since I was largely
| ignoring the press piece and directly using only the
| quotes from the Army Report.
|
| Below are some of the direct quotes from the Army Report
| quoted in the article.
|
| >> "fundamental security" problems and vulnerabilities,
|
| >> should be treated as a "very high risk
|
| >> "We cannot control who sees what, we cannot see what
| users are doing, and we cannot verify that the software
| itself is secure,"
|
| >> "very high risk" because of the "likelihood of an
| adversary gaining persistent undetectable access," wrote
| Gabrielle Chiulli, the Army chief technology officer
| authorizing official.
|
| >> Any user can potentially access and misuse sensitive"
|
| >> One application revealed 25 high-severity code
| vulnerabilities. Three additional applications under
| review each contain over 200 vulnerabilities requiring
| assessment, according to the document.
|
| >> "Any user can potentially access and misuse sensitive"
| classified information, the memo states, with no logging
| to track their actions.
|
| The report on a supposedly secure communications system
| prototype contains these exact criticisms about 1)
| fundamental lack of access control for users of
| classified info at multiple levels, 2) complete lack of
| logging for any access authorized or unauthorized, and 3)
| likelihood of an adversary gaining persistent
| _undetectable_ access.
|
| To anyone with a clue, this is exactly the opposite of
| what a secure military communications system needs.
|
| For people on a site who supposedly care about software
| quality to defend such obvious slop is ... surprising. It
| looks from this collection of quotes that Palantir and
| Anduril just tossed over some Slack/Discord clone and
| thought they'd "wow" the Army with the new (presumably to
| those backwards customers) tech and slap on some security
| later, and are now finding out their customer is a bit
| more sophisticated than they expected.
|
| There are very good reasons consumer tech is often
| unsuited for military use.
|
| (OFC, if the press piece is lying about the direct quotes
| and numbers from the document, we have an entirely
| different discussion, but no one here has argued that is
| the case)
| Grimblewald wrote:
| You're fighting the good fight, palantir bots out in force in
| this one.
| toss1 wrote:
| Yes, thanks, I noticed
|
| Especially surprising that on a site unmatched by any other
| in the near-reflexive liberty and anti-surveillance
| attitudes, one of the most aggressive and far-reaching
| surveillance corporation finds such support...
| reissbaker wrote:
| I think what's happening here is:
|
| 1. The Army gave a reasonable analysis of the security issues
| with the prototype.
|
| 2. This is normal.
|
| 3. But most people don't have experience in this field.
|
| 4. A reporter got access to the report, and published the most
| salacious-sounding parts -- and if you don't know that this is
| normal, it sounds really bad.
|
| 5. Oh no, the sky is falling. Click here to watch our ads, oops
| I mean, to read all about it.
|
| Generally my read on tech-adjacent reporters is they have very
| little understanding of what they're reporting on, and mostly
| try to manufacture outrage to get clicks.
| appreciatorBus wrote:
| Also true of non-tech-adjacent reporters!
|
| The impulse may be stronger in some and weaker in others, and
| the incentive structure at their outlet may be stronger or
| weaker, but all of them know, even subconsciously, what type
| of stories are likelier to capture attention, make $ for the
| outlet and hopefully return a portion of that to them.
| Outrage is high the list of qualities that guarantee
| attention.
|
| Since learning about social media algorithms, I've come to
| think of all news media, even old timey newspapers, in the
| same light. IMO The only difference between TikTok's For You
| page and newspaper headlines from 200 years ago was the
| precision of the engagement feedback and the latency.
| MountDoom wrote:
| > Also true of non-tech-adjacent reporters!
|
| It's true for _everyone_. Over the years, I 've been on the
| business end of several "tech outrage" stories that made
| the headlines on HN, and over time, became a sort of IT
| canon: "company X did something really bad".
|
| And they all had the same origin: a party with an ax to
| grind latched onto a fairly boring story, distorted the
| facts to tell a narrative, and that narrative "clicked"
| with everyone else because it confirmed their preexisting
| biases.
|
| It doesn't mean that there are no companies that are truly
| evil or incompetent, but I'd wager is <50% of the ones that
| get raked over the coals here and elsewhere.
| reissbaker wrote:
| Yep -- sadly the most effective cure is being on the
| receiving end of one of the stories, and realizing how
| bad faith they are.
|
| I think the U.S. slander laws are probably too light. I'm
| generally supportive of the idea that "democracy dies in
| darkness," but I think we've gone further than that in
| allowing people to lie in public for money. I don't think
| _that_ helps democracy, and in fact probably hurts it. I
| think anyone, anywhere on the political spectrum, can
| point to damning examples of the other side lying for
| their cause, and I think we 'd all be better off if that
| stopped.
| kingforaday wrote:
| Re: Benjamin Franklin and the Pamphlet Wars
| snerbles wrote:
| Also the Yellow Press drumming up support for the
| Spanish-American War.
| thfuran wrote:
| https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect
| Grimblewald wrote:
| I dunno, the process is normal but the issues raised are
| extreme. Too extreme. I'd expect things like "in edge cases X
| vulnerabilities start being an issue" rather than "at any
| point, anyone, can gain undtected full access to all our live
| infrastructure, equipment, and troop poaitions"
|
| it feels like the bar for what are acceptable toothing issues
| is set unrealistically low here.
| 1-more wrote:
| Is NGC2 meant to replace JTRS? Did JTRS ever actually ship
| broadly and replace SINCGARS?
|
| Wow holy calamity lol JTRS never shipped. Paid a lot of mortgages
| though.
| Jtsummers wrote:
| JTRS had so many problems. It was spectacularly badly managed
| by its program office. I'll repeat what I've written perhaps
| too many times here on HN: DOD program offices are not capable
| of handling IT (software-centric) acquisitions efforts. They
| reliably fail.
| mandevil wrote:
| The reason that Rumsfeld's second term as SecDef marks him as
| the worst to ever hold the position (1) is that at least the
| other guy who oversaw the US getting into a decades long morass
| (McNamara) delivered some effective weapons. Forcing the USAF
| to buy the F4H, the USAF half of the 'vark, Nimitz class
| carrier, Spruance class destroyer, etc. were all reasonably
| successful weapons systems that McNamara was largely
| responsible for, in bureaucratic terms.
|
| Donald Rumsfeld's term managed to get the US into a decades
| long morass _and_ basically all of his procurement plans failed
| (FCS, JTRS, EMALS, LCS, EFV, DDG-1000). Rumsfeld 's best
| program outcome (LCS) was still worse than McNamara's worst
| (F-111).
|
| 1: Not counting the current occupant where we can't fully judge
| him yet, but he's not doing well.
| SJC_Hacker wrote:
| Were those programs really on Rumsfeld, or was it the
| Congress/Senate ?
| mandevil wrote:
| The consistent emphasis on the value of speed and mobility
| over the other parts of the combat triangle (mobility-
| firepower-survivability)- to the detriment of them as
| weapons systems- is a sign that there was a coherent
| influence and direction being put on those programs, to
| their detriment, by the SecDef's office.
|
| Basically, Rummie's approach was to emphasize speed and
| mobility over all other aspects of fighting, and it created
| ships with high speed and little sustainability or
| effective mission packages (LCS) and ground vehicles which
| were hideously expensive and way too vulnerable (EFV, FCS).
| Some things that happened under him (like the F-22 line
| being closed permanently) were more due to Congress' than
| him, but those programs were closely associated with him
| and his office at the time, and were gigantic CF's that, in
| the best case, ended without a single production unit ever
| reaching service.
|
| I say this as someone who worked in Army procurement doing
| FCS things. In my opinion as someone who was there, it was
| Rumsfeld's baby, and it was such a disaster _both_
| Presidential candidates in 2008 promised to kill it. And it
| deserved that killing.
| mmaunder wrote:
| If mandatory access control (MAC)is the expectation and these
| guys haven't built that in from the ground up, they're going to
| find it very hard to bolt on later.
| terminalshort wrote:
| Every prototype I've ever built has been a throwaway POC. So
| nothing to bolt on later because the production version is
| built from scratch. I write a very different type of software,
| though, so not 100% sure if applicable here.
| microdrum wrote:
| These are forcememed companies, unfortunately. Neither Palantir
| nor Anduril make a single thing that China doesn't, and neither
| one makes a single thing at attractive cost that would intimidate
| China in a conflict. They could disappear tomorrow with no impact
| to US military lethality.
| terminalshort wrote:
| Source?
| aerostable_slug wrote:
| Based on my direct personal experience, this is a
| counterfactual statement.
|
| It's sad when partisan politics so overwhelms discourse that
| people just make up nonsense because they don't like the CEO of
| a company.
| aegypti wrote:
| "I personally don't think that's true, and it upsets me you
| believe it's true" isn't really an argument though.
|
| What are they making that would intimidate China, that China
| doesn't already?
| aerostable_slug wrote:
| Combat-proven software that helps put warheads on foreheads
| in compressed timescales. I'm not talking about development
| projects or what could happen, I'm referring to
| applications that are being used right now.
|
| There's a massive difference between something in a lab or
| in a paper presentation and code that is running in
| production and provably works. There are lots of
| individuals pushing up daisies that would attest to the
| effectiveness of Palantir's applications if they could
| still speak.
| relaxing wrote:
| Dude, gross. You don't have to talk like that.
| chermi wrote:
| 1) lol 2) source for such confident claims 3) even if true, can
| they potentially make existing tech cheaper than competitors?
| Competition is good for price. If so, still an "impact on US
| military" 4) see 1.
| mhb_eng wrote:
| Somewhat old news, as a more recent article highlights that those
| issues have since been resolved.
|
| https://breakingdefense.com/2025/10/army-says-its-mitigated-...
| aelaguiz wrote:
| Whoever didn't get those contracts must be unhappy. That's how I
| read this type of story.
| stephc_int13 wrote:
| I don't think that anyone with first hand intel would be in the
| position to safely leak what is happening at those companies or
| their contractors, but I have the intuition that their founders
| are larping more than anything else.
|
| Nice toys. Not sure the tech has anything substantial or
| innovative under the hood.
| anondawg67 wrote:
| "larping" when there are jobs at both contractors that require
| top secret / sci... sure...
| _whiteCaps_ wrote:
| Naming military technology after things in LOTR completely misses
| the point of the stories. Tolkien is spinning in his grave.
| dlivingston wrote:
| Can you expand on this?
| _whiteCaps_ wrote:
| Anduril is Aragorn's sword.
|
| Palantiri are the seeing stones.
|
| I think this article has a good summary of Tolkien's
| experiences in the war:
| https://en.wikipedia.org/wiki/The_Great_War_and_Middle-earth
| rout39574 wrote:
| One of the important roles of the Palantir was that they were
| scrying devices. Sauron gained some influence over them
| warped the impressions of those who used them, by affecting
| what they could and couldn't see. It was part of the subtle
| misinformation he used to twist people into alliance with
| him.
| roywiggins wrote:
| it's at least a little funny to name your company in the
| business of secure communication products after a fictional
| communication device with a famous security flaw
| SJC_Hacker wrote:
| The novels, and movies to some extent hint heavily that
| industry/technology was used for evil far more than good, and
| in general the "forces of good" were more "attune with
| nature" than their opponents
|
| Example - Saruman clear cutting a good portion of Fangorn
| forest in order to strip mine it and produce weapons.
|
| Paywalled article in the Atlantic on this subject
|
| https://www.theatlantic.com/technology/archive/2012/07/fall-.
| ..
|
| Brief exerpt:
|
| 'So it makes sense, then, that the chief exponents of
| technology in The Lord of the Rings are a demonic figure bent
| on world domination (Sauron) and a wizard (Saruman).
| Treebeard, the Ent or tree-shepherd, says of Saruman, "He is
| plotting to become a Power. He has a mind of metal and
| wheels; and he does not care for growing things, except as
| far as they serve him for the moment." '
| bpodgursky wrote:
| Raising a PR disaster for problems with iterative prototypes is
| how you end up with traditional defense contractors with decade-
| long waterfall development cycles designed for neurotic ass-
| covering rather than effective feature delivery.
|
| Please don't sabotage national defense just for cheap shots at
| Palantir. This is the right way to develop defense tech. Make a
| prototype, see what works, iterate. Come on.
| sauercrowd wrote:
| This.
|
| Criticising a prototype that it doesn't do all the things of a
| finished product is... interesting
| indemnity wrote:
| Tactics straight out of the Simple Sabotage field manual. You'd
| think the audience of this website understood modern fast
| feedback loop iterative development to explore the problem
| space.
| jakedata wrote:
| I thought the Department of WAR was switching over to a hacked
| version of Telegram Messenger for all its secure communications.
| If you see someone you don't know in the chat, don't worry it's
| probably just a journalist. Probably... (edited to add that this
| is based on actual events, not snark)
| mway wrote:
| This is admittedly petty, but I'm getting tired of bad actors
| reappropriating nerd lore (LotR) for nefarious products.
| snickerbockers wrote:
| But thats the palantir.
| RatchetWerks wrote:
| I've directly worked in this space. This article is pure tabloid-
| style reporting.
|
| It sounds like they are testing prototypes, and it's not ready
| for mass fielding. Nothing new here.
|
| Access/permissions control in military applications is VERY
| different when compared to the consumer or B2B space.
|
| It takes real field testing to figure what is best for the
| customer needs.
| bluelightning2k wrote:
| Admittedly my experience of what a battlefield comms system would
| look like comes only from games, but I think it needs emotes,
| flashy red low health indicator, and microtransactions.
| fishmicrowaver wrote:
| Doesn't matter. Go to DC and get a tour of the Pentagon. You have
| a 50/50 chance of seeing Palantir/DOD counterparts physically
| hugging and talking about eachothers personal lives.
| Congratulations to them, they've won the game. And congrats SV,
| the rest of you hang up your phones when you might be the only
| plausible competitor for the next bid, because you think staying
| away from gov protects your values. All you're doing is letting
| the absolute worst of companies win.
| snickerbockers wrote:
| Are you under the impression that silicon valley is some
| bastion of ethics and protector of liberty?
| fishmicrowaver wrote:
| No and I'm being unfair in my super hot take. However, many
| companies turn down opportunities, and were left with
| ...Palantir.
| newfriend wrote:
| Everything has flaws. This smells like a hit piece.
| avazhi wrote:
| 'May have flaws' would be the accurate title but that wouldn't
| get CNBC the clicks.
|
| Crying about being unable to audit a propriety system isn't the
| same thing as demonstrating that the system itself is flawed.
| AfterHIA wrote:
| Lord Of The Rings obsessed computer dorks shouldn't be designing
| equipment as civilians that is life-and-death critical for
| Marines and soldiers. Prove me wrong.
|
| https://en.wikipedia.org/wiki/Skin_in_the_Game_(book)
| nikolay wrote:
| I'm eager to see how Barracuda fails to make any difference in
| attacking Russia directly! Luckey needs to be grounded, literally
| - just like all arrogant assholes!
| photochemsyn wrote:
| Oh this is just the Israeli back door. What did you expect
| really?
|
| > "The Army should treat the NGC2 prototype version as "very high
| risk" because of the "likelihood of an adversary gaining
| persistent undetectable access," wrote Gabrielle Chiulli, the
| Army chief technology officer authorizing official."
___________________________________________________________________
(page generated 2025-10-03 23:01 UTC)