No more big 32-bit cores for RISC OS from 2022

Steve, maybe we differ on what the two streams approach would entail. In practice, I imagine it would amount to dual booting between forks, albeit between forks where there’s a lot of cooperation at the development level. For example, if the serious side creates something new, the fun side strips out all of that paranoid nonsense for their version, and likewise if the fun side create something new, the serious side closes all those glaring security holes for their version.

How to make sure dodgy applications don’t appear on the secure side?
Ah someone mentioned signing.

Someone also mentioned that such a thing is demonstrably unreliable. ;-)

And the problem with current applications is that they usually need a filetype allocation which someone has to administer.

No, they need a one-off app name allocation. Whether or not filetypes are required depends upon the app, and that (also a one off) is usually done at the same time.

after the initial dual boot secure/nosecure work.

Ah, so the way to work around the issue of freedom versus security is to have two different versions?

Didn’t work out so well the last time two versions of RISC OS existed side by side…

Only someone with the password can run the secure version, so only someone with the password can read the data stored by that version.

That’s good up until to point where somebody can replace the secure OS (on the FAT partition) with an insecure version. I trust the password will also be required in order to decrypt the filesystem, so at least that much ought to be locked down.

Keep arguing,

It’s a public holiday and I spent the morning fiddling with the water pump, so I think I’m going to make a tea, get into bed (I’m cold) and waste some of my life on Netflix.

Water pump – sucks water out of a well, puts it into a tank. Because air leaks out over time, the pump was forever turning on and off. So last night I left off and the taps running to drain the system down. It’s supposed to turn on at around 0.9 bar and turn off at around 3 bar. However the pump doesn’t want to make it to 3 bar any more (it’s about twenty years old!) so I opened up the pressure valve and fiddled with it until the pump trips out at around two and a half bar. And now, rather than the pump cutting in every thirty seconds when running a tap, it can do that for about five minutes, because of pressurised air at the top of the tank.

The water, by the way, is for washing, washing up ¹, and bathing. Given it comes out various colours and often smelling of metal ², there’s no way in hell I’d willingly drink it. Volvic for pasta/cooking and Evian for tea. ;-)

¹ Things are “sterilised” with freshly boiled bottled water before use.

² Just across the field is the end of a slate seam with obvious iron deposits between the pieces of slate. We’re not famous like the Angers slate seam because the stuff around here is too polluted… with iron. And about a half mile away is an old, mostly forgotten, antimony mine.

Just a note and a set of questions:

• Security is not Stability, so we probably should separate the two concepts, although if stability helps everything on every system and/or application.
• Before we talk encryption, there should be some consideration about security.
  • What do we consider trusted?
    • Right now we trust everything, should this stays so? If not what should be changed?
  • This is generally known as Chain of Trust, which (in very few words) is a logic process of “trusting” and/or validating each component of hardware and software from the end entity up to the root certificates. For example from system boot to ensure a system boots up in the desired state and executing only the desired code.
  • In the original Acorns the chain of trust was “naturally” ensured (and limited to) by the fact that RISC OS was in ROM, so motherboard was trusted by definition and ROM was too, they were both extremely hard to modify, hence there was some degree of intrinsic-trust.
  • In an OS that boots from disc there are techniques that have to be implemented in order to ensure a system is booting what is supposed to and not something else. In the PC world such techniques are collectively named Secure Boot (and there are entire books and standards defined to ensure such process works correctly).
  • Chain of trust doesn’t ends with system boot, it also can include applications execution, installation, file access and more, so what level of chain of trust would be acceptable for RISC OS?
• Security always implies some degree of system and application hardening, what level of hardening should be considered for RISC OS?
  • For instance, right now a BBC BASIC program can have access to almost everything. If this is limited for security reasons (or even for stability reasons) then such program will stop working, is this acceptable?
  • Hardening also means having to modify the OS in order to support certain workflows, is this acceptable?

