The problem that multi generational projects like this always have is tech debt. Any library/dependency chosen by the previous generation might be unmaintained for decades until it falls through the cracks and someone notices it.
Heretrix, for example, was written in a very old "Java way" to do it. They have also lots of services that were built in the PHP4 age, with globals by default and stuff like that.
Always keep in mind that whatever you choose, it's a bet, essentially. Over time you'll realize that different language ecosystems have different aligned or misaligned goals to your project. Don't choose libraries because of hype, choose them because of maintainability.
I dunno about the state actor hypothesis, but if there is, it all sounds like Charles Stross's description of future cold war in Halting State:
"And that's the twentieth-century model, what they used to call an electronic Pearl Habour. Things have moved on since then. Footnotes inserted in government reports feeding into World Trade Organization negotiating positions. Nothing we'd notice at first, nothing that would be obvious for a couple of years. You don't want to halt the state in its tracks, you simply want to divert it into a sliding of your choice."
Who knows what will appear after the archives are restored?
Heh, yeah. It was probably "the Entity". An AI that subtly nudged human affairs as the opening salvo of its Big Plan. Masquerading as hapless hackers of course hahaha! :)
Hah! As if they need ideas. But that's not the point, how possible is it?
Re your comprehensive edit, I totally am on board with that tech choice idea. It's a bet, avoid the fads, pick stuff that's robust (or at least a fit for your possible futures)
I'd say we have to differentiate between human error as an attack surface and software bugs / vulnerabilities as an attack surface here.
Software-wise I wouldn't know where to start, honestly, because the internet archive as a project is so vast [1] that it's hard to get an architectural overview of how the pieces are glued together. Unifying the tech stack seems to have been no concern at all in its development...
But from a pentesting perspective I'd try to find vulnerabilities in the perl based services first, then Java, then PHP, then NPM and so on... because older projects tend to have a higher likeliness of being unmaintained or using outdated libraries.
Comments
how vulnerable is IA to some malicious actor who wanted to rewrite history or run an 'information cleansing' operation?
- take offline
- purge 'problematic' archives
- return to service
is that impossible? are there redundancies to make this very hard?
Don't give the SVR any ideas, man.
The problem that multi generational projects like this always have is tech debt. Any library/dependency chosen by the previous generation might be unmaintained for decades until it falls through the cracks and someone notices it.
Heretrix, for example, was written in a very old "Java way" to do it. They have also lots of services that were built in the PHP4 age, with globals by default and stuff like that.
Always keep in mind that whatever you choose, it's a bet, essentially. Over time you'll realize that different language ecosystems have different aligned or misaligned goals to your project. Don't choose libraries because of hype, choose them because of maintainability.
I dunno about the state actor hypothesis, but if there is, it all sounds like Charles Stross's description of future cold war in Halting State:
Who knows what will appear after the archives are restored?
Heh, yeah. It was probably "the Entity". An AI that subtly nudged human affairs as the opening salvo of its Big Plan. Masquerading as hapless hackers of course hahaha! :)
Hah! As if they need ideas. But that's not the point, how possible is it?
Re your comprehensive edit, I totally am on board with that tech choice idea. It's a bet, avoid the fads, pick stuff that's robust (or at least a fit for your possible futures)
I'd say we have to differentiate between human error as an attack surface and software bugs / vulnerabilities as an attack surface here.
Software-wise I wouldn't know where to start, honestly, because the internet archive as a project is so vast [1] that it's hard to get an architectural overview of how the pieces are glued together. Unifying the tech stack seems to have been no concern at all in its development...
But from a pentesting perspective I'd try to find vulnerabilities in the perl based services first, then Java, then PHP, then NPM and so on... because older projects tend to have a higher likeliness of being unmaintained or using outdated libraries.
[1] (~242 public repositories) https://github.com/orgs/internetarchive/repositories
I hope that Google (for instance) has an occasional snapshot of everything tucked away somewhere on a tape in Norway or somewhere. Like the seed bank.
- openly speculate the tactic to preemptively address concerns
Exactly! Red-team the situation to identify weaknesses, build defenses and devise overall strategy! :)
Yeah, last time I checked they weren't doing any timestaping.
They definitely should.