For clarification, here's the actual quote from the article describing the process:
> I verified the issue with the minimum access necessary to confirm the scope - and stopped immediately after.
No notion of a script, "every password" out of a set of a single default password may be open to interpretation, no mention of data downloads (the wording suggests otherwise), no mention of actual number of accesses (the text suggest a low number, as in "minimum access necessary to confirm the scope").
Still, some data was accessed, but we don't know to what extent and what this actually was, based on the information provided in the article. There's a point to be made about the extent of any confirmation of what seems to be a sound theory at a given moment. But, in order to determine whether this is about a stalled number generator or rather a systematic, predictable scheme, there's probably no way around a minimal test. We may still have a discussion, if a security alert should include dimensions like this (scope of vulnerability), or should be confined to a superficial observation only.
> That's it. No rate limiting. No account lockout.
To me, if he confirmed that there’s no rate limiting on the auth API, this implies a scripted approach checking at least tens (if not more) of accounts in rapid succession.
Granted. I guess, unless it's applied very aggressively, assessing the existence of rate limiting may require some sort of automation (and probably some heuristics – how much data points do you actually need? do you have to retrieve any data at all, while looking for a single signal? The article doesn't tell.) Same goes for lockout.
On the other hand, as mentioned already, all that's required is really looking for a return code and not for any data. Is accessing an API endpoint the same as retrieving data? Is there proof or evidence of intent of the latter? I guess, there remains much to be defined. Especially, if it's not so much about protecting reputation than it is about protecting data and ensuring trust, and the intent is to protect and secure this in the first place.
Regarding "The Second Oldest Game Developer", there are also the authors of "Spacewar!": Steve Russell was born in 1937, meaning, he's either 89 or will be 89 this year. Dan Edwards must be around that age, as well.
Spacewar was ported to Plato from Control Data; I played a little, but I played a lottt of Avatar. There are a number of Plato games that probably have some older / early game developers. Out of curiosity I just looked up Avatar, Bruce Maggs coded it in ‘76 and went on to among other things be one of the Akamai founders. But he’s 20 years younger than Russell.
A few more candidates for the ranking: Peter Samson (of Expensive Planetarium fame, the background star simulation of Spacewar!, and known for his music on the PDP-1, also author of the TMRC Dictionary [0], still active with the CHM PDP-1 team) born in 1941, Ellen Kuhfeld (Minnesota Spacewar [1] for the CDC 3100 at the University of Minnesota, 1966-68) is also in her 80s.
It was originally a PDP-1 game. If you are talking about the PC remake by B. Seiler, it was only 9KB. There is no need to bother with a relocation table if it's under 64KB.
I think, while icon + label is good for things like UI buttons, this is not that great for tables. There are a few reasons for this:
- icons really work only as a small set (e.g. checkmarks versus crosses or similar) – so the only useful application is also in a context which is already highly selective and with low ambiguity. (Familiarity helps and should be a major concern.)
- icons are useful for scanning for rows with a given property – however, to scan icon + label we must not only scan horizontally as well as vertically, but have also to scan items with varying column alignment, which isn't favorable for a vertical scan, either.
So, if it is a case for icons, say, each row has a state out of a set of three, there shouldn't be need for an accompanying text label (this can be learned from a tooltip or a legend), which is also apt to destroys most of the advantages of having icons in the first place. Having both just introduces a mode change, which isn't helpful for scanning, either. If you must have both, put them in separate (adjacent) columns. (In this context, we may note that tables are really about reducing redundancy, though.)
Moreover, to be meaningful in tables (or menus – yes, I'm speaking of recent macOS), icons should only be used to represent state or to represent actions that modify state. There are, of course, exceptions to this, but this may be still a viable starting point…
I'm a confessing user of em-dashes (or en-dashes in fonts that feature overly accentuated em-dashes). It's actually kind of hard to not use them, if you've ever worked with typography and know your dashes and hyphenations. —[sic!] Also, those dashes are conveniently accessible on a Mac keyboard. There may be some Win/PC bias in the em-dash giveaway theory.
A few writer friends even had a coffee mug with the alt+number combination for em-dash in Windows, given by a content marketing company. It was already very widespread in writing circles years ago. Developers keep forgetting they're in a massively isolated bubble.
The site covers mostly retro- and classic computing. (Strictly no AI generated content.) Here in convenient format:
(
:name "Norbert Landsteiner"
:site "https://masswerk.at/"
:blog "https://masswerk.at/nowgobang/"
:feed "https://masswerk.at/nowgobang/feed.xml" //covers blog only
:about "https://masswerk.at/info/" //legal info
:hnuid "masswerk"
:bio "web developer and designer, site content is mostly retro- and classic computing."
)
Your Pet 2001 emulator's pretty cool, and seems much more capable and user friendly than a lot of the downloadable alternatives.
Actually a bit of an issue, its so capable, I actually have difficulty justifying a downloadable alternative, even though I'd prefer to have a local copy due to the untrustworthiness of web apps over time.
Thank you! I can see that this may a bit of an issue. However, this being a simple webpage is what allows to quickly tinker with this and push a quick update, which is also how much of this has kept growing.
The choice of AppleSoft BASIC for a recreation seems to be somewhat odd and deliberate, and doesn't represent the typical limitations of the time (AppleSoft BASIC does floating point math!): in August 1975, the MOS 6502 hadn't even been announced and the Apple ][ wasn't yet a dream. Even Microsoft 4K BASIC for the Altair hadn't been introduced, yet (this was to happen only later in October.) Meaning, none of the basic technology of choice would have been available.
Something along the lines of Intel 8080 assembly may have been more appropriate, given that the target platform would have probably been a coin-op machine. (Given that "Gun Fight", the first arcade video game utilising a microprocessor, wasn't yet released, even this would have been an ambitious choice. Atari doing research for something that required an ALU may be even more interesting than the involvement of the young Steve Jobs.)
PS: This is just to give some truth to "this is where the hackersnews jerks will say this is an ad". ;-)
Yeah... it's a bit unclear to me what hardware this was even supposed to run on? The home and arcade video games Atari was producing at the time (Pong and later Breakout) were based on discrete logic chips, so weren't "programmable" in any modern sense of the word. As you wrote, the 6502 was only introduced later in 1975, and designs using it came even later.
Notably, Dave Nutting Associates (Bushnell's former employer, who also distributed Computer Space) had played around with an Intel 4004 in 1974 and then demonstrated (to Bally) a CPU based system with a frame buffer in September, which evolved into the Intel 8080-based board that ran Midway's Gun Fight. Atari would have probably been aware of this (Nutting Associates had filed a patent.) So, something along the lines of Intel 4004 or 8080 machine code, maybe M6800.
reply