Steve, maybe we differ on what the two streams approach would entail. In practice, I imagine it would amount to dual booting between forks, albeit between forks where there’s a lot of cooperation at the development level. For example, if the serious side creates something new, the fun side strips out all of that paranoid nonsense for their version, and likewise if the fun side create something new, the serious side closes all those glaring security holes for their version.

Total co-operation at the release level basically.
If you want to label them as forks in your mind then fine, but my vision is that having moved to a fork point directly alongside the two tracks stay as parallel as railway tracks¹ so there isn’t really a divergence and moving items from an open development status into a secure general use status shouldn’t be a major hurdle.

Someone also mentioned that such a thing is demonstrably unreliable.

Citation needed.

No, they need a one-off app name allocation. Whether or not filetypes are required depends upon the app, and that (also a one off) is usually done at the same time.

Same difference, still handled by the maintainers of the RO IP

Ah, so the way to work around the issue of freedom versus security is to have two different versions?

Didn’t work out so well the last time two versions of RISC OS existed side by side…

I’d hardly call the existence of two versions in the hands of two groups throwing rocks across some distance “side by side” and unless the individual members of ROOL start arguing about who is in charge etc I don’t thing things likely to truly fork and it’s extremely unlikely to approach to within a planetary orbit of the level of disagreeableness in the ROL-Castle feuding.

No, parallel tracks is what I was suggesting.

I trust the password will also be required in order to decrypt the filesystem, so at least that much ought to be locked down.

That was the idea, did I not spell it out – grabbing time before work, during lunch and coffee breaks (Real coffee, I like home working)

Keep arguing,

It’s a public holiday and I spent the morning fiddling with the water pump

That was encouragement BTW. You’re one I suspect could come up with useful ideas and spur others.

about a half mile away is an old, mostly forgotten, antimony mine.

Perfect for added flavour, if you’re daft enough…

Security is not Stability, so we probably should separate the two concepts,

Yes. Just tagged together in the options A, B, C for brevity (I sometimes manage that, but rarely)

Before we talk encryption, there should be some consideration about security.
What do we consider trusted?
Right now we trust everything, should this stays so?

My thought was that if you initially build an environment that is secure against reading by any method other than giving the correct password in the ROM boot then you’ve ticked one small box.

People can steal your machine, or just your “disc” and it has no accessible data¹ without the password which has been used for the encryption.
Usual warnings about making sure you know the exact password or you lose access to the data.

As to what is secure, well initially just access to the secure partition. What the user puts on that partition wouldn’t, initially, be any different in trust level to the current.
As things progress you can mark modules and applications as “trusted” and a ROM based table (or small encrypted table) specifies which are expected to be trusted so an untrusted replacement gets a Foxtrot Oscar from the OS.

In an OS that boots from disc there are techniques that have to be implemented in order to ensure a system is booting what is supposed to and not something else. In the PC world such techniques are collectively named Secure Boot (and there are entire books and standards defined to ensure such process works correctly).

The boot setup I was thinking of would boot a ROM from an insecure storage (later versions might tighten that ‘flaw’) and use the key saved in the ROM image (one time only?) along with the boot time supplied user password for the other key. These together form the decrypt.

Chain of trust doesn’t end with system boot, it also can include applications execution, installation, file access and more, so what level of chain of trust would be acceptable for RISC OS?

Interesting question, and that is an item to be decided along the way.
Bear in mind that this may well be totally divorced from the open stream so implementing some trust chain that stops experimentation in the secure stream isn’t a showstopper or, possibly, even relevant.
Most objections people throw up about security are because that specific security aspect you might have just mentioned is their personal “hack-round-the-backdoor” method of getting things going in the initial development – accessing the CLI environment via the serial port on a new OS port for example.
In what way would that be an excuse for leaving the backdoor in place on the finished, secure, article?

Security always implies some degree of system and application hardening, what level of hardening should be considered for RISC OS?

In some respects I may have accidentally/incidentally covered this to an extent in the OS signed/approved modules and applications element earlier. Only listed approved items can run.

