[app_Developer]

I wonder if the need to be *nix like constrained what could be done with microkernels. So much hasn't been done due to entrenched tech (incl. knowledge) which makes the cost of replacement prohibitive.. IoT could be an excuse to rethink things more fundamental than the transition from the combustion engine to electric -- more like steam engine to electric engine.

We really are entrenched.

I highlighted the word excuse, because that seems to be what you are looking for. Most of us in tech are worried about much more important things than rebuilding kernels. Linux is just fine for 99% of what the world does. (Or QNX is fine as the entrenched choice for those of us in autos). Nobody cares about the kernels anymore. Most of us are NOT looking for an EXCUSE to rebuild something that has already been done and works perfectly well (except for China of course, but that's a different political driver there)

Most of the real product and engineering work (not research projects) in the world happens layers up from the kernel.

[app_Developer]

I wonder if the need to be *nix like constrained what could be done with microkernels. So much hasn't been done due to entrenched tech (incl. knowledge) which makes the cost of replacement prohibitive.. IoT could be an excuse to rethink things more fundamental than the transition from the combustion engine to electric -- more like steam engine to electric engine.

We really are entrenched.

BTW, if you want to build things from scratch to replace things that are already working just fine, then you should move to China and work on stuff there. They have good reasons to build a lot of new things from scratch.

[DonHB]

I am not talking about kernels. I am talking about how the entire software stack works. As I said, I find the modularity of QNX more interesting because it makes introducing new abstractions to the operating system easier.

[Dunt Dunt Dunt]

I am not talking about kernels. I am talking about how the entire software stack works. As I said, I find the modularity of QNX more interesting because it makes introducing new abstractions to the operating system easier.

So is QNX any more modular than the dozen other microkernels?

Bottom line is QNX is a proprietary OS that BlackBerry tightly controls.... but BlackBerry hasn't got the resources to take it beyond what they are doing in Automotive and maybe a little IoT. Tiny company struggling to gain any traction in ESS. A few years from now if they hit it big, maybe they'll have some extra cash to throw at QNX.

If you want the whole software world to change... you need to back a more open solution.

[app_Developer]

I am not talking about kernels. I am talking about how the entire software stack works. As I said, I find the modularity of QNX more interesting because it makes introducing new abstractions to the operating system easier.

What is a specific new abstraction that would be easier to introduce in QNX versus a half dozen other kernels?

And if you or I want to introduce something new to QNX and collaborate with others on our new work, how do we do that?

[DonHB]

How about replacing persistent storage with DRM which will provide much more granular control of IP. It should be generalized to work for business IP as well as personal IP. If I want to send pictures from my mirrorless camera (or handset) I can be assured that only my family can see it. I would only need to send it to one family member who would forward it to others. I shouldn't have to provide any more authentication than watching Netflix. The OS would embed into the file the DRM requirements. In a sense it would be a distributed networked ACL. Now, consider how the granular control of DRM can be extended to work with a DBMS. Much harder than extending this abstraction to streaming media. Think how much persistent storage needs to be rethought for this to work.

You will say this functionality should be implemented in an app with an API. If this were done in the OS how much simpler would app implementations be? Some apps may not need to be modified at all. Of course some OSes like Windows allow for installable file systems. So, adding support to third party platforms may be in the form of replacements or extensions even on Linux. I am not sure how restricted the APIes are for extensible file systems on these OSes. QNX seems to make adding APIs easier than those.

[app_Developer]

Every single operating system in the past 50 years has had a pluggable filesystem. All modern OSes support multiple filesystems concurrently. All of them. And they all support encrypted filestores.

In fact what you just described is how iMessage works, and the crypto you describe that drives that is implemented in iOS (and in the hardware of Apple products)

In your scheme, How will your family members authenticate and authorize access?

[DonHB]

Actually, the question should be how are people authorized to gain access? This should work with IoT and for businesses. Imagine a scenario which applies to a Hollywood production from the time a script is acquired, through production (and script rewrites), delivery to theaters and finally streaming. This would require rethinking how the stack works, if you are interested in keeping complexity down. Of course doing it at the app layer would provide you the opportunity to proliferate proprietary APIs of all kinds.

Just to bring this back to handsets. If you consider handsets being an amalgamation of IoT features (e.g. sensors like GPS, compass, etc.) and the company wants to be in IoT how would a handset's software stack be designed so the pieces are applicable to less feature rich IoT devices. You would want a system which can easily be pulled apart and recombined and provide a well integrated whole.

[app_Developer]

Actually, the question should be how are people authorized to gain access?

Yeah, that's exactly what I asked. When families share data in your scenario, how do you authorize access? You restated the question but I didn't see your answer. How specifically would you do this? And how would it be different from how we *already* do this on PC's and phones. [Hint: I do this in iMessage every time I share a picture]

[Chuck Finley69]

Yeah, that's exactly what I asked. When families share data in your scenario, how do you authorize access? You restated the question but I didn't see your answer. How specifically would you do this? And how would it be different from how we *already* do this on PC's and phones. [Hint: I do this in iMessage every time I share a picture]

So we already have available solutions and no further need for additional....... waste of money

[DonHB]

Yeah, that's exactly what I asked. When families share data in your scenario, how do you authorize access? You restated the question but I didn't see your answer. How specifically would you do this? And how would it be different from how we *already* do this on PC's and phones. [Hint: I do this in iMessage every time I share a picture]

What can be done with that picture once it is sent? Think VPN, but not one that is based on devices and connections among those devices.

[conite]

What can be done with that picture once it is sent? Think VPN, but not one that is based on devices and connections among those devices.

You mean once it's sent to one of the 99.9% of people who have Android or iOS devices?

[app_Developer]

What can be done with that picture once it is sent? Think VPN, but not one that is based on devices and connections among those devices.

Explain the use case more?

[DonHB]

It should be harder to send something to someone by mistake than to someone I wish to receive the content. If I somehow manage to get it delivered it should be destroyed upon attempts to copy it (or open it). I should also be able to leave it to a legitimate recipient to decide if someone should also receive it and this be authorized without this intermediary having to ask me (but certain criteria need to be met) for approval. This criteria should be applicable across apps. It should be less complicated than MS Windows permissions yet have more granular control and work across unaffiliated networks: nothing like Active Directory or a VPN should be required.

[app_Developer]

It should be harder to send something to someone by mistake than to someone I wish to receive the content. If I somehow manage to get it delivered it should be destroyed upon attempts to copy it (or open it). I should also be able to leave it to a legitimate recipient to decide if someone should also receive it and this be authorized without this intermediary having to ask me (but certain criteria need to be met) for approval. This criteria should be applicable across apps. It should be less complicated than MS Windows permissions yet have more granular control and work across unaffiliated networks: nothing like Active Directory or a VPN should be required.

- Existing controls like this require a shared identity provider. Would you agree with that? If not, why not? (Otherwise the system has no real way of knowing who has seen what or with whom you can share things)

- For the control to be complete, the app has to be aware of the control. Does that make sense? Otherwise the app can't enforce the control. if the OS hides this, then the app ends up with a normal picture and is then free to share it normally, which totally breaks the control. So the app has to be aware of protected content and then have the APIs it needs to display or share or edit or even create that content with the controls in place.

- There are several other projects/systems that address this type of DRM. Since people share content across multiple operating systems already, any DRM system has to be supported in all the OSes that people actually use. Would you agree?

[DonHB]

If this is done at the OS level it will be far easier to use for all customers including developers. Some classes of apps my not need to be aware of the control, but the control needs to be maintained nonetheless. If done at the level of the OS it could be a distributed instead of a centralized solution that supports the apps on alternative OSes. These differences can be a selling point of the OS. This suggests that other OSes should be supported and this difference in "flow" could be exploited in marketing. It is also possible for certain features (or sensitive content) to be withheld because privacy concerns on certain platforms.

[conite]

It is also possible for certain features (or sensitive content) to be withheld because privacy concerns on certain platforms.

So again, 99.9% of actual end-users can't play your game?

[app_Developer]

If this is done at the OS level it will be far easier to use for all customers including developers. Some classes of apps my not need to be aware of the control, but the control needs to be maintained nonetheless. If done at the level of the OS it could be a distributed instead of a centralized solution that supports the apps on alternative OSes. These differences can be a selling point of the OS. This suggests that other OSes should be supported and this difference in "flow" could be exploited in marketing. It is also possible for certain features (or sensitive content) to be withheld because privacy concerns on certain platforms.

That makes absolutely no technical sense. This premise that you’ve made it easier for developers is completely unsupported by actual developers.

Let’s take a picture for example. If an app that is unaware of the control opens a picture, then it has the picture and can display the picture to the user. If it can display the picture to the user then it also has the ability to transmit same picture (without controls) over the net, and to any other non-secure means. Remember you’re talking about apps that are totally unaware of the controls and so will blissfully do anything with the actual bits of the content.

If you think that apps that are unaware of the control should simply not have access to display the sensitive content, then all you’ve invented is a cryptography library, which has existed on almost all operating systems for the past 80 years.

And you also totally glossed over the identity management piece of this. When you realize you have to manage the identity of the users and roles who have access to the content, then you will realize you have to have a bag of keys somewhere, with a different key for each authorized user or group of users and you have to be able to distribute said keys as needed to multiple users on multiple systems.

And if you now turn this into some argument about distributed work at the *kernel* level, I’m going to roll my eyes pretty hard.

The idea you have is interesting, but remember it’s been worked on for many decades now. Snap, for example, originally built a business around a very similar idea if you think about it.

[app_Developer]

So again, 99.9% of actual end-users can't play your game?

Further, if the business objective is to allow users to make content that is only accessible to 0.1% of the world then that capability already exists.

[DonHB]

No, the idea is to make the IP available only to whom the IP owner decides. It should scale from protecting a family photograph to a Hollywood film or software. It should also be able to manage change in ownership. It could have at least as much impact as a widely adopted OS (and its API). What is interesting is that some have claimed that blockchain is not suitable for implementing DRM.

[conite]

No, the idea is to make the IP available only to whom the IP owner decides. It should scale from protecting a family photograph to a Hollywood film or software. It should also be able to manage change in ownership. It could have at least as much impact as a widely adopted OS (and its API). What is interesting is that some have claimed that blockchain is not suitable for implementing DRM.

So now you want to rewrite the entire mobile firmament, but still on a shoestring budget involving a dead OS from a company that has zero interest? Did I miss anything?

[app_Developer]

No, the idea is to make the IP available only to whom the IP owner decides. It should scale from protecting a family photograph to a Hollywood film or software. It should also be able to manage change in ownership. It could have at least as much impact as a widely adopted OS (and its API). What is interesting is that some have claimed that blockchain is not suitable for implementing DRM.

yes, it's an interesting idea and one that the world probably needs and one that many people have worked on. You should go work on that. Find an existing project and contribute to it.

QNX and BB10 bring nothing more to this problem than any other OS. OTOH, the other OSes bring a lot more users, which means a lot more users with whom you can share content. A system like this is pointless without users.

[Dunt Dunt Dunt]

No, the idea is to make the IP available only to whom the IP owner decides. It should scale from protecting a family photograph to a Hollywood film or software. It should also be able to manage change in ownership. It could have at least as much impact as a widely adopted OS (and its API). What is interesting is that some have claimed that blockchain is not suitable for implementing DRM.

I'm sure the MPAA, IFPI, RIAA and others would love to see more IP protection. But if they couldn't force some major change in the system, I doubt you are going to get very far.

Has nothing to do with BlackBerry....

[eshropshire]

yes, it's an interesting idea and one that the world probably needs and one that many people have worked on. You should go work on that. Find an existing project and contribute to it.

QNX and BB10 bring nothing more to this problem than any other OS. OTOH, the other OSes bring a lot more users, which means a lot more users with whom you can share content. A system like this is pointless without users.

Fully agree, this is a very active space in the tech world. I have been working in and with some of the leading companies in this area. App_Developer is 100% correct. Read back through his threads, he outlines a lot of the challenges still being worked on in the industry.

The big challenge is striking a balance in a company between people who need access to data to get their work done and IT needs/legal requirements to secure the data for proper protection. If IT makes accessing and using data too hard for people to get their work accomplished then 'shadow IT' appears in companies. Workers need to be able to access the right data, at the right time, in the right places using the right methods/controls. With Covid-19 and many working from home this is more critical today. At the same time IT must protect a companies most valuable data assets. Today failure to do so can result in massive fines.

I could write for hours about this topic. My statement above is a very overly simplified explanation of the challenges. I see absolutely no usage of QNX of BB10 in solving this problem. They bring nothing to the table.

[DonHB]

I could write for hours about this topic. My statement above is a very overly simplified explanation of the challenges. I see absolutely no usage of QNX of BB10 in solving this problem. They bring nothing to the table.

If you look at the various products and the IP required to implement them (consider the subsidiary that evaluates risk) BlackBerry is in a particularly good position to address this. That no product they have directly addresses this (not even WorkSpaces though it does more than what Conite believes) means that most would not even consider them in the game and could surprise the market. The company could even monetize the tech (seems obvious for DRM).

That BlackBerry owns QNX combined with its other IP is the reason the company should invest in using QNX tech. By judiciously choosing a handset's SoC it could impact, in partnership with Qualcomm and Samsung, the direction of chipsets in both IoT and automotive. Would it make sense for a SoC to migrate from handsets to automotive and finally to IoT? When would it make sense for 5G to migrate to IoT? It may make more sense than 4G. Samsung has 5G modems.

Finally, the question you don't answer and no-one arguing against my proposition does is whether QNX-7 architecturally makes these things more difficult to implement than Linux (the migration of the underlying SoC to automotive and then to IoT should mitigate the driver availability difficulties). Remember, part of what QNX touts is its POSIX compatibility. What I am suggesting isn't compatible with Linux either. From a business perspective, should a solution it created, that brings DRM to the Gig economy, be OSS?