Rick's b.log - entry 2015/06/08

The RMS Jive

And, yes, I consider an invasive app that I cannot remove to be malware. Not only that, but if I had given my Facebook information to the app, it would have been at the time when Facebook "oops accidentally modified many people's contact email addresses to point to Facebook". Need I say more?

Yes, developers routinely mistreat users - but a huge part of the problem here is not the developers, it is the wilful refusal of Android to implement anything that resembles a sensible permission system. Is it bad that an app wants location data and full internet access? Possibly. But these features are probably used by the advertising insert rather than the app itself. I have several apps that demand Internet access and location, and the app itself has no requirement for either. The advertising, on the other hand, does. And guess who supplies the core advertising system? This is why we will probably never have a option to enable and disable specific permissions in apps.

Likewise, for some historical bug, Android persists in combining the phone state (is the user making a call?) with all of the identity information of the device. A program like a music player may need to know when you are making a call so it can silence itself for the duration of the call. However, as a side effect that permission provides your IMEI, your phone number, possibly the number of the caller, etc etc. It would not be hard to split this into new permissions and provide fake identity details for apps that use "the old way" to determine if the device is in or out of a call. This quirk, from Android 1.something is still active in the latest version. Why?

Don't give me this backwards compatibility bull. It would be quite simple to have a three level permission system - level 3 is full access, level 2 is spoof access (the app is granted the permission but dummy data is returned - this is what is likely to be needed for all apps written to the current API because they wouldn't be able to handle...), level 1 is The Computer Says NO. I could cobble together a simple specification of this in an evening. Why, with all the resources Google has, can they not implement it for real?

Mr. Stallman then goes on to state that various operating systems themselves snoop, shackle, and contain backdoors. Well, yes, Google does have a backdoor. It is often used to push updates to Google Play Services, but it can also be used to remotely remove apps that contain nasties. Given that many users don't know about technical things, perhaps it is better for them if harmful apps can be removed rather than them continuing to use the app unaware? It is a double-edged sword, it can be used for good as well as bad. The balance is how much bad vs how much good.

As for snooping, this is not something specific to those nasty closed source operating systems. Ubuntu Unity's search is enabled for interactive searching, not just on your computer but on the internet. This can be a boon for some people, and it is enabled by default. Take a look at the small print of the licence:

Unless you have opted out [...] we will also send your keystrokes as a search term to productsearch.ubuntu.com and selected third parties so that we may complement your search results with online search results from such third parties including: Facebook, Twitter, BBC and Amazon. Canonical and these selected third parties will collect your search terms and use them to provide you with search results while using Ubuntu.

Enabled by default in the Ubuntu that I tried. That sounds like snooping to me.

Yes, apps snoop. The question is, do apps snoop because the developer is inherently malicious, or do apps snoop because they can and it might make a small additional income for the developer? I will say it again, the Android permission system is fundamentally broken. iOS is slightly better in that apps are sandboxed and "privacy" related functions prompt for permission and can be turned off, but the list of permissions is not as fine-grained as Android. Not that having a "run at startup" permission is any use at all if you can't tell the app not to run at start-up.

The discussion then descends into a rant about how proprietary software is just generally evil - you know, when the devil takes a dump, what's sitting in the pan is the next incarnation of Windows, blah blah. This is not really a surprise given the author, you can see this logic quite clearly in the GNU GPL FAQ that talks about how it is not permissible to include VisualC / VisualBasic DLLs in an installer for a GPL program because of how nasty and evil Windows is. Despite the GPL implying the opposite - section 1, "System Libraries", does not appear to say that such libraries cannot be included with the GPL program, as it says in the FAQ. This is just making up bull because Windows is counter to all of those grandiose ideals of "openness". Plus, the FAQ is just random spew. It is not the licence itself and thus carries no weight.

Yes, Mattel did make a Barbie doll that recorded children's speech and transmitted it to Mattel for analysis in order to figure out what was said (as children's speech is a lot more complicated than adults and would be difficult to process in a small microcontroller within the Barbie). Parents found this idea, rightfully, horrific. I am not even sure if such a device could be legally sold within the EU, there are rules regarding profiling and tracking children. I certainly would not buy one for my non-existent daughter, the whole idea is creepy.

There is no excuse in the case of the SmartTV. The TV in question was a Samsung, and the problem is that Samsung is tied up with "Nuance" voice recognition. Because of this, the company's products would rather send your voice across the internet for analysis and decoding than attempt to do it on the device itself. For example, my Motorola DEFY, several years ago, could respond to spoken commands. The phone itself processed these. My Xperia U did the same, but only via a Bluetooth headset for some reason. My Galaxy S5 Mini takes this a step further with Siri-like abilities, but like Siri, it doesn't attempt to process and interpret on the phone. So by using "SVoice", you will be sharing not only your voice but also your contacts list, location, etc with Nuance. At least it asks you to agree to the terms up front:

[...] To provide [...] language processing functions Nuance Communications ("Nuance") may collect: (i) your location data, (ii) your vocal data, (iii) your stored data (e.g., contact names, music information), (iv) your device data [...] (v) your usage data. Collected data may be used by Nuance and its partners for (i) service provision, (ii) service improvement, and (iii) statistical purposes. By clicking the "I agree" tick box below, you hereby agree to [...] the collection, use, storage, sharing and disclosure by Nuance and its partners of data from your device for the purposes set out above [...]

Sorry, that's a deal breaker for me. If I want to ask my phone "Who is best placed for winning The Tour de France this year?" or "What is the average flight speed of an unladen swallow?" or "Who the hell is Bruce Caitlyn Jenner?" then by all means involve a third party. But if I want to ask my phone "call mom mobile" or "what time is it?", there is no excuse for a 1.4GHz quad-core device not being capable of dealing with this internally. Sharing my contact data and whatever is considered "device" and "usage" data is unacceptable. The best way to deal with data sharing on your device is....to simply not permit it. Am I losing a useful function of my phone? Perhaps. Am I wilfully sharing my personal data with Nuance and unknown "partners"? No.

Richard then suggests that we reject proprietary software as a way of retaining our freedoms, but I think he is missing the larger picture here. We should not be rejecting proprietary software, we should be rejecting proprietary protocols. Things should be supported and encouraged if they are interoperable, openly documented, and follow a consistent API. Then it does not matter if we choose to use a closed source app, or one that somebody wrote themselves and released the source code. A case in point is the iPad that I am writing this on has Bluetooth built in. In fact, I'm using a Bluetooth keyboard. I think that's about the only Bluetooth device I own that works with the iPad. Can I pair with my phone? Sure. Can I pair with the netbook? No problems. Can I do anything at all with any of these devices? Uh... No. In order to transfer a photo from the iPad, I have to either use the pain of iTunes or I have to email it to myself and pick up that email on another machine. Or, in the case of this document, I used Google Docs as an intermediary.

It's 2015, guys. Not cool.

That's not to say that iOS cannot do these things. It can. Via AirDrop. To other Apple devices.

My netbook? My Android phones? They can shift files to each other - how do you think the screenshots got from my phone to the netbook? Sometimes it is easier to push an MP3 or JPEG from the PC over Bluetooth than to hook up the cable and do all that stuff. Which is how it should be. It doesn't matter is the systems in use are open or closed. It just matters that they work. So the important thing is not system openness, it is protocol openness.

The thing is - of all of the stuff that Richard points out, there is no guarantee whatsoever that free and open source is not going to fall prey to the same issues. As I mentioned, the Unity searching shares information by default so it clearly isn't immune to snooping issues. ShellShock, Heartbleed and OpenSSL adequately demonstrate that open source is not inherently more secure, and that while the masses can examine the source code, it seems rather evident that they just don't unless there is a problem. Yes, certainly, there are regular updates for Linux. Well, you know what? Microsoft does regular updates too.

And, finally, the issue of shackling. It is an interesting one here. We may be shackled by the licences of the software we use, especially those products that are tied to a subscription model (Office365, for instance), and it makes me wonder what value your documents will have if you decided not to continue your subscription. I prefer the idea of "pay for the product, it's yours". I have some old WordPerfect files around from many many years eons ago, and I also have the WordPerfect5.1 discs. I can install that. Probably on DOSbox these days, but it can be installed and used, a quarter century later.

In the world of open source, we are not shackled by the use of open source software. But we may well be shackled by the use of any of the source. There is a reason why no GPL code is permitted within the RISC OS codebase. There is OSI-definition open source present - CDDL, bsd, etc - but no GPL.
The thing is, these other licences do not require that the entire code be instantly and completely converted to GPL just by mere proximity. The GPL itself is unclear on the scope of linkage and the general idea is that this issue is something best left for the courts to decide. As far as I am concerned, it is an utter fail of a licence if the terms are not clearly defined from the outset (actually, they are - you cannot use any GPL code with non-GPL code in any way - but whether or not this is even enforceable or reasonable has yet to be tested in a court).
The idea of various linkages makes sense in how Linux operates. It does not make sense in how one builds a RISC OS ROM image (and the same sort of static linking applies to all smaller embedded systems that simply do not have a filesystem . . . and what makes a filesystem different to a big wodge of binary? what if I implement a filesystem within the ROM image, you know, like AppFS... the whole thing is just nonsense). It is no surprise that some hav considered GPL itself to be "viral", "infecting", and like a "cancer". Ultimately, GPL is truly only compatible with itself to the specific exclusion of the entire rest of the open source movement. Most open source licences aren't too concerned about what the open source code is linked with, so long as the source remains available. Some, like the revised bsd, are not even concerned with that. Others, like the EUPL, are willing to allow the code to be relicenced in order to become compatible with other less enlightened open source licences. The GPL? Is not only interested in GPL, but also in tainting everything that it touches with GPLness. Funny attitude for those who claim to extol the virtues of open source. The one out of step here is the GPL, so the simplest approach to the problem is to simply mandate "no GPL".
Being "shackled" takes many forms, some less obvious than others, and the issue is not as clear cut as "open source good, everything else bad".