For instance, right now a BBC BASIC program can have access to almost everything. If this is limited for security reasons (or even for stability reasons) then such program will stop working, is this acceptable?

Ah, restricting access to the ‘bare metal’ as some like to view it.
Initially I’d say leave that alone, don’t try and fix everything at once.
When you start changing things is different.
Generally speaking BASIC programmes don’t dig that deep, and they actually deal with what the system presents to them. Removing the actual MOS ‘cruft’ and replacing that element with something that responds in a like manner should convince BASIC programmes and other stuff that they are dealing with the old OS base layers when they aren’t.

Hardening also means having to modify the OS in order to support certain workflows, is this acceptable?

I think that is likely to be a debate that comes up when you start that process.

Certain “it’s always been like this” adherents will shout, loud. The initial response is “I hear what you are saying”² Stepping beyond that particular complaint, the question is why do they want to do whatever they are doing that way?
Is it somehow more efficient? Or is it just familiarity?
Does the new way fit with the current RO ethos or has a change been made because it’s different and “change is good” (a mantra I’ve always answered with one word³)
Acceptance and adoption of required change is good. First define the requirement.

Hmm, not War & Peace but heading that way. Stop for food & drink (tea, I’m a Brit).

¹ Except any data you place in the non-secure partition / disc

Q-Lock by Nat Queen enables you encrypted single files or whole directry structures whilst doing high grade deletion of the original files.

Perhaps that is something that could be built in but guess the issues around !Boot files would need to be looked in to but perhaps good to get a lot of things out of it at the same time?

Citation needed.

Me, when I pointed you towards the app stores of both Google and Apple, both of which are supposed to have been vetted for safety, both of which have carried malicious apps (Google rather more than Apple, but they’re both guilty; it’s an unavoidable side effect of running automated scanning against submissions, they can’t detect everything).

Just because something has made it to a centralised repository and been signed does not automatically make it safe.

This is generally known as Chain of Trust,

It seems to me that Chain of Trust in its broadest applications is not about providing trust but removing user control.

I’ve mentioned in the past that when connecting to a server using SFTP or the like that the first thing any sensible client will do is display some numerical gibberish and ask “this is the server’s fingerprint – do you trust it?”.
This never happens for https websites. Granted, it would be weird and confusing for many people, but really we have sacrificed security for convenience. We “trust” that site X is really what it is, not because we’ve checked but because somebody else says so.
Given that banking transactions happen using the same process…

from the open stream so implementing some trust chain that stops experimentation in the secure stream isn’t a showstopper

But it does raise the question of software that may work on one stream and not the other.

Generally speaking BASIC programmes don’t dig that deep

The salient point isn’t whether or not BASIC programs do, it’s that they can.

There was a time when the simple line !8=0 issued from BASIC would instantly freeze the entire machine (it sets the SWI branch address to zero).

“I hear what you are saying”

Usually a euphemism for “I see your mouth moving but I’m not paying any more attention than that”.

Listen for it on TV debates. The person will say “I hear what you are saying but” and then carry on making their point completely ignoring what their opponent had been saying.

First define the requirement.

Second, show me the code.

Familiarity is good, change is good, but it is a balance.
Never moving forward is not good, and change for the sake of change (like Android, iOS, Firefox, etc dicking around with the UI in each version) is not good.

See also: https://duo.com/decipher/attackers-are-signing-malware-with-valid-certificates

Q-Lock by Nat Queen enables you encrypted single files or whole directory structures whilst doing high grade deletion of the original files.

Thus proving that elements of this have been done before. Author co-operation and/or licence compatibility assumed this could be a useful starting point.

Nice reminder Doug.

it’s an unavoidable side effect of running automated scanning against submissions, they can’t detect everything

Nor can human scanning. Nothing is perfect, however something is better than nothing.

Just because something has made it to a centralised repository and been signed does not automatically make it safe

Especially when the people running it are more interested in the money than the accuracy.
Can we assume that we care less about the money than the accuracy?

