HNHacker News
TopNewBestAskShowJobs

asciilifeform

3,974 karma · joined February 21, 2007

submissionscomments
asciilifeform··on Owner of Symbolics Lisp machines IP is interested in a non-commercial release
DKS doesn't own the IP, and wouldn't sell (to me at least) any unpublished sources, schematics, etc. for any price at all.

As of several years ago, though, he was willing to part with a number of new-old-stock Ivory CPUs, for roughly the cost of their weight in gold. (And periodically offers Ivory machines for sale on eBay. Here's what these look like: http://www.loper-os.org/?p=2857 )

asciilifeform··on Owner of Symbolics Lisp machines IP is interested in a non-commercial release
AFAIK it's still owned by one John Mallery, a wealthy MIT prof with military and intelligence establishment connections.

My favourite "conspiratorial" hypothesis concerning this question is that the Symbolics IP was ordered to be perma-buried for "national security" reasons (as it threatens to make practical systems with capabilities much superior to today's state of the art, but running on early 1990s IC fab processes) and that Mallery (who, per rumour, purchased the IP for next to nothing via a backroom deal) was the designated undertaker.

AFAIK it is still unknown whether the chip die masks, source for (the parts not included on the tapes/CD) os/compiler/IC workflow -- was even preserved to this day.

asciilifeform··on Owner of Symbolics Lisp machines IP is interested in a non-commercial release
I have 5 Symbolics Ivory CPUs (1 of which is in a working MacIvory III card.)

Recently I found that not far from where I live, one can rent time on an electron microscope for a very reasonable price. But the lab in question does not have the gear needed for decapping and delayering.

If someone knows of a reasonably-priced (mid five-figures or less) commercial facility that will do it with a good chance of success, I'd be interested. But I won't be sending these chips to some random person who may or may not be able to (or even make an honest attempt) to do the job, as I have only this small handful of units and currently no way to get more.

asciilifeform··on “Pest” vs. 0xFE
Indirect messages must be marked as hearsay, given as (barring the use of asymmetric crypto, which is AFAIK impossible to carry out at Gb+/s line-rate without specialized hardware) there is no way to verify, in any useful sense, their authorship.

The most that can be done to infer authenticity of indirect messages is to see whether such a message rejects the authorship of a known previous message having the same handle -- via the SelfChain. In virtually any case of handle collision, this will occur.

Re: floods -- a station only processes messages from a peer. So in fact in all cases the proximate cause of a flood is identifiable, and you can "UNPEER" and "GAG" him.

Flooding by a peer is annoying, but is not what people normally think of as "DDOS" (normally the term implies a flood of rubbish received directly from unauthenticated third parties.)

How liberally to peer -- is a matter for an individual station operator. Peering with every passing acquaintance has obvious down-sides.

asciilifeform··on “Pest” vs. 0xFE
> HTTPS on content only sides is primary about preventing people with tampering with the website

"people" here specifically excluding Verisign & its successor racketeers, the NSA (plus bananistani national equivalents thereof).

> in ways which potentially can hurt you from just opening them

Running shitware is optional.

> It doesn't prevent JS injected into your side from being executed

The only solution to malicious JS is... to switch off JS. Asking people you don't know to pay the cert tax does not somehow guarantee that their JS is not malicious.

> ... check the signature before loading/parsing any content it isn't secure.

"Secure content" is what you obtained from someone you actually trust and verified with a pubkey you received out of band (ideally -- meatspace). All other content may as well have been authored by evil martians, despite any pretense to the contrary.

> by now pretty much not-undoable not-decentralized HTTS infrastructure

What part of "Where I still have the freedom not to use the Reich's master-keyed pseudocryptographic garbage - I will not use it" is hard to understand?

IMHO it is quite strange that the "HTTPS-everywhere" nonsense isn't immediately understood by everyone for what it is -- simply Google's latest effort to stymie ad-blocking (with the applause of NSA, whose mission today consists largely of efforts to retard the development of actual - i.e. not masterkeyed and not escrowed - crypto.)

asciilifeform··on “Pest” vs. 0xFE
Only validly-signed (from one of the station's peers) messages move past the decoding stage ("prologue"), and of these only ones with timestamp +/-15min. of station's time; these finally searched for in dedupe queue; and at the end may be rebroadcast, if so marked, to the station's peers strictly.

You can be DOSed, so to speak, by one of your peers, but not DDOSed by a third party -- a reasonable machine can reject signature-failing or replayed-stale packets from multiple NICs at line rate, so long as your WOT is compact (i.e. less than 100 entries). This of course remains to be experimentally tested. Currently there is only an algorithm!

asciilifeform··on “Pest” vs. 0xFE
At the moment even the algorithm isn't finished.
asciilifeform··on “Pest” vs. 0xFE
This is correct, and is described in the article ("Kelvin versioning".) The concept is not original to the author.
asciilifeform··on “Pest” vs. 0xFE
"every message is rebroadcasted by everyone" is not factual per the spec.
asciilifeform··on “Pest” vs. 0xFE
Author of linked article speaking. (How it ended up here -- I have no idea, I'm rather surprised that it was of interest to more than the 3 people for whom it was written.)

This flame is doubly funny given how the article specifically concerns algorithms for possible decentralized cryptonets.

HTTPSism is deliberately broken on my WWW, to annoy unthinking servants of the PKI Reich.

For the thick: at the start, there is a PGP-signed copy of the text offered. And yes I in fact live and die by my PGP identity. And not Verisign et al's NSA-controlled PKI horror, no.

asciilifeform··on “Pest” vs. 0xFE
"V" is a very simple versioned publication system (there's an explanatory link in the article.)

Vpatches are backwards-compatible with ordinary gnupatch. (can simply execute "patch -p0 < nameofpatch" for the sequence.) "V" has nothing directly to do with Bitcoin.

asciilifeform··on Why Hypercard Had to Die (2011)
I do have a multi-chapter series on constant-time integer arithmetic -- indeed tagged incl. "bitcoin", as it is meant to be used in (among other places) a rework of the client.

You evidently spent at most 3 seconds reading the link; wouldn't kill you to spend 5 seconds and see what is behind the tag.

asciilifeform··on Why Hypercard Had to Die (2011)
One of the attractions of Hypercard was that a "stack" (document) was entirely self-contained; and would always behave exactly the same on any machine where HC could run.

Notably, would run without any need for servers (or, worse, the subscription-and-lock-in "services" ubiquitous today -- arguably the 1980s "computer revolution" was strangled in the cradle, and we've gone most of the way back to 1970s-style time-sharing now: how many phone apps etc. will run usefully without a net connection? The "smartphone" is essentially a small "glass TTY", rather than personal computer in the '80s sense.)

I've run HC stacks written 30+ years ago. How many current-day "web app" documents will be readable as-found 30 years from now? For that matter, I've paid for iOS apps that would no longer execute after half a year (on account of Apple's "API changes", or in some cases -- author's "call home" server fell down and did not get up, etc.) Permanence (in the most basic "I paid for this and it ought to be usable for so long as any compatible iron remains functional" sense) is no longer part of the software commercial culture, and one is likely to be laughed at for merely raising the question.

asciilifeform··on Why Hypercard Had to Die (2011)
Doubt it: I have not written at Kuro5hin. (Possibly linked there at some point, however?)
asciilifeform··on Why Hypercard Had to Die (2011)
Author of linked piece speaking. Seems like many readers continue to miss the essential point, just as they did in 2011:

Hypercard wasn't a gem of graphic design (1-bit colour, plain line graphics) or of programming language design (one of the many laughable attempts at "natural language programming") or of high-performance number crunching... but it was simple. I.e., the entire system was fully covered by ~100 pages of printed manual. It fit in one's head. (And did not take 20 years to fit-in-head, either, an intelligent child could become "master of all he surveys" in a week or two.)

Where is the printed manual for the current MS VB, or the WWW's HTML/JS/CSS/etc stack (yes including all browser warts), or for any of the other proposed "replacements" ? How many trees would have to be killed to print such a manual, and would it fit in your house? Could you read it cover to cover, or would die of old age first?

asciilifeform··on Why Hypercard Had to Die (2011)
Author of linked site speaking. Are you sure you are reading the same page? I had half a dozen articles re Bitcoin, the last in 2014...
asciilifeform··on The Google H1 Fritz Chip
Intel. No thanks.
asciilifeform··on The Google H1 Fritz Chip
The Infineon couldn't force a boot ROM update via USB-C.
asciilifeform··on The Google H1 Fritz Chip
My current alternative appears to be to desolder the Cr50 and fabricate harmless replacements (to e.g. init 3.3v rail).

So naturally voids warranties.

> firmware updateable, but not for you

Finally, honesty. It's a Tivo.

asciilifeform··on The Google H1 Fritz Chip
The Cr50 does not limit itself to user key storage.

It turns the USB-C ports into always-on NSA-keyed backdoors (anyone in possession of the private RSA key, can reflash all three flash ROMs in the machine with whatever he likes, via the external ports, which cannot even be cemented shut, as the machine charges exclusively from USB-C.)

asciilifeform··on The Google H1 Fritz Chip
Why lie to the public ? Pulling the battery does enable rewrite, by the user, of the AP ROM, but not the Cr50 -- the latter remains Tivoized. And every owner of this machine can verify this with his own hands, it is not even necessary to build the USB debug cable.

The Cr50 accepts firmware updates at all times, but only when signed with Google's RSA key.

asciilifeform··on The Google H1 Fritz Chip
You are quite right, I do not work at your factory (TBH, I'd rather work for, e.g., Monsanto...)

Instead, I'm a reluctant purchaser of your hardware (the market is completely devoid of alternatives, if I go to buy a 6-core ARM64 laptop with a IPS display, it's the Chromebook or the highway). A purchaser who would like to actually use what he paid for. And this means the removal of all golden-key backdoor garbage, in the AP, EC, and Cr50 ROMs.

And yes this includes the FBI-subpoena-keyed "upgrade" capability, the AP ROM write-protect override, the I2C/SPI bus mastering, the locked-from-all-but-the-anointed-few console, etc.

I couldn't care less about user-installed "TPM secrets", disk encryption, etc. I get these boxes brand-new. What I want is to wipe the Cr50 and install a routine that simply handles the power button, 3.3v bringup and whatever else is absolutely required for the box to run, under full owner control like the old Chromebooks that had no Cr50.

asciilifeform··on The Google H1 Fritz Chip
Do you particularly care whether the backdoor was installed at Google's initiative, or Trump's ?

The golden key exists, and will be used.

asciilifeform··on The Google H1 Fritz Chip
The details are openly published in Google's Cr50 sources, linked from the article.
asciilifeform··on The Google H1 Fritz Chip
Cr50 has replaced the old Infineon TPM, which the above link concerns.
asciilifeform··on The Google H1 Fritz Chip
You can't. Thank 20 years of apathetic consumers, such as the people in this comment thread.
asciilifeform··on The Google H1 Fritz Chip
Cr50 is quite different from the Infineon et al TPM item commonly found in x86 boxes. It is able to rewrite AP and EC firmware, overriding the advertised write-protect feature; access the microphone; etc.

No reason to take my word for it: I recommend to read Google's source, I have linked to the most interesting routines.

asciilifeform··on The Google H1 Fritz Chip
Google, quite untypically for large manufacturers, put their golden key backdoor in plain sight, inside published source. (Apparently, "only a terrorist!" would read it?)
asciilifeform··on The Google H1 Fritz Chip
> It's plenty easier to buy a hackable and open by default platform...

Pray tell, where can I buy a laptop (of new, rather than vintage, manufacture) without blobs and master keys?

asciilifeform··on The Google H1 Fritz Chip
Author of linked article speaking (supposing anyone is still reading, thread already marked as spam?)

I recommend to actually read Google's published Cr50 sources -- no reason to take my word for it. All of the functionality I described -- and more -- is there, plain as daylight, with comments. Including the backdoor pubkeys.

Page 1 of 26Next →