Your statement "with hardware encryption there is less room for error" doesn't jive. Hardware can have bugs too. I would say the hardware errors are worse as they require device replacement. Hardware implementations cannot be trivially inspected.
If your data is extremely (i.e. NSA level) important, never trust device-side encryption unless indeed you did compile and upload the firmware yourself. I'm not sure about how modern SSDs allow custom firmwares to be uploaded but it'd be really cool if they did. Could roll your own if you are super paranoid - I can't remember who makes but I did see one time an "SSD development kit" - it was a larger-than-a-2.5-SSD board that had a SATA port on one side and a serial port on the other - this is where you would upload firmware. You also had to purchase and install your own NAND modules which resembled DIMMs from what I could tell. It was really cool.
For 95% for use cases it's likely better than nothing.
Software is not good at generating entropy but there is no reason why software should do that. There's many physical sources of good entropy, your soundcard for one.
Truecrypt at least I can look at and compile myself if I so wanted. That says a lot to me.
Well, the way many modern tape drives work in Linux is acting like a non-seekable device that can have a single file written to or read from.
So if you had a BIOS bootloader or tape option ROM that could read the tape into RAM and then transfer control of execution to the beginning of the image, which would unpack the kernel and initrd and start booting Linux, it's completely possible.
If you have coreboot on your system I think you could really do it.
I mean if the failing marketshare year on year since the iPhone came out didn't clue you in, maybe the KIN debacle would have, or certainly the fact that your marketshare is no better off despite practically owning a phone manufacturing company could point that out.
If it's a Linux machine consider using nfblock. You'll need to hook it into iptables using an NFQUEUE target. You'd also need to find the APNIC IP ranges and put them in a blocklist.
The VT console has been "hardware accelerated" under x86/VGA for years. You don't think it's actually copying memory line for line when it needs to scroll the screen, do you? No, it's incrementing the VGA register that tells it what memory address to start drawing text from.
Why, so you can further annoy the hapless Windows Phone user with lovely messages saying "The limited functionality you're trying to access on your crappy phone has been even more restricted by your domain administrator." or push out all those ARM-based software packages you have via GPO over 3G/4G? I guess integration with the Windows app store would be OK, well..."Sorry, you can't make phone calls because a GPO-mandated update over 3G is in progress. Please try later."
In a mobile environment it seems to me from my admittedly limited experience with Windows AD GPOs is that they aren't overly useful - GPOs and such seem to really shine in an "old-school everyone has desktops physically locked to their desks and is on a wired LAN" environment. In the current firm where I work it seems other than having a central place to keep authentication information the domain controller really doesn't help us out a lot.
Though a random number or other GUID-type identifier still needs to be attached to all names to account for two people with the same exact name and multiple instances of people with no name.
So take this name: (At least I hope it's a name) add random number: 94921 xn--eqr37k.94921@domain.tld
And null names handled: xn--.23213@domain.tld
This leverages currently existing software investment in Punycode and can easily be converted using online tools like I just did here.
And yes, true property has to be physical. "Imaginary property" is a terrible term that confuses things and encourages application of "age of scarcity"/pre-information age to things it shouldn't apply to, leading to inefficient artificial social and economic structures (ultimately doomed to failure anyway) to support them. It is wrong to treat things like music, art in the same method as commodities where quantity matters. Because the quantity of something does NOT matter if the cost of reproduction is zero. It simply doesn't, unless you buy the lie of intellectual property and think that everyone will always follow your notion of rights.
If something doesn't act like a car, it's wrong to call it a car.
(I'm not sure I entirely agree with this statement yet but I'm just putting it out there)
What happens is that media production stops becoming a viable industry and a vehicle of corporate cultural oppression tanks with it. The entire notion of manufactured popular culture and its method of control over people dissipates. Movies, music, stop becoming things for mass consumption, a relic notion of an industrial-revolution-scarcity mindset and become personal, meaningful again. People really want something in music or movie form, they make it, or pay someone to make it directly. Less people consider musicianship or movie production as valid careers. So music and movies don't disappear, but become things people want to do because they want to do, or commissioned.
I am surprised no one mentioned I2P earlier as it does things very similarly to how the writer describes.
Ultimately though, the solution is to stop giving people money who will turn around and use that money to enslave you, threaten you, or coerce you. A dollar not spent on the movie or music industry is a dollar spent for freedom.
If you can mount a cloud service as a folder in Linux somehow, then Tahoe-LAFS can work. I know Dropbox lets you do this but am unsure about the other systems. If the cloud service allows upload/download via HTTPS, this could be worked around nontrivially by writing something using FUSE to translate filesystem requests to HTTPS requests recognized by that service.
You would have to have a "client" running for each cloud service. Each client has a storage directory which needs to be configured to be the same as the local sync directory for the cloud service. While Tahoe-LAFS is intended to have each client in a "grid" run on separate machines, there's no reason why multiple clients on the same grid could not be running locally. You'd just have to edit configs manually, setting the IP address to 127.0.0.1 and choosing a different port for each "client", and also making sure the introducer.furl is set accordingly.
Tahoe-LAFS's capability system is pretty neat. Clients never see unencrypted data and you can configure the redundancy and "spread-outness" of the data however you like. Tahoe-LAFS's propensity to disallow quick "deleting" of shares also works well with possibly slowly updating cloud backends - Tahoe is designed to prefer to "age out" shares containing old files periodically rather than support direct deleting.
And Tahoe works as well on Windows as it does on Linux (it's a python script) so if your cloud service is Windows only that is no disadvantage.
Slashdot Mirror
Your statement "with hardware encryption there is less room for error" doesn't jive. Hardware can have bugs too. I would say the hardware errors are worse as they require device replacement. Hardware implementations cannot be trivially inspected.
If your data is extremely (i.e. NSA level) important, never trust device-side encryption unless indeed you did compile and upload the firmware yourself. I'm not sure about how modern SSDs allow custom firmwares to be uploaded but it'd be really cool if they did. Could roll your own if you are super paranoid - I can't remember who makes but I did see one time an "SSD development kit" - it was a larger-than-a-2.5-SSD board that had a SATA port on one side and a serial port on the other - this is where you would upload firmware. You also had to purchase and install your own NAND modules which resembled DIMMs from what I could tell. It was really cool.
For 95% for use cases it's likely better than nothing.
Software is not good at generating entropy but there is no reason why software should do that. There's many physical sources of good entropy, your soundcard for one.
Truecrypt at least I can look at and compile myself if I so wanted. That says a lot to me.
...especially with the included Hot Dog Stand theme? Who *doesn't* want that?
Look, I really want to run my old DOS 6.22 applications on my phone, OK? Also I think Windows 3.1 would make a fantastic mobile operating system.
http://mamajiwatulip.blogspot.com/2010/10/tulip-bling-bling-stickers.html
Put a couple of those on and you'll be "Pimp"(tm) in no time.
-1 Microsoft Shill detected.
I stand corrected.
Well, the way many modern tape drives work in Linux is acting like a non-seekable device that can have a single file written to or read from.
So if you had a BIOS bootloader or tape option ROM that could read the tape into RAM and then transfer control of execution to the beginning of the image, which would unpack the kernel and initrd and start booting Linux, it's completely possible.
If you have coreboot on your system I think you could really do it.
I mean if the failing marketshare year on year since the iPhone came out didn't clue you in, maybe the KIN debacle would have, or certainly the fact that your marketshare is no better off despite practically owning a phone manufacturing company could point that out.
If it's a Linux machine consider using nfblock. You'll need to hook it into iptables using an NFQUEUE target. You'd also need to find the APNIC IP ranges and put them in a blocklist.
http://compare.ebay.com/like/200851091953?var=lv<yp=AllFixedPriceItemTypes&var=sbar
Yes, gouging out your keyboard or RAM is acceptable to install this. All's fair in love and Linux.
What laptop doesn't have a Mini-PCIe slot?
Then, PCI/PCIe serial port adapter. No Linux box should be without one. The decision to take this off standard PC motherboards was stupid.
Laptop? They have PCMCIA to serial port adapters.
The VT console has been "hardware accelerated" under x86/VGA for years. You don't think it's actually copying memory line for line when it needs to scroll the screen, do you? No, it's incrementing the VGA register that tells it what memory address to start drawing text from.
then you aren't really using a "failsafe" console. Even Windows has this with it's "Special Administration Console" / "Emergency Management Services."
When I was building custom kernels for my server I would remove the VT support. Pure serial.
So I don't care. Sounds good from a design standpoint. Should have the least in the kernel possible - simple = robust.
um .... many phones have an hdmi port, or an mhl port ... completely possible.
Careful now, otherwise they may kick you out of their network: http://gizmodo.com/275374/sprint-dumps-needy-customers
Nothing a little ultraviolet can't fix.
Why, so you can further annoy the hapless Windows Phone user with lovely messages saying "The limited functionality you're trying to access on your crappy phone has been even more restricted by your domain administrator." or push out all those ARM-based software packages you have via GPO over 3G/4G? I guess integration with the Windows app store would be OK, well ..."Sorry, you can't make phone calls because a GPO-mandated update over 3G is in progress. Please try later."
In a mobile environment it seems to me from my admittedly limited experience with Windows AD GPOs is that they aren't overly useful - GPOs and such seem to really shine in an "old-school everyone has desktops physically locked to their desks and is on a wired LAN" environment. In the current firm where I work it seems other than having a central place to keep authentication information the domain controller really doesn't help us out a lot.
Though a random number or other GUID-type identifier still needs to be attached to all names to account for two people with the same exact name and multiple instances of people with no name.
So take this name: (At least I hope it's a name)
add random number: 94921
xn--eqr37k.94921@domain.tld
And null names handled:
xn--.23213@domain.tld
This leverages currently existing software investment in Punycode and can easily be converted using online tools like I just did here.
Punycode.
No. Wrong. It's infringing, not stealing.
And yes, true property has to be physical. "Imaginary property" is a terrible term that confuses things and encourages application of "age of scarcity"/pre-information age to things it shouldn't apply to, leading to inefficient artificial social and economic structures (ultimately doomed to failure anyway) to support them. It is wrong to treat things like music, art in the same method as commodities where quantity matters. Because the quantity of something does NOT matter if the cost of reproduction is zero. It simply doesn't, unless you buy the lie of intellectual property and think that everyone will always follow your notion of rights.
If something doesn't act like a car, it's wrong to call it a car.
(I'm not sure I entirely agree with this statement yet but I'm just putting it out there)
What happens is that media production stops becoming a viable industry and a vehicle of corporate cultural oppression tanks with it. The entire notion of manufactured popular culture and its method of control over people dissipates. Movies, music, stop becoming things for mass consumption, a relic notion of an industrial-revolution-scarcity mindset and become personal, meaningful again. People really want something in music or movie form, they make it, or pay someone to make it directly. Less people consider musicianship or movie production as valid careers. So music and movies don't disappear, but become things people want to do because they want to do, or commissioned.
I am surprised no one mentioned I2P earlier as it does things very similarly to how the writer describes.
Ultimately though, the solution is to stop giving people money who will turn around and use that money to enslave you, threaten you, or coerce you. A dollar not spent on the movie or music industry is a dollar spent for freedom.
Atari died when the Jaguar flopped and JTS quiety bought them in a "reverse merger."
I would venture to say though that after the crash of '83, and the NES started becoming cool two years later, was really when it started to fall.
If you can mount a cloud service as a folder in Linux somehow, then Tahoe-LAFS can work. I know Dropbox lets you do this but am unsure about the other systems. If the cloud service allows upload/download via HTTPS, this could be worked around nontrivially by writing something using FUSE to translate filesystem requests to HTTPS requests recognized by that service.
You would have to have a "client" running for each cloud service. Each client has a storage directory which needs to be configured to be the same as the local sync directory for the cloud service. While Tahoe-LAFS is intended to have each client in a "grid" run on separate machines, there's no reason why multiple clients on the same grid could not be running locally. You'd just have to edit configs manually, setting the IP address to 127.0.0.1 and choosing a different port for each "client", and also making sure the introducer.furl is set accordingly.
Tahoe-LAFS's capability system is pretty neat. Clients never see unencrypted data and you can configure the redundancy and "spread-outness" of the data however you like. Tahoe-LAFS's propensity to disallow quick "deleting" of shares also works well with possibly slowly updating cloud backends - Tahoe is designed to prefer to "age out" shares containing old files periodically rather than support direct deleting.
And Tahoe works as well on Windows as it does on Linux (it's a python script) so if your cloud service is Windows only that is no disadvantage.
I always have to tell them the "key above Enter."
Many people's IQ drop 50 points when faced with Windows authentication dialogs.