I’ve mentioned in the past that when connecting to a server using SFTP or the like that the first thing any sensible client will do is display some numerical gibberish and ask “this is the server’s fingerprint – do you trust it?”.
This never happens for https websites.

In the first case you don’t have the certificate in the second you do.
I think you’ve read my tales of cocked up certificates many times.

It’s perfectly possible to sign the SFTP (or FTPS – different but often confused) connections with a public certificate. Sites rarely do as the self-signed is easier, then again a large proportion of the sites persist in using plain FTP – this being an idea that is treated to a plain “No”¹ when connectivity through any of our firewalls is requested.

But it does raise the question of software that may work on one stream and not the other.

Thus demonstrating the need for a means of testing things on the open stream for compatibility issues before second stage testing on the secure stream. Whether that is a set of tests to run through or a specific tool is the question.
Provide a tick box sequence of tests to run and someone will get fed up and script/automate the sequence.

The salient point isn’t whether or not BASIC programs do, it’s that they can.

When they can’t, the only issue is: do the useful programmes still work?
If the answer is no, then the question is “what were they doing wrong?” Why do it that way if there is an alternative? “Speed” on a 1GHz+ machine? Really?

Usually a euphemism for “I see your mouth moving but I’m not paying any more attention than that”.

I’m far more polite. I give a reasoned refusal. Once in a blue moon, I may reconsider the original.

Never moving forward is not good, and change for the sake of change (like Android, iOS, Firefox, etc dicking around with the UI in each version) is not good.

Exactly. The exercise here is to define which bits need to change (in generalities, specifics come later) and then what order to make the change.

¹ Believe me, that’s the polite version.

Exactly. The exercise here is to define which bits need to change (in generalities, specifics come later) and then what order to make the change.

Yes I personally agree with this.

IMHO initially it should be an exercise of understanding what the community wants (and explain certain technical possibilities to make sure everyone understands them), create a list of desired changes and then start with the technicalities, otherwise there is the risk of scaring out people by mentioning SWIs, technical architectural changes and what we would change in the specifics.

as always, just my 0.5c

Has anyone ever done a flowchart for the ROM startup of the ROM?

There’s a nice flowchart for the disc elements (paper copy upstairs from the ROL stand at the Birmingham show years ago).

See also: https://duo.com/decipher/attackers-are-signing-malware-with-valid-certificates

“Since its inception, the process of cryptographically signing a piece of code was designed to give the Operating System a way to discriminate between legitimate and potentially malicious software,” Chronicle wrote.

Where did that nonsense came from? Signing is to check whether code has been tampered with since publication; it has nothing to do with whether that code does something desirable!

@ Chris Mahoney

Where did that nonsense came from?

It’s just Rick sharing what he has learned from the internet about advanced threats. The reality of RISC OS is: RISC OS is not affected by such degree of cyber criminality because RISC OS has not such “hacking value”. RISC OS’s value on the market is literally zero.

To me Rick is entitled to his opinion and so I do not argue/comment on that link.

The fact that may be of more general interest is that to use RISC OS as a daily driver and main Desktop OS we should probably have a look at what people do with their main Desktop computers:

Home user use case (example):

• Browse the web for:
  • General information
  • Buying on sites like amazon (et similar)
  • Watching Youtube and similar
  • Accessing cloud services of different nature
  • Using social media (FB, Tweeter, LinkedIn, you name it)
  • Reading articles on their favourite blogs and news sites
  • Listening to some internet radio
  • Listening to podcasts
  • Listening to music services
  • Home banking
  • Expense Management
  • Chatting
• Storing and Sharing their pictures (with or without their consent lol)
• Doing some photo-retouch (especially on selfies!)
• Playing some games:
  • Simple/desktop games (solitaire is still a hit in 2020!)
  • Retro gaming
  • So called AAA Games
• Store and watch videos
• Listen some music locally stored (mp3 and other formats)
• Someone still uses Music CDs
• Someone still watches DVD and Blue Rays
• Read and send emails
• Download documents in well known formats for various reasons (from having to fill out forms to get documentation the need)
• Some spreadsheets for the ones who manage their expenses locally

