AlfredCamera is a software solution that can turn a smartphone – with a camera, of course – into a surveillance camera. It is easy to use, and yes, it does work fine – I tested it with a Samsung Galaxy S7 as my “security camera”. The application unerringly detected me when I entered the room and created a time-stamped photo in the log.
Sample picture from the Alfred Camera website.
But is it really secure? The website does not really address this issue. I do worry about the privacy of my video stream. Where exactly are the images and the corresponding data stored? Are the images encrypted on their way to the AlfredCamera website? Can I be certain that I’m the only one to access those data?
I hesitate to use this solution as a webcam in our house during our holidays because of a lack of answers to these and other questions. Does anyone have more information on the matter? Do you have any experience with Alfred?
Sometimes it’s handy to have multiple browsers open at the same time, especially when you’re a web developer ;-) And until now, Google Chrome was often my choice number one – on Windows, that is. Given the current state of affairs, I’m lucky to have nothing but Macintosh and Linux machines at home, so the new so-called “privacy sandbox” won’t bother me too much. You don’t know what that sandbox is? Read up on Ars Technica: “Google gets its way, bakes a user-tracking ad platform directly into Chrome“.
Just to be sure, I did already follow the instructions in that article on my Mac:
Just go to the Chrome Settings, then “Privacy and Security,” then “Ad privacy” (alternatively, paste “chrome://settings/adPrivacy” into the address bar). From there, you can click through to each of the three individual pages and turn off the top checkbox, and in a mere six clicks, you can presumably turn off the ad platform.
So if I fire Chrome up in the future, I will be a bit protected from ad targeting (or so I hope).
Apple’s computers are too good – they keep working and working. Case in point: we still use a Mid 2007 iMac at home. And: I also still use a Macbook Pro from Mid 2012. Certainly we’re not the only people in the world that do not throw out our computer every three or four years.
Hence it would be… nice if Apple kept the software on those older machines up to date. I understand that Apple cannot implement every last novelty on those oldies. That’s not what I’m asking for. But security patches and certificate updates can’t be that hard to integrate in some sort of update package for earlier versions of Mac OS X. After all, email is still email, and web browsers from 10 years ago are still capable of displaying most current sites. Just covering those two functional domains might allow many Mac users to use their older machines. How about it, Apple?
One of the issues posed by these older Mac OS X versions is the browser message “This Connection Is Not Private” when trying to access a site over the secure https: protocol. This message means that there is a problem with one or more certificates in the certificate chain for that particular site. Usually it’s a matter of expiration: certificates are only valid for a specific period of time. That is also the case for the certificates that were used by the Certification Authorities that sign the TLS certificates for the website. As time goes by, some of those “root certificates” expire, making browsers like Safari pop up warning messages to tell you of the problem. The correction for this problem is easy: the root certificate has to be updated, and things will work again. As long as Apple updates Mac OS X on your Mac, they will do that for you, and you don’t have to worry about this problem (at least for websites that play by the book!). However, if you’re not familiar with the underlying mechanisms in the browser, the error message is actually blocking you from accessing the site – even when in fact there is nothing wrong with it (the problem is on your Mac!).
Can this problem be fixed on older MAC OS X versions, for which Apple no longer provides updates? Luckily, the answer is yes. But it is not a “click here and you’re done” kind of fix; you need to have some experience with the Terminal application and the bash command line on your Mac, and you also need access to a Mac with a recent (preferably the latest) version of the certificates.
Here’s the procedure, paraphrased from StackExchange. To simplify things, I’ll describe how to update all system root certificates in one swoop.
On the ‘newest’ Mac, launch the “Keychain Access” application.
In the “Keychain Access” application, click on “System Roots” in the left column, and select all certifcates in the list that appears (a single click in the that list, followed by Cmd-A).
In the File menu, select the option “Export Items…” and save the file as “rootcerts.pem“.
All the certificates will be stored in that single file. The first thing to do now is to transfer that “rootcerts.pem” file to your ‘old’ Mac. You can do so with a memory stick or card, by email, or by using some kind of cloud storage (Google Drive, Dropbox, etc.).
To do so you should log on to the ‘old’ Mac, using a user account that has administrator rights.
Put the “rootcerts.pem” file in a folder, e.g. “Downloads”.
Open the Terminal application, and go to the folder with “rootcerts.pem” file.
In that folder, create a new script file called ‘trustroot.sh‘ (yes, I prefer to add a .sh extension to that file in order to recognize it as such later on), and add the following content (using pico or the text editor of your preference):
Save the file and make it executable, using the command ‘chmod 755 trustroot.sh‘.
Everything is now in place; all that remains to be done is the execution of the script with the following command line (plus your sudo password, of course):
sudo ./trustroot.sh rootcerts.pem
You should see a list of certificate descriptors pass by in the Terminal window.
The certificates exported from your ‘new’ Mac will now be included in the list of ‘System’ certificates (as explained on StackExchange, only Apple can update the ‘System Roots’ keychain), but they will be taken into account just as well.
You can close your Terminal session now. It’s up to you to decide whether or not to keep the ‘trustroot.sh‘ script for future use; you will have to replace the rootcerts.pem file later anyway, with a more recent version of the certificates.
If everything went well, your browser should no longer show the dreaded message – except for sites that really have an expired certificate.
PS. I have changed the location of the temporary directory in the ‘trustroot.sh‘ script to the current directory, compared to what you see on StackExchange. I did that because I got an error message when running the ‘trustroot.sh‘ script that complained about “/” being a read-only file system. Somehow the settings of my Terminal shell had chosen “/” as the TMPDIR, and you can’t just create new folders there. Since the script deletes the temporary directory anyway, it’s location doesn’t matter; it will exist for a just a few seconds anyway…
From now on, it’s quite possible to get an ...@ik.me email address. I love that email address, since the Dutch word ‘ik’ means ‘me’ in English. How appropriate! So I registereed for one of those (free) addresses ;-)
The reason to choose such an address, of course, is not that little word play. Infomaniak is a Swiss hosting company that promises to be more ethical and respectful of privacy than the Microsofts and Googles we usually entrust with our online conversations. That was one of the reasons for our trade union section to choose this company to host our website and mail addresses.
Also, Infomaniak is doing a whole lot to be environment-friendly and “green”: their Charter is quite extensive and contains many realized goals, not just promises. We’ll see how that works out over the long haul…
I was pretty surprised when I read this – in fact, I had to read it a couple of times to make sure I read it right!
Following the intense scrutiny generated by the Colonial Pipeline hack, DarkSide appeared to be reconsidering this model. On Monday, a statement purportedly from the DarkSide hackers announced the group’s intention to closely scrutinize its partners’ planned attacks in the future to “avoid social consequences.” “Our goal is to make money,” the statement said, “and not creating problems for society.”
At work we’re still running ColdFusion 11, and that version is not mentioned in the report (probably because it is already out of support). Nevertheless I would to know whether CF11 is also concerned by this issue – if only to tell our IT security office that we have no problem with vulnerability CVE-2021-21087 in our configuration ;-)
I’m convinced 2FA is an excellent idea, and I’m already using it for a few situations like my Apple devices and a Google account. Of course I use two-factor authentication on my Apple devices – but that only goes so far, of course. Google also bugs me when logging in to another Google account on those devices, but keeps sending the confirmation to an Android device that I do not always have near me (and I haven’t found a way yet to alter that setting).
But I have always hesitated to apply 2FA to all the applications and websites I use. Why? Because it’s hard to pick the right tool – which one can be applied to most/all sites (and I have a lot of those)? Should I pick a hardware solution, or an application? What about backing up your keys? What if I lose my phone? Etc.
Don’t get me wrong: Goodin does an excellent job introducing the complexities of choosing a 2FA solution. But there are many more solutions available – just try any search engine and look for “2FA”. Years ago, I already looked at FreeOTP and andOTP, but I did not feel confident enough in their backup strategies to actually use them. I would also like to know more about privacyIDEA and its application to the problem.
The article mentioned however can be used as a measuring stick, to see whether your 2FA choice ticks the points that you really want/need. And if you don’t use any 2FA solution yet, at least make sure that you have all your (complex!) passwords in a decent password manager on all your devices – I still find Keepassium and the other members of the Keepass family very valuable.
You will have to read the original Github ticket – or one of its copies, in case the Github ticket were to be closed/deleted/… – but the essence of the message is that Chrome extension “The Great Suspender” (TGS) has become a very suspect suspender. According to the ticket, version 7.18 in the Chrome Web Store does not correspond to the source on Github, and has been modified in such a way that it could (can/will/…?) be used to invisibly execute tracking or malicious code!
I was a great fan of that extension: I’m always juggling reading material and lots of browser-based applications at the same time, and that extension made it possible to keep them all open yet limit the memory and CPU footprint of Chrome to more reasonable sizes. I read about the trouble yesterday, and did not hesitate to delete this extension from all my computers!
There is mention of a few alternatives to The Great Suspender; at least one of them is a copy of the latest “pure” version of TGS. But at the moment it isn’t available at the Chrome Web Store and requires a bit of manipulation to get it installed properly: that’s not for everyone.
By the way: if the ticket mentioned above is too technical for you, hop over to Life Hacker or The Register get their take on the subject.
Anyway, the worst part of the whole story is that Google does not seem to be interested in doing what it should do, that being to kick the extension out of its Web Store, at least while investigating the matter. But so far there seems to have been no reply from them, even though several people, including me, reported the extensions as incompatible with the rules of the Chrome Web Store. In the words of The Register:
The Register asked Google whether it plans to implement any measures to help make it easier for people to understand who maintains Chrome extensions and to understand code changes that have been made. We’ve not heard back.
I was wondering: should I install the belgian Coronalert app to help me know whether or not I have been in contact with COVID-19 contaminators? Many solutions to such “contact tracing” apps from all over the world have been found to be guilty of privacy invasions. I like to be on the side of the maximum privacy camp, so I went looking for serious discussions about the Belgian app. Sorry to say so, but the only valid discussion I could find was the report of the official security assessment, on the website of the application:
The report seems to be well done, and the conclusions in it are encouraging: there seem to be no serious issues when it comes to the security of the app and its data. I would have loved to see an independent review by one or more security researchers… But in the meantime it won’t hurt to install this; let’s just hope it does not drain the battery too much!
A couple of months ago I started my search for a good iOS app to replace MiniKeePass; I even wrote about it briefly on November 15th. The situation became very urgent when I switched iPhones two weeks ago: everything moved swiftly from iPhone One to iPhone Two – except MiniKeePass, which had disappeared completely from the App Store!
It took me a couple of hours to read up on the current state of KeePass affairs in the iOS world (thank you, reddit!), and a few more to test and re-test a few candidates. Since my wife will also be using the application, and we both also have an iPad, syncing with the iCloud was a must-have feature.
In the end, KeePassium turned out to be a winner after all. This time (and ever since!) it does open our .kbdx files without issues, and is well integrated with iOS and Face ID. That’s all we need at the moment. Thanks, Andrei!
PS. It must be happening more and more these days: apps that are no longer compatible with current OS versions, or that are no longer actively maintained by their developers. But I feel it might be worthwhile to keep a trace of them in the App Store (and similar repositories), if only when you search for them by name. I’ll give bonus points for a small explanation as to why they disappeared from current search results…
The list proposed isn’t perfect, but multiple items on the list are a good start: “Security Checklist: Be safe on the internet“. It’s an “open source checklist of resources designed to improve your online privacy and security“, and it does cover the basics: a password manager, strong passwords, two-factor authentication where possible, device encryption, etc. As a Belgian citizen, I don’t know what a “credit freeze” is, so I ignore that suggestion.
I’m not certain if I should classify it as a minor or a major flaw, but I feel that Keepass (and its variants/derivatives) should have been mentioned explicitly. I have written about Keepass in the past, and in my mind it’s still the best password management solution. Yes, it requires a bit of tinkering, but you really don’t need any advanced computer skills to build a strong, working solution for multiple devices that works online and offline. I prefer that to a paying solution which at the same time stores your precious data in a place that you just have to trust…
In the words of Julia Reda, MEP for the German Pirate party:
[On January 18, 2019, the European] Council firmly rejected the negotiating mandate that was supposed to set out Member States’ position ahead of what was supposed to be the final negotiation round with the European Parliament, Politico reports. National governments failed to agree on a common position on the two most controversial articles, Article 11, also known as the Link Tax, and Article 13, which would require online platforms to use upload filters in an attempt to prevent copyright infringement before it happens.
So for the moment the proposal on copyright reform isn’t going anywhere. This is not the end of the battle, however. But in the mean time, many thanks to Julia and to all of the people who helped to increase the pressure on the European politicians. Stay alert, and let’s keep fighting bad legislation!
It’s all over the Internet: the Telegram messaging application will be banned in Russia. Censorship is never good news, so why am I happy about the news?
It’s simple: if even the russian secret services/hackers can’t break the Telegram encryption, then their protocol and encryption must be very good! That’s good news for Telegram users and privacy lovers all over the world (except Russia, of course). And that makes me a happy user of Telegram.
Want to learn something about SSL and SSL certificates? I sure do, having just encountered an revoked certificate blocking an app at work. So I read “Revocation is broken” by Scott Helme. In summary:
We have a little problem on the web right now and I can only see this becoming a larger concern as time goes by. More and more sites are obtaining certificates, vitally important documents that we need to deploy HTTPS, but we have no way of protecting ourselves when things go wrong.
As you can guess, that didn’t really help to solve our problem – but it’s a clear explanation of the current state of affairs in certificate validation land, at least for browsers!
NUKLEOS weblog 
You must be logged in to post a comment.