That's too bad, but I expected it - they announced it, asked for partners, and then it was crickets until they started on the Ubuntu for Phones path.
It's a damn shame, though, I bet it would ROCK on my Note 3, it's so crazily powered - 2.3 gHz quad-core CPU, 3 GB of RAM and 96 GB of storage. I would freaking LOVE to see Ubuntu run natively on this thing to a screen or a lapdock. Same for the new CyanogenMod phone, except it doesn't have MicroSD storage as an option.
Well, when you're running edge cache servers that service gazillions of SSL sites and need to store a private key for each on each of those distributed servers, you're pretty much going to be modifying quite a lot of stuff.
Consider SpiderOak Backup - they have a package repository for Ubuntu and the "Spideroak Hive" is, I believe, much like the Ubuntu One folder. I use it for backups but it looks to be nicely usable as a One replacement, especially if you're not sharing with other people a lot.
They recently sent me an email that they're offering unlimited storage for $125 a year as well, though I'm not sure how that works in practice.
And, of course, their big claim to fame is that they're zero-knowledge, so no NSA requests, etc etc.
I hate Microsoft with a flaming hot passion, but I'll say this: OneNote is a very cool and under-appreciated program.
One very cool feature I used to use a lot when I was consulting - I often had analysis engagements where I had to spend one or two marathon days interviewing lots of different staff members. OneNote has a feature that allowed me to record audio of the interviews (and only about 10 MB per hour) and would store pointers into the audio as I typed notes into OneNote. Then later, if I had a question about something, a quick double-click of the text in the notes would automatically start the audio playing a configurable number of seconds before I started typing.
It could even do the same thing with video and audio - I brought in my QuickCam Orbit with face tracking one time, and the camera would follow the speaker's face. Just a tad too disconcerting for the interviewee though, I didn't do that very much.
Sadly, this free version doesn't do the above - you still have to buy the full version for that. And somebody told me the free version is licensed such that companies can't use it anyway, so I won't be using this - I run Linux at home.
I read an article on this recently, it appears that Target contacted both those whose name/address/email had been compromised AND those who use their credit card there during the time period using the same email. They should have split the two.
So it's likely that your personal information was compromised, but not your credit card number. Be on the lookout for phishing attempts.
So, time for me to rant, but on-topic, for a second.
Everybody knows, I would hope, that best practice is to never allow an Internet-facing server to initiate outbound traffic. This is both because, should the server get compromised, it becomes a new attack vector - as in Code Red or SQL Slammer. This is also because, as in Target's case, it makes it fairly trivial to exfiltrate stolen data.
But services still persist that require that this very access be enabled. My current case in point: ReCAPTCHA. Google hosts the URL for this service, intended to provide additional security, on a www.google.com URL, which means that, at minimum, I have to allow outbound access from any server hosting a ReCAPTCHA on port 443 to everything Google owns. In practice, of course, it's all but impossible to keep track of Google's address space for firewall purposes, so this means that I have to allow that server out on port 443 to the entire Internet. It's either that, or set up a proxy solution that can do URL filtering and then require the CAPTCHA verification code to use that. Not exactly something your typical smaller company using ReCAPTCHA is apt to do.
I've talked to competing, for-pay, services, and they require the same thing, despite the fact that they're smaller and have only a few, well-defined networks, but they won't commit to keeping me up-to-date with network changes.
We really need to start pushing back on this crap. Servers accepting inbound traffic should never need to initiate outbound communications.
It would probably be a good idea to take installation media along with you, and make sure to hash it before you go, then keep the hash on your person. If my machine got grabbed for "inspection", I wouldn't trust the OS on it as far as I could throw it.
My thoughts exactly. Maybe Ender's Game is considered to be so by people under a certain age, but Starship Troopers is almost certainly THE quintessential classic military sci-fi book.
And I would also argue that The Forever War should be in the list somewhere above Card's book.
Heck, between the RPV's and the children, I'm almost hesitant to even call it a "military" book per se.
If the data is that confidential, you should probably look into an actual FIPS-certified network-connected HSM instead of rolling your own.
I did a project a few years back using nCipher NetHSMs (they've since been bought up, I believe) and they were quite cool technology. Even then, I think one of these devices was in the $25K range at most.
The great thing is, if you generate a key pair with one of these, you literally cannot get access to the private key to hand over to the government, even if you wanted to.
The CSR (Certificate Signing Request) contains only the public half of the key, to be signed by the CA's key which results in the CA attesting that the information is verified.
The entity whose key was signed always maintains control of the private key. Which, to me, is the reason that public-key encryption is not "over". The NSA would have to strong-arm every single holder of an SSL key, not just the Certificate Authorities.
Granted, though, those private keys are not often held terribly securely - they're most often just files on a server that aren't even password-protected, because that requires an admin to type in passwords whenever the Web server is restarted. They COULD be held in an HSM, a hardware security module much like a TPM on steroids, but that's very expensive and difficult to set up.
However, none of this means that public-key crypto is broken. It's possible that individual sites could be compromised via this route (Facebook, Google, etc) but as a whole, no.
The hardware isn't from Icom, it's from DVSI and available, at least on paper, to anybody that wants to pony up for a pre-programmed DSP from them. The existence of the DV Dongle from Internet Labs completely disproves your statement.
Now, as I've previously posted, I don't like that it's a proprietary codec that is only implemented in hardware, but that doesn't mean "you need to buy decryption keys [...] from Icom". Let's keep this conversation factual, shall we?
Sadly, the protocol didn't allow for identifying the codec used for the voice bits, so even if one wasn't concerned about interoperability with normal DSTAR radios, it's not possible as the DSTAR radios will try (and fail) to decode the voice data that's encoded using Codec2, but try to decode it in AMBE.
I think we need a newer protocol anyway that is much more supportive of mixed voice and data comms - the only way to send data with a DSTAR handheld is by keying up voice, wasting most of the bits, and sending slow-speed data along with the voice bits. It's really tragic if you ask me, such a waste.
Not possible to do in software because the only implementation is in a DSP chip that must be purchased from the vendor.
I have much less problem with the use of a proprietary codec (although I do wish Codec2 had been available at the time or a good allowance was made in the protocol for changing codecs) than I do with the fact that the only implementation possible is in hardware. It very much limits flexibility in open-hardware and computer-based implementations relating to the protocol. Such a waste.
People keep wishing that other manufactures would implement DSTAR hardware - I hope they don't, as I'd like to see it replaced with something much more open, or at least flexible. As well, support for data transmissions was implemented very badly and IMHO as implemented it's a waste of bandwidth, because it should have much better data transmission support.
Um, actually, Jared A. Bruegman, ex-KC0IQN, of Bolivar, Missouri, was given a $10,000 Notice of Apparent Liability (NAL, FCC-speak for "you've been a bad boy, pay up") just a couple of months ago.
No kidding. I consulted for a few days in Batesville, Indiana a few years back, and flew into (and out of) Cincinnatti, which was on DST while eastern Indiana was not. Luckily I left quite early for the trip back home, because I lost an hour on the drive! Easily could have missed my flight because of all this stupidity.
Count me in for completely getting rid of this madness. Crossing time zones I can keep track of, but not taking into account the fact that only half of one state doesn't feel like following the rules.
We just made changes to every system not so long ago when Bush decided to lengthen DST, and I don't recall the world ending. Now is a great time to do it while the experience is still fresh.
Or they did as of not very long ago at all - I had to recover my password on their site, and just about fell out of my chair when, instead of sending me a recovery link, they emailed me my current password.
Nowadays that password is a KeePass-generated random one.
With IPv6, the smallest subnet that will be assigned is a/64 - meaning 64 bits of host addresses are possible within that subnet. Originally it was envisioned that those 64 bits would be the MAC address of the host, but people had a wee bit of a problem with that privacy-wise, for just this reason - exposing the MAC address of a system on the public Internet.
So, many, if not most, hosts nowadays choose a random value for their host ID, do the IPv6 equivalent of a gratuitous ARP to make sure it's not in use already (highly unlikely), and if not they use it. Many also change their address periodically by doing this again.
Nice advantage here: unless a given network is using DHCPv6 and logging the requests, this is all done on-the-fly with no logging and no discovery possible.
Slashdot Mirror
has typed the words "moisture vaporators" prior to this?
Damn, has this place gone downhill.
That's too bad, but I expected it - they announced it, asked for partners, and then it was crickets until they started on the Ubuntu for Phones path.
It's a damn shame, though, I bet it would ROCK on my Note 3, it's so crazily powered - 2.3 gHz quad-core CPU, 3 GB of RAM and 96 GB of storage. I would freaking LOVE to see Ubuntu run natively on this thing to a screen or a lapdock. Same for the new CyanogenMod phone, except it doesn't have MicroSD storage as an option.
the downside of SDR. Just wait until BladeRF and HackRF and others really get spun up. No frequency will be safe.
In an actual "Sh*t Hits the Fan" emergency, technology like this isn't a bad thing to have on tap. The fun part is managing it day-to-day.
Well, when you're running edge cache servers that service gazillions of SSL sites and need to store a private key for each on each of those distributed servers, you're pretty much going to be modifying quite a lot of stuff.
Consider SpiderOak Backup - they have a package repository for Ubuntu and the "Spideroak Hive" is, I believe, much like the Ubuntu One folder. I use it for backups but it looks to be nicely usable as a One replacement, especially if you're not sharing with other people a lot.
They recently sent me an email that they're offering unlimited storage for $125 a year as well, though I'm not sure how that works in practice.
And, of course, their big claim to fame is that they're zero-knowledge, so no NSA requests, etc etc.
I got you beat - I know of a company that's still running OS/2 Warp on two production systems. They track the entire backup tape library.
I hate Microsoft with a flaming hot passion, but I'll say this: OneNote is a very cool and under-appreciated program.
One very cool feature I used to use a lot when I was consulting - I often had analysis engagements where I had to spend one or two marathon days interviewing lots of different staff members. OneNote has a feature that allowed me to record audio of the interviews (and only about 10 MB per hour) and would store pointers into the audio as I typed notes into OneNote. Then later, if I had a question about something, a quick double-click of the text in the notes would automatically start the audio playing a configurable number of seconds before I started typing.
It could even do the same thing with video and audio - I brought in my QuickCam Orbit with face tracking one time, and the camera would follow the speaker's face. Just a tad too disconcerting for the interviewee though, I didn't do that very much.
Sadly, this free version doesn't do the above - you still have to buy the full version for that. And somebody told me the free version is licensed such that companies can't use it anyway, so I won't be using this - I run Linux at home.
Is that you, Steve Gibson?
I read an article on this recently, it appears that Target contacted both those whose name/address/email had been compromised AND those who use their credit card there during the time period using the same email. They should have split the two.
So it's likely that your personal information was compromised, but not your credit card number. Be on the lookout for phishing attempts.
So, time for me to rant, but on-topic, for a second.
Everybody knows, I would hope, that best practice is to never allow an Internet-facing server to initiate outbound traffic. This is both because, should the server get compromised, it becomes a new attack vector - as in Code Red or SQL Slammer. This is also because, as in Target's case, it makes it fairly trivial to exfiltrate stolen data.
But services still persist that require that this very access be enabled. My current case in point: ReCAPTCHA. Google hosts the URL for this service, intended to provide additional security, on a www.google.com URL, which means that, at minimum, I have to allow outbound access from any server hosting a ReCAPTCHA on port 443 to everything Google owns. In practice, of course, it's all but impossible to keep track of Google's address space for firewall purposes, so this means that I have to allow that server out on port 443 to the entire Internet. It's either that, or set up a proxy solution that can do URL filtering and then require the CAPTCHA verification code to use that. Not exactly something your typical smaller company using ReCAPTCHA is apt to do.
I've talked to competing, for-pay, services, and they require the same thing, despite the fact that they're smaller and have only a few, well-defined networks, but they won't commit to keeping me up-to-date with network changes.
We really need to start pushing back on this crap. Servers accepting inbound traffic should never need to initiate outbound communications.
It would probably be a good idea to take installation media along with you, and make sure to hash it before you go, then keep the hash on your person. If my machine got grabbed for "inspection", I wouldn't trust the OS on it as far as I could throw it.
My thoughts exactly. Maybe Ender's Game is considered to be so by people under a certain age, but Starship Troopers is almost certainly THE quintessential classic military sci-fi book.
And I would also argue that The Forever War should be in the list somewhere above Card's book.
Heck, between the RPV's and the children, I'm almost hesitant to even call it a "military" book per se.
If the data is that confidential, you should probably look into an actual FIPS-certified network-connected HSM instead of rolling your own.
I did a project a few years back using nCipher NetHSMs (they've since been bought up, I believe) and they were quite cool technology. Even then, I think one of these devices was in the $25K range at most.
The great thing is, if you generate a key pair with one of these, you literally cannot get access to the private key to hand over to the government, even if you wanted to.
Actual answer: no.
The CSR (Certificate Signing Request) contains only the public half of the key, to be signed by the CA's key which results in the CA attesting that the information is verified.
The entity whose key was signed always maintains control of the private key. Which, to me, is the reason that public-key encryption is not "over". The NSA would have to strong-arm every single holder of an SSL key, not just the Certificate Authorities.
Granted, though, those private keys are not often held terribly securely - they're most often just files on a server that aren't even password-protected, because that requires an admin to type in passwords whenever the Web server is restarted. They COULD be held in an HSM, a hardware security module much like a TPM on steroids, but that's very expensive and difficult to set up.
However, none of this means that public-key crypto is broken. It's possible that individual sites could be compromised via this route (Facebook, Google, etc) but as a whole, no.
The hardware isn't from Icom, it's from DVSI and available, at least on paper, to anybody that wants to pony up for a pre-programmed DSP from them. The existence of the DV Dongle from Internet Labs completely disproves your statement.
Now, as I've previously posted, I don't like that it's a proprietary codec that is only implemented in hardware, but that doesn't mean "you need to buy decryption keys [...] from Icom". Let's keep this conversation factual, shall we?
Sadly, the protocol didn't allow for identifying the codec used for the voice bits, so even if one wasn't concerned about interoperability with normal DSTAR radios, it's not possible as the DSTAR radios will try (and fail) to decode the voice data that's encoded using Codec2, but try to decode it in AMBE.
I think we need a newer protocol anyway that is much more supportive of mixed voice and data comms - the only way to send data with a DSTAR handheld is by keying up voice, wasting most of the bits, and sending slow-speed data along with the voice bits. It's really tragic if you ask me, such a waste.
Not possible to do in software because the only implementation is in a DSP chip that must be purchased from the vendor.
I have much less problem with the use of a proprietary codec (although I do wish Codec2 had been available at the time or a good allowance was made in the protocol for changing codecs) than I do with the fact that the only implementation possible is in hardware. It very much limits flexibility in open-hardware and computer-based implementations relating to the protocol. Such a waste.
People keep wishing that other manufactures would implement DSTAR hardware - I hope they don't, as I'd like to see it replaced with something much more open, or at least flexible. As well, support for data transmissions was implemented very badly and IMHO as implemented it's a waste of bandwidth, because it should have much better data transmission support.
Um, actually, Jared A. Bruegman, ex-KC0IQN, of Bolivar, Missouri, was given a $10,000 Notice of Apparent Liability (NAL, FCC-speak for "you've been a bad boy, pay up") just a couple of months ago.
Info here.
No kidding. I consulted for a few days in Batesville, Indiana a few years back, and flew into (and out of) Cincinnatti, which was on DST while eastern Indiana was not. Luckily I left quite early for the trip back home, because I lost an hour on the drive! Easily could have missed my flight because of all this stupidity.
Count me in for completely getting rid of this madness. Crossing time zones I can keep track of, but not taking into account the fact that only half of one state doesn't feel like following the rules.
We just made changes to every system not so long ago when Bush decided to lengthen DST, and I don't recall the world ending. Now is a great time to do it while the experience is still fresh.
Or they did as of not very long ago at all - I had to recover my password on their site, and just about fell out of my chair when, instead of sending me a recovery link, they emailed me my current password.
Nowadays that password is a KeePass-generated random one.
Not a lot of change that I can see.
With IPv6, the smallest subnet that will be assigned is a /64 - meaning 64 bits of host addresses are possible within that subnet. Originally it was envisioned that those 64 bits would be the MAC address of the host, but people had a wee bit of a problem with that privacy-wise, for just this reason - exposing the MAC address of a system on the public Internet.
So, many, if not most, hosts nowadays choose a random value for their host ID, do the IPv6 equivalent of a gratuitous ARP to make sure it's not in use already (highly unlikely), and if not they use it. Many also change their address periodically by doing this again.
Nice advantage here: unless a given network is using DHCPv6 and logging the requests, this is all done on-the-fly with no logging and no discovery possible.
Wanna bet? VOIP + SWATting = win.
Dude, bad example.
If you were in that union, you would have noticed that 92% of your fellow workers voted against the company's offer.