For professional users things are more complicated and, in many situations, they require even specific softwares. For example in the world of professional music recording there is need for specific audio formats, sampling rates, DAW multi-track formats.

Beside all the specifics of software formats etc… one of the main thing is: a lot of the things people do are related to their life and require some degree of security (without getting into Advanced Threat situations for which very little can be done even on more mature systems and even on things like Paranoid Linux).

No degree of security = no RISC OS as main desktop. It doesn’t matter what people may comment on this regard, because I am pretty sure none of them would use RISC OS to buy on amazon or to login on any services when they know their password can be stollen by anyone or they could install software that would steal all their passwords and data without even knowing their computer got severely compromised. And yes this can also happen on other systems, but this is not a good excuse to leave RISC OS in a messy state.

Obviously someone at this point my comment: But to me main Desktop in 2020 means still only using Ovation Pro and PipeDream. Well, if so, then I am happy for this person, but try to tell this to new generations or to people that use a desktop for the list of things above…

And then another may comment: Ok, but for the things above I use my iPad/mac/Windows/Linux/Android/whatever. If so then the answer is already clear: RISC OS is not going to be a main Desktop.

In other words to be a main device it has to follow the changes in usage requirements, the changes in security and privacy requirements and someone may also argue the changes in aesthetic requirements.

Do we agree on this at least? If not then can we at least agree on disagree? :D

Regarding security, one thing’s sadly likely: If RISCOS ever came back in a big way, the developer’s elation would quickly turn to horror as they discovered the hard way just how much computer crime has advanced in the past 25 years. Once the veil of security by obscurity drops away, it’s inevitable that organized crime will launch a full-on assault.

Paolo: I pretty much agree with your list. The only exception I’d make would be AAA games, as no one would expect them to run on what would likely be a sub-£100 piece of hardware. The other big thing is DRM protected media like Netflix and Prime.

Once the veil of security by obscurity drops away, it’s inevitable that organized crime will launch a full-on assault.

I think a lot of us have been saying that for quite a long time.
There was a reason for discussing signed apps¹ sitting in an encrypted disc partition.

¹ Signed by ROOL – no signing, no run.

Does anyone seriously imagine people using a RISCOS machine to engage in financial transactions? I’m astonished.

I’d hardly call the existence of two versions in the hands of two groups throwing rocks across some distance “side by side”

There were two versions in use independently at the same time. That’s “side by side” if we tactfully gloss over the bonfires and pitchforks…

Especially when the people running it are more interested in the money than the accuracy.

A very valid point.

It’s perfectly possible to sign the SFTP (or FTPS – different but often confused) connections with a public certificate.

I think my site does (with the heyrick.eu cert, since that’s the domain I’m connecting to). Then there’s the server fingerprint. Then there’s an obscenely long line noise that counts as the password, then there’s a private key exchange (with only two copies of the key in existence). Thankfully WinSCP automates all of this. ;-)

And yes, it’s an appropriate level of paranoia these days.

Would be interesting if immigration into a less liberal country should ever demand my passwords. I don’t remember the server password, I’m unlikely to ever remember it, and if I did, it’s no good without the encryption key. Uh…

then again a large proportion of the sites persist in using plain FTP

Sites aimed at the AOL crowd, I presume?

“Speed” on a 1GHz+ machine? Really?

Yes, actually. One thing that has come from this discussion is that not everybody speaks C or wants to learn it. In the absence of plentiful compiled languages, we may yet run into people writing code in BASIC with splatterings of assembler for the “slow” parts.

understanding what the community wants

Asking questions like that on a forum is the way of madness.

If you rummage around, you might dig up an older thread asking what was it about the other version of RISC OS that people wanted to see in this version. Not wishlist stuff like firewalls and rounded icons, but actual show stoppers that need to be prioritised.
From memory, asides from the usefulness of built in image format filters and a little more stability, the results were rather inconclusive.