Where I work, they set up a stock control system based upon Linux. The problem was, the software was buggy. The stock would be scanned in (reception) and scanned out (use) on site, and for traceability, the products being made would be scanned through production and pick'n'pack. There's a lot of little barcode stickers and a lot of beeping stuff with the barcode reader.
The on-site machines would communicate with the main database at the head office site. Somewhere along the way, this communication was lost or corrupted, and for some reason, the local machines would behave as if everything was okay instead of flagging that a fault had happened. Well, you can guess the resultant chaos when actual stock and database record differed. I do not know exactly what happened but they persisted with it for a couple of months. I rather suspect the IT guy was told something like "you have the source, you fix it" which is utterly not how a business expects to operate.
Then, one day, they went back to Windows. All of it. The Ubuntu desktop machines, OpenOffice, the lot. Every bit of Linux was removed (in what must have been an utter crushing defeat to those who believed in the virtue of open source systems). I think it says something that the cost of having Windows licences for Windows and all the software was decided as being more cost effective than free. Free? At what price is free?
Just to follow up, the new stock control system didn't do something obscure they the company needed. Somebody visited and an upgrade was produced, tested, and rolled out. That is how a business turning over a lot of stock (and big numbers that I cannot mention, let's just say enough to buy a nice house in the Mediterranean area - this sort of ballpark (damn, nice looking property!)) expects to do things. Results, not farting around with half-baked source code.

So there are benefits to closed source products. Remember this the next time you go into a supermarket and see the checkouts running Windows (probably still using XP!). Remember this when you see photo booth software running on Windows. Remember this when you see price check machines running Windows. One is tempted to say "you get what you pay for". While Linux is a solid operating system, it is very good at specific things. Running hardcore servers? It'd be a Linux box over Microsoft. Running user facing software? It seems Windows has better compatibility here. Running a desktop operating system? Well, surely this is decided by what the user actually wants - and even though most PCs come with Microsoft pre-installed, I wonder how many are more familiar with iOS and Android these days?

Or, in short, an open source system is only one option of many and has good points and bad points, just like all the others. It would be better perhaps for a user to choose what works best for them instead of worrying about idealogical crusades.

Interfacing a USB joystick to RISC OS

I don't play games, except once in a while on a PS2, so I have no idea where this joystick came from. And being USB, it would be useful for.... well... not a lot that I have.

I had the bright idea of plugging it into RISC OS. But how would one talk to this device? I opened it up to see what was inside it, and the component side of the board give zero hints:

Okay then. I'm on my own. I guess it'll have to be the old-fashioned way. I plugged the device into the Pi and !USBInfo reported it was present as an HID (Human Interface Device - keyboards, mice, etc fall into this category). It has a single inpoint, claiming to have an 8 byte buffer.

On my machine, the joystick was enumerated as USB device "USB8". So to access it, I open a file with read-only access using this pathname "devices#endpoint1:USB8". This is a special path that tells DeviceFS to return a handle to endpoint 1 on device USB8.
RISC OS does, so it is simply a matter of pressing buttons to see what turns up.

As it happens, the protocol is remarkably simple. Every transition (press or release) outputs three bytes.

• The first byte is for the left and right value.
  Left returns a value of &00, right returns a value of &FF.
  If neither left nor right is pressed, then this byte will be &80.
  I think it would be best to check for less than or greater than &80 as I suspect analogue joysticks may use the same protocol, only with varying values.
• The second byte is as above, only this time it is for the up (&00) and down (&FF) value.
• The third byte is a bitmap of the remaining buttons, of which there are eight. If a button is pressed, its bit will be set. All buttons pressed is &FF, default (no buttons pressed) is &00.
  • Joystick top - Left = &01
  • Joystick top - Up = &02
  • Joystick top - Down = &04
  • Joystick top - Right = &08
  • Joystick rear - Left upper = &10
  • Joystick rear - Left lower = &20
  • Joystick rear - Right upper = &40
  • Joystick rear - Right lower = &80

I put together a program to interpret and display button presses:

The logic is very simple. If there is data to be read (should be three bytes, or a multiple of), read the bytes. Then...

      if (byte_one < 0x80)
         // Left

      if (byte_one > 0x80)
         // Right

      if (byte_two < 0x80)
         // Up
         
      if (byte_two > 0x80)
         // Down

      if (byte_three & 0x01)
         // Left
         
      if (byte_three & 0x02)
         // Up
         
      if (byte_three & 0x04)
         // Down
         
      if (byte_three & 0x08)
         // Right

      if (byte_three & 0x10)
         // (rear) Left upper
         
      if (byte_three & 0x20)
         // (rear) Left lower
         
      if (byte_three & 0x40)
         // (rear) Right upper
         
      if (byte_three & 0x80)
         // (rear) Right lower

That said, you have the source alongside the program. It is open source, EUPL v1.1 (only) - not GPL. Feel free to hack!
Builds on RISC OS with the DDE. You'll also require my 32 bit port of DeskLib if you wish to build the source.

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

VinceH, 9th June 2015, 14:36

Software on a subscription basis... software as a service (SaaS)... DaaPR (Data as a Protection Racket)    Just saying.

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 67552 backwards.
		Your comment