BlackBerry Blog

> Which is no software company has ever done this

Yeah, I'm just not buying this whole we're the only one to have ever used the common "<letter> is for <thing we provide>" -- for one more letters, including sometimes with the implication that the company being promoted provides a whole alphabet of solutions either by explicit claim using the term "alphabet" or by providing or implying coverage of the full alphabet of letters -- promotional gimmick in and around the software industry.

https://twitter.com/mscloud/status/619883853587591168
http://www.wittyparrot.com/sales-blog/s-is-for-storytelling
http://www.ornavi.com/2015/05/31/the-a-z-of-ornavi-2/
http://blogs.blackberry.com/2015/07/the-a-to-z-of-qnx-in-cars/
http://nchsoftware.blogspot.com/2012/01/is-for-audio.html
http://www.computeruniverse.co.za/ABC.html

> Would it surprise you to learn that we too are in "advertising" business.

No, because I already knew that. Which makes it even sillier -- two companies that (whether more fairly viewed as technology companies or not) are in the advertising/marketing business both use different variations (not more similar to each other than each is to many other common instances of the technique) on a technique common in advertising and marketing. This is not surprising. That one of them would accuse the other of stealing the idea, based on the idea that, despite the fact that the technique is common, the two companies are "software" companies and supposedly no other software…

For some context, read BlackBerry COO Marty Beard's blog post[1] from a few weeks ago. I don't think Chen or anyone else at BlackBerry thinks the government should compel anyone to write apps for their specific platform, in fact that's the very mindset they're criticizing. What they're getting at is that services should leverage open technologies so that nobody's platform gets shut out, which I believe is also a core value of Mozilla and Firefox OS, for example. It's not just a matter of BlackBerry vs. the world; how many apps are iOS-first or iOS-exclusive, despite the market domination of Android? I think Chen and Beard are advocating for the tearing down of the "walled garden" world of mobile platforms.

I use a BlackBerry Passport as my daily driver, and although I have both native apps and sideloaded Android apps via Amazon App Store and Snap, a lot of my most regularly used items are mobile websites. Many companies have excellent mobile sites, you can save them as bookmarks to your homescreen, they pull in the favicon and look just like apps. You don't have to install updates for them or worry that they'll stop supporting your OS version or particular hardware, and a lot of times they're a better experience than the corresponding native (or sideloaded) apps.

[1] http://blogs.blackberry.com/2015/01/surprising-winner-of-html5-apps-war/

I found some notes from when I was looking into the Priv at the end of last year. They lack detail, but maybe are a good starting point for someone.

* Root of trust: unique crypto keys at the hardware level: Somehow implemented in way that guarantees Blackberry through supply chain, they claim. Maybe Blackerry supplies own chipset, w/ key included?

* Verified Boot and Secure Bootchain: Verifies integrity of all layers, from hardware to software. Uses hashes, crypto signatures

* hardened Linux kernel with numerous patches and configuration changes to improve security

* FIPS 140-2 compliant full disk encryption for data and applications

* Monthly updates through the Google Play store (only?)

* DTEK: "a single dashboard to monitor and control application access to your microphone, camera, location and personal information."

* Can customize each app's privacy settings, like in Android 6

Also of potential interest, from a competitor:

* http://www.tomshardware.com/news/copperhead-nexus-more-secure-priv,30565.html

----

Sources:

* http://blogs.blackberry.com/2015/10/priv-is-for-private-how-blackberry-secures-the-android-platform/

* http://www.zdnet.com/article/the-many-ways-blackberry-beefs-up-android-security-on-the-priv/

Yes but the host he's using is Apple Silicon, I think what he's talking about is QEMU using Apple's Hypervisor Framework, which is what vmware Parallels, etc also use nowadays. Booting an apple silicon version of MacOS on non-Apple hardware probably isn't going to possible for a while as it would require emulation.

In 2021 Blackberry, surprisingly, wrote this article about getting emulating the XNU kernel and getting it running on non-apple hardware, but its just a terminal:

https://blogs.blackberry.com/en/2021/05/strong-arming-with-macos-adventures-in-cross-platform-emulation

Someone would have to write something that can emulate/abstract the apple iGPU to get anywhere near a usable GUI - I'm no expert but I don't think this is going to happen anytime soon, so when Intel releases of MacOS stop happening apple hardware might be the only way to virtualize MacOS for a while

I have been using the BlackBerry Priv since it's release. One of the best things they have going for them is how quickly they apply the android security patches once they are available.

I think they have released every security patch on the day of the public disclosure since the Priv released. This blog post shows the release dates up until March atleast, and they've hit the Nexus release dates on all of them.

http://blogs.blackberry.com/2016/03/beating-expectations-android-security-patching-for-priv/

EDIT:

The beta branch for the Priv already applies 5th August security patch. Usually the official release is not that far (a week or so AFAIK).

http://m.gsmarena.com/latest_priv_marshmallow_beta_brings_august_security_patches-news-19710.php

Can you run it with a working framebuffer and peripherals? Probably not. You'd have to ask Corellium for their secret sauce Apple SoC virtualization.

Can you run it in some capacity? Yes. See https://blogs.blackberry.com/en/2021/05/strong-arming-with-macos-adventures-in-cross-platform-emulation and https://news.ycombinator.com/item?id=25064593

With additional work, it should be "possible" to do this on an ARM device and use KVM to get virtualized performance, with unsupported instructions/features trapping back to the hypervisor and being emulated in software.

All that said, it will probably be a long time (if ever) that you will be able to boot a virtualized ARM MacOS up to a graphical desktop.