create a list of desired changes

This thread is meandering a lot. Are we talking about RISC OS now or a potential 64 bit version?

For me – I’d say some important changes would be to better utilise existing hardware. On several devices we have onboard WiFi and Bluetooth unused, three cores unused, and we’re still stuck emulating an ancient FP chip and ignoring the hardware FP present in everything post-Iyonix.

I think, ultimately, fewer people are going to care about the mess that is the RMA (it’s been like that for thirty three years, a little longer won’t make much difference!) than they would about having the platform actually utilise the available hardware, that we have right now, today.

Where did that nonsense came from?

Ah, you noticed. ;-) That’s mostly why I posted that link instead of the others.

The thing is, even though it’s crap, it’s crap that people believe.
Rather like the “padlock equals safe” with websites. It absolutely does not mean that, the fact that your connection to a site is encrypted doesn’t preclude them from storing passwords in plain text and leaking credit card details all over the dark web.

Signing and encryption != Safe, but try telling that to the masses.

To me Rick is entitled to his opinion

The point was, legitimate signing (as accepted by the OS) has been used for malware on other platforms, thus demonstrating that there is no easy or reliable technical solution.

RISC OS is not affected by such degree of cyber criminality because RISC OS has not such “hacking value”.

That’s true. But should we ever poke our heads above the parapet, expect snipers to get a few clean kills.

Or, to put it in other words, the only sensible way to treat “the internet” is to assume that everybody and everything is out to pwn you.

Remember, RISC OS dates from a time before global connectivity. The platforms that also did (like the Win32 era), they learned hard. So did the users. Win32 was abandoned in favour of the more secure NT kernel, but Microsoft unwisely gave home users admin rights by default. They fixed that in Vista, then had to fix that better in… what was it, 7?
The point is, it’s always been a moving battle and you need to keep up to date with patches as more issues (and the occasional zero day) are uncovered.

We don’t stand a chance. RISC OS, as it is today, is architecturally incapable of the degree of isolation and protection necessary to withstand much of anything. All it takes is one privilege escalation, and hell, a huge chunk of the API does that as a matter of course.

Browse the web for:

We’re getting better in that respect. I just hope RODev’s new browser has decent blocking capabilities (or can run UBlock Origin).

Watching Youtube and similar

We don’t really have a way to make use of the GPU, so YouTube is limited to fairly small image sizes (what can be feasibly decoded in software).
There’s also the issue of encryption (re. Netflix etc).

Listening to some internet radio
Listening to podcasts

DigitalCD?

Chatting

Chatcube?

Listen some music locally stored (mp3 and other formats)

DigitalCD.

Someone still uses Music CDs

Was possible on the RiscPC. I wrote a lightweight player called “Mewzyck” that just told the drive what to do.

Not sure how it works for USB drives as there’s no dedicated audio output.

Someone still watches DVD and Blue Rays

Hmm, I wonder if 1GHz(ish) is fast enough to decode MPEG-2 in software? If so, might be able to do DVD (though I’m not aware of a player that can handle menus and such).

No to Blu-ray, that’s HD H.264. Really need GPU for that.

For example in the world of professional music recording there is need for specific audio formats, sampling rates, DAW multi-track formats.

But more than all of that, there’s a need for software.

As far as I’m aware, we don’t have a competent free MIDI sequencer, for instance. Nor anything that resembles Audacity. And you mentioned touching up selfies. We don’t have anything that can do that either. There’s PhotoDesk, but that’s seriously overkill if you just want to knock out red eye or fiddle with the contrast or colour balance of a shot taken on a cloudy day.

No degree of security = no RISC OS as main desktop.

Funny thing is, I don’t use my PC much these days so “the desktop box” is a Pi2 running RISC OS.

Amazon? Netflix? Banking? Ordering stuff? That’s what I use my phone for. In a way, the inability of RISC OS browsers to cope with such things means that I never had any expectations of RISC OS being able to do them.

but this is not a good excuse to leave RISC OS in a messy state.

