It wasn't Apple, but there was a ribbon cartridge (Thunderscan) that one could swap out in order to use the ImageWriter II as a scanner.
On the Mac side, there was a scanner that one could use to obtain programs which were printed in a proprietary barcode/strip code format and were present in magazines for a few months until the publishers realized few people were buying the scanner.
This seems to be getting better. In a lot of the world, stick PCs running ARM and Android are becoming popular. One can spend $50-60 and get one here, although in emerging markets they are likely far cheaper just due to economies of scale.
No, they won't run the latest Crysis, but for something for basic application use, they do the task at hand quite well, and because they have no moving parts, are pretty reliable, and with cloud backups, loss of data can be minimized.
Where I pity my kids won't be CPU architectures, it will be vendor lock-in, DRM stacks, NAC (healthchecks), mandatory idenfitication, 24/7 tracking [1], and Draconian IP legislation. Take a new PC off the shelf, and there is a good chance that it will only run Windows 8 [2]. We are one calamity away from having laws passed that would force any machines to have DRM healthchecks before they are allowed onto the Internet at large [3], and it is only a matter of time before another ACTA/CETA treaty passes.
[1]: This is already here. During a job interview, I had to defend posts I made to sci.crypt and comp.sys.next.advocacy that I made to USENET in 1991.
[2]: Some PCs can turn off the secure boot. Others just don't have that option.
[3]: This is a common practice in companies where a PC has to respond that it has various software installed. However, replace Norton with some software dedicated to DRM, and that is what would come at us should a remote intruder manage to take down some piece of infrastructure on a large scale.
Probably one of the better magazines I bought was the old Computer Shopper, before it shrunk into a "regular" size magazine. Stain Veit's articles were always a treat, and even the ads were useful, back when there were tons of white-box makers (Arche, Bell, Austin PC, etc.)
The early Mac magazines were like this as well. If you had a special device that could scan, you could actually scan a page out of the magazine and have a couple useful applications each month.
I do miss the good magazines that just don't have ads, and ads masquerading as new product reviews.
On one hand, the shift from engineer to tinkerer to professional to drool-cup was inevitable, but on the other hand, there is something missed about getting a magazine that had something worth reading by a very knowledgeable author.
I wouldn't mind a system of going to a completely passive backplane architecture, although with electrical signal distances, this likely wouldn't be really doable until we have the ability to get optical signals onto the fiber from the chip die itself (which means a lot of muxing/de-muxing since having tons of optical connections would be a lot harder than solder pads.)
I'd say we end up back at the 1980s or early 1990s where companies had internal networks and did NOT connect them to the Internet. In fact, a lot didn't use IP, so bridging them would be difficult (doable, but hard).
Bingo. This is why I prefer hard-sided luggage. It holds less, but a thief isn't just going to pop the zipped area with a pen and have complete access to the contents.
9: The iPhone does have encryption. I'd insure it, set a password [1], set it to erase after 10 tries, set find your iPhone on, back it up, and call it done.
10: If really worried about data, I'd consider fedexing an encrypted HDD with your real stuff to the hotel, and using a dummy install on a trip. This way, a routine border search won't turn into a seizure and a visit to the local grey bar hotel when some guy sees encryption and you don't give them the unlock code. Even better, use the laptop as a glorified terminal, where accessing data is done through a VPN and a remote login.
11: Similar to #8 in the parent, but I'd consider using a work address (if possible), or one of the shipping receiving services (glorified post office box that accepts UPS and FedEx.) This way, the bags can be shipped -somewhere-, without revealing one's home address.
[1]: On the iPhone, if you set a password (not a PIN), and use all numbers, you will get a number pad when it asks for it. This makes it easy to enter in a >4 number code.
The *real* sensitive stuff, I'd see about having shipped insured by Fedex or another good shipping company. That way, you will be assured you get your stuff or a check for the amount of how much it cost.
Now, get yourself some TourSafe luggage from pacsafe.com. This has embedded "chainmail" in rather large links between the fabric. It won't stop someone determined, but it will slow the thief with the pocketknife. Then buy yourself a decent combo padlock. You don't need a Sargent & Greenleaf 8077AD. Get yourself a few decent locks (Non-TSA , obviously) and call the job done.
If you want to protect an existing backpack, PacSafe also has security "sacks" which can go over items, then lock to something.
This won't provide you with Fort Knox protection, but it will resist a sneak thief well enough.
My issue with password managers is that even though the passwords are stored in a secured basket, making backups of it, and having peace of mind that the backups are secured is difficult.
If I store the password database on Dropbox, in theory a cracker could slurp the file, fire up a bunch of cloud computing instances, and do some heavy brute-forcing. On smartphones, typing a long password accurately may not be the easiest task. I like having another mechanism of protection that isn't limited to a password that I can reasonably type on a smartphone. Since most smartphones have full disk encryption and will erase themselves after "x" amount of mistyped PIN entries, generally physical security is fine.
Probably the best compromise on Android is using Titanium Backup. Since restoring is not something one does often, setting a suitable (30+ character) passphrase is less of a PITA than having to type that in multiple times a day for access. Backups use a RSA keypair (the restore unlocks the private key), so an attacker with access to the stored data on a remote site ends up having to either brute force the RSA key, guess the passphrase protecting the private key, or deal with the full 256 bit keyspace of the key protecting the actual data.
What I would like to see is a password manager that allows one to copy a keyfile onto devices, especially iOS devices. (On Android, there are KeePass apps that allow this to be done.) This way, the passphrase doesn't have to be as long, but the data stored on an offsite storage service will not be able to be brute forced (other than an attack on the whole keyspace.)
What Jobs brought to the table was unquestionable authority, which is what Bill Gates had during MS's heyday. He gave the marching orders, and people under him performed.
Tim Cook is doing quite a good job, but he is a CEO. He may have the authority to hire/fire, but he doesn't have the "mandate" that made Apple under Jobs a cohesive entity. There is no RDF anymore.
Ultimately, Apple is going to need to find new markets if they are going to grow, as opposed to just stay still and try go squeeze more out of existing markets. There are still plenty of niches out there that would become rules by iDevices.
One idea would be a home audio "head" that would essentially be an iPod on steroids, designed to offer pro-level/audiophile-level audio. It would not just do what an iPod does, but because of the larger form factor, offer recording, playback, streaming of radio stations, high quality digital audio out (AES/EBU, S/PDIF), equalizing, and more DSP controls that could be packed in an iPod form factor. If Apple promised that it would not change dimensions or docking connectors for 10 or so years, third parties would be falling over themselves to make home audio systems that would accept the Apple "brains". It might even be useful in studios, provided it had a Thunderbolt connector for low-latency tracking/sequencing/recording.
Another would be car audio. Apple makes a 1-2 DIN "head", with some decent security features [1], have it do all the functions of an iPod Touch except with streaming, and Apple would have that market in a heartbeat.
[1]: Apple has always made devices where if they are locked, there is a method of resetting them, although it might cause the contents to be lost. With an audio deck, Apple would have to find a way of being able to have them lock when removed, and do it in such a way that there is no easy way to reset them. Even then, there is always just parting out the unit and selling the components. One ideal might be to have the unit come with not just a passcode that is typed in if the battery power goes out, but perhaps some type of physical key similar to how some Blaupunkt decks used to work.
For Apple to not stagnate, they will have to expand their market, and as a devicemaker with a good amount of cash, this probably can be done fairly easily.
Of course, there is always the enterprise. Apple historically has not been an "enterprise" vendor, but they can easily make inroads in the market given some thought.
From what I know about Chinese phones, they don't bother much with trying to have locked bootloaders, or anti-rooting measures. The hardware is meant to be mass-produced with a decently functional ROM in place (perhaps with an update or two to fix device issues.)
Of course, dual-SIM functionality comes into handy as well. Not just work/home lines, but if one does travel, one could get a disposable SIM from a Canadian/Mexican provider as well as the usual telco in the US.
The US has the iPhone, but other than that, there are a lot of advances in other smartphone ecosystems that end up our shores months to years after they are commonplace overseas. Quad-core CPUs are one example.
If I could root and unlock the device's bootloader, and there is some type of custom ROM ecosystem for the device, so much the better. In the past, I'd use Titanium Backup to save stuff to the SD card [1]. Worst case, I need to install the app on the new device via Google Play, then copy its data from the TB stash. If I were moving between the same model of devices, then nandroid becomes useful. As a secondary backup, Titanium Backup and another app made by the same people can sync data to Dropbox, so if the phone is lost completely, it isn't too bad a hit.
[1]: Call me crazy, but even though newer phones have 64GB of onboard storage, I wish they had a SDXC slot, just for backup reasons... phones are plenty thin, and the Android trend towards phablets [2] definitely provides some real estate where a card can fit.
[2]: I also wish Android phone makers would go to a smaller, but higher DPI screen. My HTC One X+ with a decent case won't even fit into a drink holder. I'm guessing one reason for the larger sizes is more heat dissipation required for the quad-core CPUs.
Web browsers are the front line in the security fight too. It used to be that the biggest point of attack was the firewalls. Now with packet inspection on even the inexpensive home routers, as well as IDS/IPS appliances being relatively inexpensive, going in via the Internet is fairly difficult.
However, Web browsers and add-ons are the gold rush for malware authors. Add-ons until recently tended to be written at best to support functionality; security was an afterthought, if there was any thought to it at all.
Having a Web browser constantly updated, especially if it is response to potential new attacks against it or add-ons is a good thing. It is one of the few software programs on client machines that is always in contact with untrusted and potentially malicious code on a constant basis. Even trustworthy sites can have ad servers which expose visitors to malicious code.
It is understandable to have a stable browser in the enterprise. However, even IE is updated monthly on average, perhaps more if an out of band patch is required.
The best compromise would be something like FirefoxADM, where on the internal WSUS patch release, push out Firefox as well.
Until the Web browser stops becoming the main staging ground for intrusions, having constant updates is a good thing.
If the technology came down in price (say to $100-$200), where this would shine would be a possible successor to tape drives. Since Flash drives can be made in almost any shape, creating a form factor that is made to be used in a robot silo with highly dense packing of the drives would be easily doable. Combine that with the second that the media is mounted, I/O can start happening (unlike tapes which require the drive to physically grab the media and swish it past the heads.) Shoe-shining would be a thing of the past. The silo also could quickly scan media in use for errors and relocate it either when it isn't busy, or have dedicated read/writes just to do that. Add hardware based compression and encryption, and this would be a solution that would replace tape in a footprint much smaller.
Of course, there is the fact that SSDs are not recoverable if something happens to the cells, while tape can sit for decades and still be used. However, with an active media management cycle and a backend program checking and moving data before it gets nailed by bit rot, this can be minimized.
In a media cycle, there is always the destruction or erasure of data. With flash/SSD, this is trivial -- if the drives are not self-encrypting, have the OS fire off a TRIM command, zeroing all sectors. If the drives have built in encryption, purge the key, recreate another one, then fire off a TRIM command. If the SSD needs physically destroyed, there is always the ability to add e-fuses so the drive can be zapped on the electronic level making recovery requiring the resources of a chip fab.
I'm happy HIPAA is being enforced. We have already had way too many breaches, either tapes left in unsecured locations, or laptops "going missing".
We already have had a decade of businesses giving security the hind teat, since it is viewed as a cost center, and the belief that "calling Geek Squad" after the fact can fix things. Having it made public that if laws/regs are broken, that fines will be levied might get places to zip their flies.
Encryption of laptops is not hard, especially Windows laptops that are the mainstay in business that have TPM chips. With any Windows version newer than Vista, Bitlocker is very easy to enable on an enterprise level. For most things, just forcing BitLocker via GPO on laptops, even if the user is a full admin is more than good enough for security.
For laptops without a TPM, Windows 8 and Windows Server 2012 allow for a password to be set before boot.
Almost all new major operating systems have some form of DAR/WDE encryption ready to go. Linux has LUKS, BSD has gbde, AIX has EFS, Solaris has encrypt(1), OS X has FileVault II. Enabling this may not be trivial, but it is doable.
Of course, almost all new backup programs have encryption, usually create/import a key, set a button to encrypt, and let fly. Netbackup has the Media Server Encryption Option, but even better, if one uses LTO-4 or newer media, NBU can just use the tape drive native AES encryption directly.
There is no excuse for encrypting laptops and media these days. None.
For sensitive applications, as well as confidential+, banning cellphones goes without saying.
However, if a company is afraid of people taking pictures in general, then they have an HR issue or an issue with their management technique, something that is not going to be solved by anything technical, even mandatory body cavity searches.
Company morale is a concept often ignored by the PHB types (it isn't a revenue stream like the MBA class teaches), but ignoring that aspect means that employees can and will get around rules put in place. Yes, that cellphone may be banned... but there will be the guy coming in with the spy camera who will be doing it just to get around what he/she feels are tyrannical rules.
The ironic thing is that companies who focus on the morale aspect tend to have fewer security problems in general, mainly because employees tend to either actively adhere to policies in place, or even actively report "hmm, that's not right" incidents. If a fire door is ajar, an employee would make sure it is closed.
Contrast this to companies with poor morale where at best employees might comply to policies only if their job was at stake, and anything out of the ordinary would be ignored, "they don't pay me enough to report that the fire door is cracked open."
As with most technologies, early adopters tend to front a good chunk of the costs to develop a technology. This is normal, because it takes time to make something that can be mass produced and stuck in all car models.
I have paid extra for safety technologies. My previous vehicle (which I bought almost 20 years ago, and is kept in roadworthy shape) I paid extra for four wheel ABS. My current ride, I paid for the higher trim level so I could get the backup sonar and a camera. Yes, it might be pointless, but a solid thump of another vehicle would cause enough damage to more than pay for the safety upgrade, and this isn't factoring in injuries.
Even the best driver makes mistakes. Of course, nothing is perfect, and if implemented wrong can be more of an annoying nanny than an actual safety feature, but if done right, can be extremely useful in situations where a human may not have the reaction time to handle a situation (swoop and squats on highways for example, which is more common due to people looking for insurance money.)
There is one good thing about Windows 8 -- Metro apps, or whatever MS calls them now (Microsoft Store Apps.)
These store their files in a restricted subdirectory in the user's homedir, and run in an extremely limited security context.
What I want to see is a real Web browser as a Metro app. This way, if the browser or an add-on running under it gets taken over, it can't get to a full user context, much less get control of the machine [1]. Same with an IMAP client. This is not to replace existing MUAs and Web browsers, but a restricted place to browse privately [2] with less exposure possible to malicious software.
I'm not a fan of workflow with Metro apps, but I do like the security contexts that limit things. It doesn't solve everything, but it is a good tool in a toolbox.
[1]: Nothing is impossible, but restricted contexts are a good start.
Africa is a huge continent. The US gets flooded with pictures of kids starving on a constant basis, but in reality, there are a lot of countries with a middle class, with middle class problems.
What I wonder about is the concept of small, but agile ISPs, small enough to provide security on their end (firewalls, outgoing port 25 blocking unless it goes through a relay, even perhaps more active IDS/IPS items like blocking C&C hosts.) ISPs small enough that they can handle threats rapidly, but large enough to be fairly profitable.
Defense in depth is critical, but there are places where one gets more bang for their naira on the network topology, mainly the edge routers, as well as different user segments.
Just offering an "antivirus kit" won't help much, because of the difficulty of AV programs in catching zero-days. Ideally an IDS/IPS, with some way to allow subscribers to bypass it if they have some special requirement (like a personal mail server, or running some other incoming process) would help catch the larger attacks, and help protect against DoS/DDoS attacks which won't take down the ISP, but can take down a subscriber on DSL or cable.
Nothing is perfect, but this is better than nothing.
This reminds me of the old IBM light pens of yore... I really don't see much difference between this and those, or the wired pens that were used on old Gridpads in the early 1990s.
Competition is good, but I don't want yet another locked down app platform to choose from. The least locked down is Android because having full root control of the phone does not mean that apps are in any way less contained (unlike iOS where a JB means that the internal security is completely compromised, and apps can write outside of their cells.)
If I could have the ideal OS, it would be like Tizen, except it would allow the RPM packages to have signed native code (which can be written in C, C++, or anything that can produce a Linux ELF binary.) That way, no JIT is needed except for the UI stuff. The OS would enforce permissions with SELinux, perhaps with chroot as well.
On the user side, permissions would be done similar to iOS and BlackberryOS. If an app wants access to the phone, GPS, contacts, music, photos, or other items, the user will be asked.
Of course, there would be a mechanism similar to ADB so if a phone is completely corrupted, it can be booted in a recovery mode, accessed from a desktop computer, the encrypted LUKS filesystems mounted, and either files recovered, or new images copied over.
All and all, the closest thing to an open, usable phone distro is Android on a rooted device with an unlocked bootloader. I think the way HTC handles bootloader unlocking is a fair compromise between keeping a novice user relatively safe, while allowing the tech savvy people who build, develop, and change ROMS the full use of their device.
Bingo. Also as important is their security model and app structure:
Tizen uses sandboxes (where apps can read their files and system libs, but not other app directories), similar to iOS and a security manager called SMACK (Simple Mandatory Access Control Kernel). It uses two UIDs, root and the UID the apps run under. For package management, it appears to use RPM.
I see a number of good/bad/ugly points about it. If I have root on the device, in theory, it should not affect app security (unlike iOS where a jailbreak kills all app security.)
The biggest downside is that apps have to be written in HTML5. It would be nice if the platform allowed native binaries to be used, but it appears that all apps have to be in HTML. This by itself is a downer, as I don't know of any JIT interpreter for HTML, and the translating is relatively slow.
So, (and this is IMHO of course), for writing relative fluff like another Angry Birds port, Tizen will be fine. However, if I'm looking to do something more complex than that on the platform [1], that would be difficult, and with the HTML5 translating, would require a lot more CPU than the Dalvik JIT VM, or iOS's Objective-C binaries.
It would be nice if Tizen's RPM packages could offer both... so I can have a HTML5 frontend for the UI, but have Linux binaries [2] for the serious work.
[1]: On Android, I can pop up a command shell, fetch a confidential Word document via sftp, fire up an Office app to edit it, convert it to PDF, gpg sign and encrypt it, then E-mail it to a potential client, all on a device that has hard disk protection. On iOS this is doable (although with a jailbroken device, it is far easier). However on a device that just groks HTML5, doing this type of workflow would be impossible.
[2]: Assuming there are usable libraries on the system. I can always statically link, but that would mean the apps made would be porky.
Call me crazy, but instead of ethanol, why not get more vehicles that can run B100 diesel? If people want to talk about a fuel that doesn't take dino carbon and put it in the air, nothing beats WVO, WMO [1] or other waste oils.
Of course, a diesel car has to have a lot more subsystems than a gas engine (EGR, DEF, DPF, multiple pumps, glow plugs, and many other components that have to be maintained.) However, if one really wants to be "green", B100 is as good as it gets. To boot, it doesn't take crop space away.
IMHO, a diesel engine is the way to go. Chrysler has been developing a true multifuel engine that is a Diesel cycle (not an Otto cycle) engine... but it has the option to use gasoline, as well as diesel.
[1]: Waste motor oil is still dino juice, but better have it used as fuel than have to reside in tanks to be disposed of. On some diesel sites, people report success with submicron filtering, mixing it with regular diesel, and using that.
Ethanol is very nasty stuff when it comes to small engines like generators. Because most of these are use carburetors, they are very sensitive to varnish and bad gas. In the past, one could leave gasoline in a tank over the winter and be OK. With E10, using stored gas of that length can result in a carb rebuild, or in some cases (newer Onans), a possible replacement.
Yes, one can use Sta-Bil or other additives, but they are more of a band-aid solution than anything else.
It wasn't Apple, but there was a ribbon cartridge (Thunderscan) that one could swap out in order to use the ImageWriter II as a scanner.
On the Mac side, there was a scanner that one could use to obtain programs which were printed in a proprietary barcode/strip code format and were present in magazines for a few months until the publishers realized few people were buying the scanner.
This seems to be getting better. In a lot of the world, stick PCs running ARM and Android are becoming popular. One can spend $50-60 and get one here, although in emerging markets they are likely far cheaper just due to economies of scale.
No, they won't run the latest Crysis, but for something for basic application use, they do the task at hand quite well, and because they have no moving parts, are pretty reliable, and with cloud backups, loss of data can be minimized.
Where I pity my kids won't be CPU architectures, it will be vendor lock-in, DRM stacks, NAC (healthchecks), mandatory idenfitication, 24/7 tracking [1], and Draconian IP legislation. Take a new PC off the shelf, and there is a good chance that it will only run Windows 8 [2]. We are one calamity away from having laws passed that would force any machines to have DRM healthchecks before they are allowed onto the Internet at large [3], and it is only a matter of time before another ACTA/CETA treaty passes.
[1]: This is already here. During a job interview, I had to defend posts I made to sci.crypt and comp.sys.next.advocacy that I made to USENET in 1991.
[2]: Some PCs can turn off the secure boot. Others just don't have that option.
[3]: This is a common practice in companies where a PC has to respond that it has various software installed. However, replace Norton with some software dedicated to DRM, and that is what would come at us should a remote intruder manage to take down some piece of infrastructure on a large scale.
Probably one of the better magazines I bought was the old Computer Shopper, before it shrunk into a "regular" size magazine. Stain Veit's articles were always a treat, and even the ads were useful, back when there were tons of white-box makers (Arche, Bell, Austin PC, etc.)
The early Mac magazines were like this as well. If you had a special device that could scan, you could actually scan a page out of the magazine and have a couple useful applications each month.
I do miss the good magazines that just don't have ads, and ads masquerading as new product reviews.
On one hand, the shift from engineer to tinkerer to professional to drool-cup was inevitable, but on the other hand, there is something missed about getting a magazine that had something worth reading by a very knowledgeable author.
I wouldn't mind a system of going to a completely passive backplane architecture, although with electrical signal distances, this likely wouldn't be really doable until we have the ability to get optical signals onto the fiber from the chip die itself (which means a lot of muxing/de-muxing since having tons of optical connections would be a lot harder than solder pads.)
I'd say we end up back at the 1980s or early 1990s where companies had internal networks and did NOT connect them to the Internet. In fact, a lot didn't use IP, so bridging them would be difficult (doable, but hard).
Bingo. This is why I prefer hard-sided luggage. It holds less, but a thief isn't just going to pop the zipped area with a pen and have complete access to the contents.
As for electronic items, my two cents:
9: The iPhone does have encryption. I'd insure it, set a password [1], set it to erase after 10 tries, set find your iPhone on, back it up, and call it done.
10: If really worried about data, I'd consider fedexing an encrypted HDD with your real stuff to the hotel, and using a dummy install on a trip. This way, a routine border search won't turn into a seizure and a visit to the local grey bar hotel when some guy sees encryption and you don't give them the unlock code. Even better, use the laptop as a glorified terminal, where accessing data is done through a VPN and a remote login.
11: Similar to #8 in the parent, but I'd consider using a work address (if possible), or one of the shipping receiving services (glorified post office box that accepts UPS and FedEx.) This way, the bags can be shipped -somewhere-, without revealing one's home address.
[1]: On the iPhone, if you set a password (not a PIN), and use all numbers, you will get a number pad when it asks for it. This makes it easy to enter in a >4 number code.
Here is what I do, if on a long train trip:
The *real* sensitive stuff, I'd see about having shipped insured by Fedex or another good shipping company. That way, you will be assured you get your stuff or a check for the amount of how much it cost.
Now, get yourself some TourSafe luggage from pacsafe.com. This has embedded "chainmail" in rather large links between the fabric. It won't stop someone determined, but it will slow the thief with the pocketknife. Then buy yourself a decent combo padlock. You don't need a Sargent & Greenleaf 8077AD. Get yourself a few decent locks (Non-TSA , obviously) and call the job done.
If you want to protect an existing backpack, PacSafe also has security "sacks" which can go over items, then lock to something.
This won't provide you with Fort Knox protection, but it will resist a sneak thief well enough.
My issue with password managers is that even though the passwords are stored in a secured basket, making backups of it, and having peace of mind that the backups are secured is difficult.
If I store the password database on Dropbox, in theory a cracker could slurp the file, fire up a bunch of cloud computing instances, and do some heavy brute-forcing. On smartphones, typing a long password accurately may not be the easiest task. I like having another mechanism of protection that isn't limited to a password that I can reasonably type on a smartphone. Since most smartphones have full disk encryption and will erase themselves after "x" amount of mistyped PIN entries, generally physical security is fine.
Probably the best compromise on Android is using Titanium Backup. Since restoring is not something one does often, setting a suitable (30+ character) passphrase is less of a PITA than having to type that in multiple times a day for access. Backups use a RSA keypair (the restore unlocks the private key), so an attacker with access to the stored data on a remote site ends up having to either brute force the RSA key, guess the passphrase protecting the private key, or deal with the full 256 bit keyspace of the key protecting the actual data.
What I would like to see is a password manager that allows one to copy a keyfile onto devices, especially iOS devices. (On Android, there are KeePass apps that allow this to be done.) This way, the passphrase doesn't have to be as long, but the data stored on an offsite storage service will not be able to be brute forced (other than an attack on the whole keyspace.)
What Jobs brought to the table was unquestionable authority, which is what Bill Gates had during MS's heyday. He gave the marching orders, and people under him performed.
Tim Cook is doing quite a good job, but he is a CEO. He may have the authority to hire/fire, but he doesn't have the "mandate" that made Apple under Jobs a cohesive entity. There is no RDF anymore.
Ultimately, Apple is going to need to find new markets if they are going to grow, as opposed to just stay still and try go squeeze more out of existing markets. There are still plenty of niches out there that would become rules by iDevices.
One idea would be a home audio "head" that would essentially be an iPod on steroids, designed to offer pro-level/audiophile-level audio. It would not just do what an iPod does, but because of the larger form factor, offer recording, playback, streaming of radio stations, high quality digital audio out (AES/EBU, S/PDIF), equalizing, and more DSP controls that could be packed in an iPod form factor. If Apple promised that it would not change dimensions or docking connectors for 10 or so years, third parties would be falling over themselves to make home audio systems that would accept the Apple "brains". It might even be useful in studios, provided it had a Thunderbolt connector for low-latency tracking/sequencing/recording.
Another would be car audio. Apple makes a 1-2 DIN "head", with some decent security features [1], have it do all the functions of an iPod Touch except with streaming, and Apple would have that market in a heartbeat.
[1]: Apple has always made devices where if they are locked, there is a method of resetting them, although it might cause the contents to be lost. With an audio deck, Apple would have to find a way of being able to have them lock when removed, and do it in such a way that there is no easy way to reset them. Even then, there is always just parting out the unit and selling the components. One ideal might be to have the unit come with not just a passcode that is typed in if the battery power goes out, but perhaps some type of physical key similar to how some Blaupunkt decks used to work.
For Apple to not stagnate, they will have to expand their market, and as a devicemaker with a good amount of cash, this probably can be done fairly easily.
Of course, there is always the enterprise. Apple historically has not been an "enterprise" vendor, but they can easily make inroads in the market given some thought.
This is good reading. There is good reason why people don't invent the wheel with cryptographic protocols.
Maybe it is time for a patch to the Linux kernel to make /dev/urandom non-blocking as well?
From what I know about Chinese phones, they don't bother much with trying to have locked bootloaders, or anti-rooting measures. The hardware is meant to be mass-produced with a decently functional ROM in place (perhaps with an update or two to fix device issues.)
Of course, dual-SIM functionality comes into handy as well. Not just work/home lines, but if one does travel, one could get a disposable SIM from a Canadian/Mexican provider as well as the usual telco in the US.
The US has the iPhone, but other than that, there are a lot of advances in other smartphone ecosystems that end up our shores months to years after they are commonplace overseas. Quad-core CPUs are one example.
If I could root and unlock the device's bootloader, and there is some type of custom ROM ecosystem for the device, so much the better. In the past, I'd use Titanium Backup to save stuff to the SD card [1]. Worst case, I need to install the app on the new device via Google Play, then copy its data from the TB stash. If I were moving between the same model of devices, then nandroid becomes useful. As a secondary backup, Titanium Backup and another app made by the same people can sync data to Dropbox, so if the phone is lost completely, it isn't too bad a hit.
[1]: Call me crazy, but even though newer phones have 64GB of onboard storage, I wish they had a SDXC slot, just for backup reasons... phones are plenty thin, and the Android trend towards phablets [2] definitely provides some real estate where a card can fit.
[2]: I also wish Android phone makers would go to a smaller, but higher DPI screen. My HTC One X+ with a decent case won't even fit into a drink holder. I'm guessing one reason for the larger sizes is more heat dissipation required for the quad-core CPUs.
Web browsers are the front line in the security fight too. It used to be that the biggest point of attack was the firewalls. Now with packet inspection on even the inexpensive home routers, as well as IDS/IPS appliances being relatively inexpensive, going in via the Internet is fairly difficult.
However, Web browsers and add-ons are the gold rush for malware authors. Add-ons until recently tended to be written at best to support functionality; security was an afterthought, if there was any thought to it at all.
Having a Web browser constantly updated, especially if it is response to potential new attacks against it or add-ons is a good thing. It is one of the few software programs on client machines that is always in contact with untrusted and potentially malicious code on a constant basis. Even trustworthy sites can have ad servers which expose visitors to malicious code.
It is understandable to have a stable browser in the enterprise. However, even IE is updated monthly on average, perhaps more if an out of band patch is required.
The best compromise would be something like FirefoxADM, where on the internal WSUS patch release, push out Firefox as well.
Until the Web browser stops becoming the main staging ground for intrusions, having constant updates is a good thing.
If the technology came down in price (say to $100-$200), where this would shine would be a possible successor to tape drives. Since Flash drives can be made in almost any shape, creating a form factor that is made to be used in a robot silo with highly dense packing of the drives would be easily doable. Combine that with the second that the media is mounted, I/O can start happening (unlike tapes which require the drive to physically grab the media and swish it past the heads.) Shoe-shining would be a thing of the past. The silo also could quickly scan media in use for errors and relocate it either when it isn't busy, or have dedicated read/writes just to do that. Add hardware based compression and encryption, and this would be a solution that would replace tape in a footprint much smaller.
Of course, there is the fact that SSDs are not recoverable if something happens to the cells, while tape can sit for decades and still be used. However, with an active media management cycle and a backend program checking and moving data before it gets nailed by bit rot, this can be minimized.
In a media cycle, there is always the destruction or erasure of data. With flash/SSD, this is trivial -- if the drives are not self-encrypting, have the OS fire off a TRIM command, zeroing all sectors. If the drives have built in encryption, purge the key, recreate another one, then fire off a TRIM command. If the SSD needs physically destroyed, there is always the ability to add e-fuses so the drive can be zapped on the electronic level making recovery requiring the resources of a chip fab.
I'm happy HIPAA is being enforced. We have already had way too many breaches, either tapes left in unsecured locations, or laptops "going missing".
We already have had a decade of businesses giving security the hind teat, since it is viewed as a cost center, and the belief that "calling Geek Squad" after the fact can fix things. Having it made public that if laws/regs are broken, that fines will be levied might get places to zip their flies.
Encryption of laptops is not hard, especially Windows laptops that are the mainstay in business that have TPM chips. With any Windows version newer than Vista, Bitlocker is very easy to enable on an enterprise level. For most things, just forcing BitLocker via GPO on laptops, even if the user is a full admin is more than good enough for security.
For laptops without a TPM, Windows 8 and Windows Server 2012 allow for a password to be set before boot.
Almost all new major operating systems have some form of DAR/WDE encryption ready to go. Linux has LUKS, BSD has gbde, AIX has EFS, Solaris has encrypt(1), OS X has FileVault II. Enabling this may not be trivial, but it is doable.
Of course, almost all new backup programs have encryption, usually create/import a key, set a button to encrypt, and let fly. Netbackup has the Media Server Encryption Option, but even better, if one uses LTO-4 or newer media, NBU can just use the tape drive native AES encryption directly.
There is no excuse for encrypting laptops and media these days. None.
For sensitive applications, as well as confidential+, banning cellphones goes without saying.
However, if a company is afraid of people taking pictures in general, then they have an HR issue or an issue with their management technique, something that is not going to be solved by anything technical, even mandatory body cavity searches.
Company morale is a concept often ignored by the PHB types (it isn't a revenue stream like the MBA class teaches), but ignoring that aspect means that employees can and will get around rules put in place. Yes, that cellphone may be banned... but there will be the guy coming in with the spy camera who will be doing it just to get around what he/she feels are tyrannical rules.
The ironic thing is that companies who focus on the morale aspect tend to have fewer security problems in general, mainly because employees tend to either actively adhere to policies in place, or even actively report "hmm, that's not right" incidents. If a fire door is ajar, an employee would make sure it is closed.
Contrast this to companies with poor morale where at best employees might comply to policies only if their job was at stake, and anything out of the ordinary would be ignored, "they don't pay me enough to report that the fire door is cracked open."
As with most technologies, early adopters tend to front a good chunk of the costs to develop a technology. This is normal, because it takes time to make something that can be mass produced and stuck in all car models.
I have paid extra for safety technologies. My previous vehicle (which I bought almost 20 years ago, and is kept in roadworthy shape) I paid extra for four wheel ABS. My current ride, I paid for the higher trim level so I could get the backup sonar and a camera. Yes, it might be pointless, but a solid thump of another vehicle would cause enough damage to more than pay for the safety upgrade, and this isn't factoring in injuries.
Even the best driver makes mistakes. Of course, nothing is perfect, and if implemented wrong can be more of an annoying nanny than an actual safety feature, but if done right, can be extremely useful in situations where a human may not have the reaction time to handle a situation (swoop and squats on highways for example, which is more common due to people looking for insurance money.)
I'm going to be a bit of a devil's advocate:
There is one good thing about Windows 8 -- Metro apps, or whatever MS calls them now (Microsoft Store Apps.)
These store their files in a restricted subdirectory in the user's homedir, and run in an extremely limited security context.
What I want to see is a real Web browser as a Metro app. This way, if the browser or an add-on running under it gets taken over, it can't get to a full user context, much less get control of the machine [1]. Same with an IMAP client. This is not to replace existing MUAs and Web browsers, but a restricted place to browse privately [2] with less exposure possible to malicious software.
I'm not a fan of workflow with Metro apps, but I do like the security contexts that limit things. It doesn't solve everything, but it is a good tool in a toolbox.
[1]: Nothing is impossible, but restricted contexts are a good start.
[2]: Pr0n sites, most likely.
Africa is a huge continent. The US gets flooded with pictures of kids starving on a constant basis, but in reality, there are a lot of countries with a middle class, with middle class problems.
What I wonder about is the concept of small, but agile ISPs, small enough to provide security on their end (firewalls, outgoing port 25 blocking unless it goes through a relay, even perhaps more active IDS/IPS items like blocking C&C hosts.) ISPs small enough that they can handle threats rapidly, but large enough to be fairly profitable.
Defense in depth is critical, but there are places where one gets more bang for their naira on the network topology, mainly the edge routers, as well as different user segments.
Just offering an "antivirus kit" won't help much, because of the difficulty of AV programs in catching zero-days. Ideally an IDS/IPS, with some way to allow subscribers to bypass it if they have some special requirement (like a personal mail server, or running some other incoming process) would help catch the larger attacks, and help protect against DoS/DDoS attacks which won't take down the ISP, but can take down a subscriber on DSL or cable.
Nothing is perfect, but this is better than nothing.
This reminds me of the old IBM light pens of yore... I really don't see much difference between this and those, or the wired pens that were used on old Gridpads in the early 1990s.
What is old is new again, I guess.
Competition is good, but I don't want yet another locked down app platform to choose from. The least locked down is Android because having full root control of the phone does not mean that apps are in any way less contained (unlike iOS where a JB means that the internal security is completely compromised, and apps can write outside of their cells.)
If I could have the ideal OS, it would be like Tizen, except it would allow the RPM packages to have signed native code (which can be written in C, C++, or anything that can produce a Linux ELF binary.) That way, no JIT is needed except for the UI stuff. The OS would enforce permissions with SELinux, perhaps with chroot as well.
On the user side, permissions would be done similar to iOS and BlackberryOS. If an app wants access to the phone, GPS, contacts, music, photos, or other items, the user will be asked.
Of course, there would be a mechanism similar to ADB so if a phone is completely corrupted, it can be booted in a recovery mode, accessed from a desktop computer, the encrypted LUKS filesystems mounted, and either files recovered, or new images copied over.
All and all, the closest thing to an open, usable phone distro is Android on a rooted device with an unlocked bootloader. I think the way HTC handles bootloader unlocking is a fair compromise between keeping a novice user relatively safe, while allowing the tech savvy people who build, develop, and change ROMS the full use of their device.
Bingo. Also as important is their security model and app structure:
Tizen uses sandboxes (where apps can read their files and system libs, but not other app directories), similar to iOS and a security manager called SMACK (Simple Mandatory Access Control Kernel). It uses two UIDs, root and the UID the apps run under. For package management, it appears to use RPM.
I see a number of good/bad/ugly points about it. If I have root on the device, in theory, it should not affect app security (unlike iOS where a jailbreak kills all app security.)
The biggest downside is that apps have to be written in HTML5. It would be nice if the platform allowed native binaries to be used, but it appears that all apps have to be in HTML. This by itself is a downer, as I don't know of any JIT interpreter for HTML, and the translating is relatively slow.
So, (and this is IMHO of course), for writing relative fluff like another Angry Birds port, Tizen will be fine. However, if I'm looking to do something more complex than that on the platform [1], that would be difficult, and with the HTML5 translating, would require a lot more CPU than the Dalvik JIT VM, or iOS's Objective-C binaries.
It would be nice if Tizen's RPM packages could offer both... so I can have a HTML5 frontend for the UI, but have Linux binaries [2] for the serious work.
[1]: On Android, I can pop up a command shell, fetch a confidential Word document via sftp, fire up an Office app to edit it, convert it to PDF, gpg sign and encrypt it, then E-mail it to a potential client, all on a device that has hard disk protection. On iOS this is doable (although with a jailbroken device, it is far easier). However on a device that just groks HTML5, doing this type of workflow would be impossible.
[2]: Assuming there are usable libraries on the system. I can always statically link, but that would mean the apps made would be porky.
Call me crazy, but instead of ethanol, why not get more vehicles that can run B100 diesel? If people want to talk about a fuel that doesn't take dino carbon and put it in the air, nothing beats WVO, WMO [1] or other waste oils.
Of course, a diesel car has to have a lot more subsystems than a gas engine (EGR, DEF, DPF, multiple pumps, glow plugs, and many other components that have to be maintained.) However, if one really wants to be "green", B100 is as good as it gets. To boot, it doesn't take crop space away.
IMHO, a diesel engine is the way to go. Chrysler has been developing a true multifuel engine that is a Diesel cycle (not an Otto cycle) engine... but it has the option to use gasoline, as well as diesel.
[1]: Waste motor oil is still dino juice, but better have it used as fuel than have to reside in tanks to be disposed of. On some diesel sites, people report success with submicron filtering, mixing it with regular diesel, and using that.
Ethanol is very nasty stuff when it comes to small engines like generators. Because most of these are use carburetors, they are very sensitive to varnish and bad gas. In the past, one could leave gasoline in a tank over the winter and be OK. With E10, using stored gas of that length can result in a carb rebuild, or in some cases (newer Onans), a possible replacement.
Yes, one can use Sta-Bil or other additives, but they are more of a band-aid solution than anything else.