My OysterCard Whinge

On 14 Jul, 11:46, thagor2...@ wrote:
> On Jul 14, 11:22 am, Roland Perry <rol...@perry.co.uk> wrote:
>
> > >If the mechanism for permanently disabling a card means they have to
> > >be touched to a gate that would rather follow wouldn't it?
>
> > So you think the idea was to disable *some* cards, but the system had a
> > brainstorm and disabled *all* of them?
>
> That would be my guess - a simple programming mistake caused some
> isThisADodgyCard() test always to return true so it killed them all.
>
> > I don't know if you can update the firmware in the cards. Do they even
> > have something to update?
>
> Some simple cards are hardwired with just a couple of numeric
> registers to carry values but Oysters will have onboard software
> because they have to store a simple database of places and times
> visited plus there's encryption going on. Whether that software is in
> ROM or something read-write akin to flash that can be updated I dunno.
> Obviously it has some sort of R/W memory to store the DB , balance etc
> anyway.
>
> > This is more consistent with their inability to "reverse" the process.
> > It's more scalable to do it that way than to have a blacklist of cards
> > available at every single Oyster reader.
>
> Yup.
>
> > I have a feeling we haven't heard the end of this.
>
> Certainly not from the poor buggers who got stranded with a broken
> card either. :o)


I am not a techy, and I was thinking at first that surely there is
something that can be reset rather than having to replace the card.

But I wonder if it's something like the way that (the surely soon to
be extinct because useless) CDs and DVDs become useless if a write
operation fails. Like some sector that tells the reader where to look
next is corrupt, rather than just a readable setting that says the
card is invalid.

In message <Pine.LNX.4.64.0807142312410.11847@urchin.earth.li >, at
23:14:56 on Mon, 14 Jul 2008, Tom Anderson <twic@urchin.earth.li>
remarked:
>To my mind, it has to be modifiable to be firmware, which makes code in
>a ROM not firmware. Although thinking about it, my mind is probably
>wrong on this point.

Lots of people these days take the precaution of making firmware
upgradeable, but that's not part of the definition - which is
non-volatile software providing the lower levels of API (not the user
interface) to a dedicated bit of hardware.
--
Roland Perry

In article <75cfddb9-ce46-4e3e-9303-1e41e16ceba9@m3g2000hsc..com>,
thagor2008@ <thagor2008@> wrote:
> So what do you think will be running the encryption processor? I don't
> know what a circuit hardwired to do something like 3DES or Blowfish or
> whatever encryption Oyster uses would look like, but I suspect it
> would be a nightmare to design and debug if it were even possible.

Hardware crypto accelerators have been around for ages and ages and
ages. I remember in the late '90s seeing one that hooked up to the
SCSI bus - it was aimed at the web server market.

These days there are off-the-shelf x86 compatible CPUs that can do
it (at least for AES, anyway).

I don't know if they'd count as 'hardwared' mind you - I would
expect them to consist of odd specialized hardware coupled with a
general purpose CPU and to split the workload between them.

--
Shenanigans! Shenanigans! Best of 3!
-- Flash

In message
<add89374-6720-4952-9fc7-443dda7c7849@p25g2000hsf..com>, at
01:31:16 on Wed, 16 Jul 2008, thagor2008@ remarked:
>where does software end and hardware start?

There are grey areas, as well as black and white.

>For example x86 processors can do trig as well as multiply and divide
>etc. But intel use microcode to carry out the operations internally.
>Does microcode count as hardware or software?

Microcode is Software, but it probably also counts as Firmware (which is
simply that subset of built-in software performing certain low-level
functions). The engine that the microcode is driving is Hardware.
--
Roland Perry

In message
<372d84e1-8cec-47fa-bea5-70dd0dd7a401@y21g2000hsf..com>, at
05:47:38 on Wed, 16 Jul 2008, thagor2008@ remarked:

>From wikipedia:
>
>"A control store is the part of a CPU's control unit that stores the
>CPU's microprogram"
>
>"A control store is usually implemented as a diode-array of read-only
>memory"

I'm a fan of Wikipedia, but that stuff is just gibberish.

>So I guess at that level you could put forward a valid argument for it
>being hard wired diodes, or software in the sense of the way the
>diodes are wired. Or both! But then again I suppose you could say the
>same about any read only ROM.

There any many technologies that can be used to implement a ROM,
including the presence and absence of diodes in a matrix, and even the
ability to erase or restore such diodes in the field. This is
ludicrously technology-specific, however, and who is to say what a
generic CPU uses to store its microcode. (If you had asked me yesterday,
I might have said "the presence of absence of conductors between logic
gates").
--
Roland Perry

In message <6e6p6uF5ie2mU1@mid.>, at 18:24:55 on Wed, 16
Jul 2008, tim..... <tims_new_home.uk> remarked:
>> Microcode is Software, but it probably also counts as Firmware (which is
>> simply that subset of built-in software performing certain low-level
>> functions).
>
>I would suggest that it is that subset of software that is hardcoded, one
>time only, into a device to perform a specific function (low level or
>otherwise).

Lots of firmware is upgradeable, and specific-function software like
Windows, when supplied in ROM for a low-cost laptop, isn't Firmware.
--
Roland Perry

On Jul 16, 4:22 pm, Roland Perry <rol...@perry.co.uk> wrote:
> In message
> <372d84e1-8cec-47fa-bea5-70dd0dd7a...@y21g2000hsf..com>, at
> 05:47:38 on Wed, 16 Jul 2008, thagor2...@ remarked:
>
> >From wikipedia:
>
> >"A control store is the part of a CPU's control unit that stores the
> >CPU's microprogram"
>
> >"A control store is usually implemented as a diode-array of read-only
> >memory"
>
> I'm a fan of Wikipedia, but that stuff is just gibberish.
>
> >So I guess at that level you could put forward a valid argument for it
> >being hard wired diodes, or software in the sense of the way the
> >diodes are wired. Or both! But then again I suppose you could say the
> >same about any read only ROM.
>
> There any many technologies that can be used to implement a ROM,
> including the presence and absence of diodes in a matrix, and even the
> ability to erase or restore such diodes in the field. This is
> ludicrously technology-specific, however, and who is to say what a
> generic CPU uses to store its microcode. (If you had asked me yesterday,
> I might have said "the presence of absence of conductors between logic
> gates").

This all might as well be a foreign language to me, but ... does one
or other hypothesis explain why a card can be permanently disabled by
being touched on a pad rather than being able to be reset?