I actually consider the “desktop machine” and the “mobile machine” as two entirely different use cases. To put this into context, if somebody raised enough cash to get info from Netflix to build an app for RISC OS… I probably would not use it.

Why? Because in my earlier life I’ve sat in front of a computer connected to a monitor to watch DVDs. Or digitised video from satellite broadcasts. Or (ahem) downloaded animé.

These days? I do that sort of stuff on my phone. I’m short sighted and my phone has a ridiculous resolution, so I can hold it about a foot away from my face and it is “perceptually” larger than my 21" monitor at viewing distance.
I can lie in bed to watch stuff. Or outside on warm days. In waiting rooms. On break at work.
Indeed, one of the main jobs of my PC now is to rip DVDs that I have bought to MP4 so I can watch them on my phone, when and where I want.

It’s much the same with things like Amazon and online banking. These services provide functional dedicated apps that run on my phone (which may be required if I’m expected to respond to a 2FA code sent via SMS); so even if RISC OS could deal with the websites (as it looks like might soon be the case), why change?

Different devices, different use cases. I don’t consider a desktop PC to be the one sole machine for everything; any more than a person would consider doing their banking on a work laptop.

but try to tell this to new generations or to people that use a desktop for the list of things above…

It’d be interesting to do a straw poll, as I rather imagine the use of desktop machines for all of the above is declining rapidly.
Give somebody a reasonable spec tablet with a decent sized screen (say at least 10") and you’ll probably find a fairly rapid transition to that device for all the things it is capable of. Tablets and phones aren’t so hot for word processing (Google Docs works but it’s a bit basic; and you really need a Bluetooth keyboard) and photo editing (basic editing is standard, but shopping one picture into another is still something that would require a desktop machine). But for a huge amount of day to day stuff like banking, shopping, checking the news, social media, kitten videos, etc… A tablet that’s like there and on and portable will replace a desktop box in a heartbeat.

My machine use? PC, maybe 1%. RISC OS, maybe 5%. Android, 94%. Guess what I’m writing this on…

RISC OS isn’t the main device, but it is the main desktop. ;-)

I’m astonished.

Maybe people with bank accounts that are already empty?

Do we agree on this at least?

I broadly agree with the gist of what you’re saying, but I think – as said above, that people’s behaviour is changing to favour portable devices rather than big clunky machines; and that “fixing” the system for security is going to take quite a bit more than signed apps and an encrypted filesystem.

Consider Windows, and all the evolutions that has gone through in its history.
Us? We’re basically Windows 3.10 in that scenario. Our “security” is that we’re something long forgotten (and, bonus, much of the world doesn’t even know we exist). But, anybody will tell you the value of security through obscurity.

Maybe it’s my age – but I didn’t think that was a lot different from the average age on this forum at 71 – but the way I my use of devices is very different from yours, Rick. Maybe rather than my age it’s my long sight.

Mobile phone: very little used at all, for making and receiving phone calls, maybe two or three a month; making and receiving text messages, also two or three a month. Carried in case of emergencies.

Tablet: don’t have one, occasionally have to help wife with hers, drives me nuts – where’s the bloody keyboard?

Laptop: have it in the living room, use it if I’m being sociable, but the screen has frustratingly few pixels – it’s only 1366×768.

Big monitor (okay, it’s a TV really, but it’s only ever been used as a monitor) in the spare bedroom, hooked up to the Mac mini and the Pi, for everything. Landline on the same desk, but also a wireless phone connected to the same landline for use elsewhere in the house (or garden or shed).

Does anyone seriously imagine people using a RISCOS machine to engage in financial transactions? I’m astonished.

I keep reading items where people are speaking of using RO to access their bank account.
I’ve not checked how payments for items in !Store are transacted, but I know the download setup isn’t properly secure.

Rather like the “padlock equals safe” with websites. It absolutely does not mean that, the fact that your connection to a site is encrypted doesn’t preclude them from storing passwords in plain text and leaking credit card details all over the dark web.

Fortunately the technical interest in using secure HTTP is more in verifying that they site you’re talking to is relatively likely to be the site that you think you’re talking to, and not what happens to your data. Hence the flagging of insecure images on this forum and the like: the browser is saying “did you know that you’re downloading stuff that isn’t coming from a certificated server?”

Yes, there’s big holes in that, too… but it’s better than not doing it, and there was a need to start from somewhere and move in the right direction.

I keep reading items where people are speaking of using RO to access their bank account.

There still seems to be a line of thought, especially in the newsgroups, that it’s safer to do that stuff on RISC OS because it’s not Windows. Sigh.

One thing that has come from this discussion is that not everybody speaks C or wants to learn it.

In some cases it’s a “use case” issue. If they do what they need in BASIC where’s the point in learning anything else, especially if they feel they may be pushing up daisies before they get to a point where they can do anything useful in C.
In other cases, like me, I may get past my mental block eventually – then again the daisies may be assisted first.

Asking questions like that on a forum is the way of madness.

There’s a reason we’re all here.

If you rummage around, you might dig up an older thread asking what was it about the other version of RISC OS that people wanted to see in this version

and if you do, and then compare that with what’s here now there are some pleasing ticks.

Are we talking about RISC OS now or a potential 64 bit version?

Neither. Amending what exists, but while doing it rewriting portions in C (or whatever is portable)
No point in developing x for RO because it’s insecure and GDPR compliance is impossible —> increase the security, build in encryption.
No point in trying to develop y because it needs a stable platform or people won’t use it —> eliminate flakey applications that access things they shouldn’t.
On that, is it me or does ImageFSFix(SparkFS) have workspace in a strange place? and UnsqueezeAIF…

thus demonstrating that there is no easy or reliable technical solution.

Controlling the human element is the correct method to reduce risk.

Win32 was abandoned in favour of the more secure NT kernel,

Win16 and a bit

but Microsoft unwisely gave home users admin rights by default. They fixed that in Vista, then had to fix that better in… what was it, 7

Win7 after a service pack. Vista was an abortion that brought all the problems of a lockdown at the same time as keeping all the sh** they thought was entertaining. Having learned their lesson and producing Win7 they forgot and did Win8.0 which even MS would prefer people forgot and consider 8.1 as “the real 8”
I’m still trying to get used to the return of Fisher-Price known as Windows 10 (I don’t have a real machine, but the virtual machine with my admin apps on it is Win10)

RISC OS, as it is today, is architecturally incapable of the degree of isolation and protection necessary to withstand much of anything. All it takes is one privilege escalation, and hell, a huge chunk of the API does that as a matter of course.

Which brings us back on track for the discussion of what needs to change and in what order.
Get a general agreement on that and you can move on to more specific stuff.
HLD —> LLD —> Detail —> Implementation

“fixing” the system for security is going to take quite a bit more than signed apps and an encrypted filesystem.

Yes, but those are blindingly obvious items to put into the spec. and the encrypted filesystem fills one of the really big holes regarding GDPR compliance when data about third parties is stored on that filing system.
Not all of the holes, but a damned big one.

More discussion, more suggestions of the kind of thing required to fill each hole.

Hence the flagging of insecure images on this forum and the like: the browser is saying “did you know that you’re downloading stuff that isn’t coming from a certificated server?”

Minor tweak in the server config and the browser now assures¹ you the link is genuinely going where you think it’s going.

Yes, there’s big holes in that, too… but it’s better than not doing it, and there was a need to start from somewhere and move in the right direction.

Which is my motivation for pointing out that the hardware that the virtual !Store server sits on clearly hasn’t been patched for years and the site isn’t setup securely anyway.
The same for the plain FTP in use by at least one RO user. That may have changed following the info from Rick on how easy it really is. BTW people should use SFTP rather than FTPS, the first is a single port to open in a firewall the latter is one port for the control channel and many varying ports for the data (major pain in ….)

¹ Or at least let’s you know it’s more likely