That is a concern, but AES encryption is not for yet another descendant of CPRM... it is because a lot of companies and government organizations require DAR (data at rest) encryption. Having this done at the HDD controller level is the best for performance reasons, and with the latest version of BitLocker, drives are recoverable (recovery info is stored in an AD schema), but still secure if someone decides to "borrow" a few drives out of a drawer.
True, that is a downside. The searches and deduplication would have to happen "behind" the encryption appliance, and the appliance might need to index stored data as an added feature (where said index is kept encrypted, of course, perhaps stashed locally.)
This means that one has to use CPU power locally instead of using something on the cloud provider side to locate data (the analog would be mounting a remotely hosted TC volume and doing a find from a workstation as opposed to just logging into the remote computer and doing a find from the shell there.) To mitigate that, one would use GNU locate and have the local side index data in the TC container, keeping that index stashed either in the container, or on the workstation.
Very true. However, there is a very large difference between passively sifting through petabytes of data looking for stuff versus actively going door to door to demand access.
Also, once the SWAT team comes by to seize the appliance, whomever the organization is that owns that will be on alert. It is a lot easier to send lawyers after active antics than it is to deal with passive monitoring (which as the courts have it, it is a normal part of Internet functioning now.)
To use PRZ's old analogy, most everyone has been sending their messages to others via postcards. Maybe it is time to start using envelopes?
First question that comes to mind. What voltage are these batteries at? 1000 amp-hours at 12 volts is a lot different than 1000 amp-hours at 120.
Gasoline gets 12,000 watt-hours as a reference.
As for these batteries, I am hoping for use in larger applications than just a skinner smartphone.
One amp-hour per gram is pretty good, assuming this is a twelve volt battery. Compare that to a deep cycle lead-acid battery that weighs about 18 kilograms and gives 150 AH or so. For the same amount of energy as that flooded wet cell, I'd just need a battery that weighed less than an ounce.
However, the big issue is energy stored per volume. Weight is one thing, but if we can get energy stored per volume even within an order of magnitude of gasoline, the game changes completely:
We can get rid of internal combustion engines completely for electric motors which do not have major energy losses due to exhaust and heat. Electric motors also have peak torque at 0 RPM.
Areas where fuel is wasted due to idling will be eliminated. A stopped electric vehicle only needs juice to keep the occupants comfortable and the computer systems going. The drivetrain needs no power unlike a gas or diesel engine which has to keep at a certain RPM level (unless stopped and started.)
Solar would become a lot more useful because there would be the ability to store that energy for use at night.
I am realistic with my threat levels. For me, the USG isn't on my list. I am more concerned about some party hacking the cloud provider I use and offering stashed directories as a large torrent file, than I am about some US government agency seeing my renassiance faire pictures.
With this in mind, I do encrypt what I store offsite with cloud disk services for archival reasons. For what I store, using an archiving program with a reliable AES implementation like WinRAR or 7Zip and a long (32+ character) passphrase is good enough. As an added bonus, some archiving utilities also have the option of adding ECC records, so if the file gets partially corrupted during the upload or download, this is likely repairable.
Realistically, what might end up happening is that some startup gets off the ground whose sole function in life is to provide an in-house encryption appliance similar to a HSM. Data goes in to the module, encrypted data gets stored in the cloud. All keys are kept in a "physically secure" 1U rack module with a USB port in front so one can back up the keys stored in the device.
Businesses will buy those encryption appliances, and IT goes on as normal.
There are good reasons to separate functions. Mainly security. That way, if someone hacks the NTP server, they don't get control of DNS, nor do they get control of the corporate NNTP server, or other functions.
The ideal would be to run those functions as VMs on a host filesystem that uses deduplication. That way, the overhead of multiple operating systems is minimized.
What would be nice would be an ARM server platform, combined with ZFS for storing the VM disk images, and a well thought out (and hardened) hypervisor. The result would be a server that can take one rack unit, but can handle all the small stuff (DNS caching, NTP, etc.)
I can see a large number of cores being useful... but with a hypervisor and a VM layer. This way, a phone can have multiple "worlds" (to use the ARM term) where work stuff is completely separate from home stuff, and there is the ability to have each client be on a separate VM. Of course, there would need to be deduplication for apps (so the MS word viewer only takes up one instance, not for each VM) and encryption for the app data, but this isn't something that is impossible.
What would be nice is to see cores that do different tasks, and a scheduler smart enough to use them. For example, one type core is mainly a GPU, another a FPU, another a slow (but energy saving) integer cruncher, another a relatively fast CPU, another a DSP, and another a FPGA. This would provide a device with immense flexibility. For optimizing calculations (such as AES which require array shifts), the FPGA can be configured and used. When the touchscreen is being used, the tasks that monitor that can be shifted from a slow core to a faster one until a few seconds elapse after the finger is removed. If the hypervisor is crunching a lot of context shifts, it can move itself to a faster core to handle the load, then back down to a slower core.
Of course, the car example is simple -- check the task at hand and find the right engine to suit. A low-wattage generator gets a one cylinder, two stroke engine. A 20,000 pound freight shipment gets a turbo diesel. A motorcycle gets a small gasoline engine.
This also would be useful if coupled with tiered storage like a mini SAN controller. SLC flash gets used for data that is more often accessed than stuff on slower MLC cells.
I would also say, not just get it in writing, but get it in writing with the "property release" form that some companies require.
This way, the abovementioned bean counter wouldn't be able to say that whomever gave it in writing didn't have authorization and raise a case of employee theft (which can get felony level quickly from the numbers on the books.)
Reason this is important is that I saw this secondhand when a company had a bunch of CRT monitors sitting around. To free up cube space, a cow-orker offered to donate them to give the company a tax break. This got cleared from his supervisor and up the chain, with paperwork. The gratitude later on? Said employee was shown the door and threatened with grand theft charges because said piece of paper wasn't "official" from the finance department.
I was unclear either. I was thinking it included some Chinese crypto algorithms that were previously secret similar to how Clipper/SKIPJACK were in the 1990s.
If the TPM chip contains additional crypto algorithms, big whoop. They wouldn't be useful for Western stuff, but for Chinese stuff, would be important (since they want their own AES for example.)
That is the only real thing I can think of which the EU would be concerned about.
TPMs do provide some good security for what they are worth. Not perfect, but it helps immensely with laptops, because if done right, a thief has to be able to get in via the OS, as well as have the proper PIN [1], and perhaps even a USB flash drive with a keyfile on it in order to boot.
[1]: Too many wrong guesses, the TPM won't accept any PIN requests for x amount of time, the value doubling each wrong time.
I'm too lazy to bother. From what I read, TPM 2.0 will work similar to 1.2. Which means on desktop computers, it ships off, unknowned, and disabled. No need to worry/care about it.
I'm glad you pointed the code out. Having Android be able to tackle users in an elegant fashion (while making sure user A's instance of an app doesn't bang into user B's instance) is a very good thing to have.
That beats having to have a hypervisor and deduplication on the backend any day.
Splitting hairs here, Linux is the kernel, and if one really wants to be technical about it, Android can be considered a really modified Linux distribution.
The issue with Android making the jump to the desktop hinges around one issue: User support. Android uses UIDs to separate apps. How would it keep users separate, which is a must on a desktop box.
The only way I can see that happening would be a hypervisor based system with each user on their own VM, and the core filesystem everything sits on having deduplication built in (so each user's environment only saves what the user's changes are.) Then, have a system where users have one mounted filesystem for sharing between everything.
It can be done, but it would take a lot of work for it to be decently elegant. However, it done right, it would be decently secure unless an app is able to get out of the hypervisor.
Other than the fact that Android is a single-user OS, it would not be too bad on the desktop. The permission model is solid enough that a compromised Web browser wouldn't mean the whole user or machine is nailed.
Part of it is a lot of geeks cut their teeth in the industry by dealing with level 0 or level 1 phone support.
There, you get the people who oftentimes have no clue what they are doing, but yet have an attitude. This is a perfect ground for breeding the "I'm smarter than you" aura. After a certain amount of calls of "I just pulled the DIMMs out of this box and put them into this other... now why isn't my RAM drive working?", one has to deal with it some way.
Data centers likely won't be going anywhere anytime soon. Businesses [1] tend to like keeping their critical stuff in a secured spot.
What I see happening in a data center are a few changes:
1: Data center rack widths will increase. This allows more stuff to be packed in per rack unit.
2: There will be a standard for liquid cooling where CPUs, RAM, GPUs, and other components that normally use heat sinks will use water jackets. Instead of a HVAC system, just the chilled water supply and a heat exchanger would do the trick. Of course, the issue is someone making valves and fittings that are leak resistant, are quick connects (disconnect hose, it shuts off the water flow), and can handle a number of connection and disconnection cycles before giving up and leaking. There would be leak sensors to shut off automatically any damaged cooling part and the machines attached to it similar to how a CPU shuts down if its heat sink gets bumped off.
3: A move to DC power because it means that every rack unit just needs to step up and down the incoming voltage. No power supply needed. Of course, there are dangers with DC power (muscle lock), but telcos already use 48VDC. Of course, switching DC power is a PITA due to no zero crossings, thus having to deal with arcs and pitted contacts. However, there are always rack-level PDUs which can take the 208 VAC power and turn it into 12-48 VDC, with low amounts of voltage loss due to the relative short distances.
4: A move to a passive backplane type of architecture. This way, specialized CPU boards can be added as needed, as well as "external RAM" [2]. It will allow the latest/greatest network and disk protocols to be changed out as need be.
5: More high end SAN features like real time block level deduplication making it into the onboard motherboard RAID chips.
6: Hypervisors built into all motherboards where a utility like Xen or vSphere will be more of an admin shell.
7: More security appliances, which are specialized in tasks. For example, an appliance that just stores username and password hashes so when a Web server authenticates a user, it uses that. Too many wrong guesses of a user's password would result in blocks/delays on the appliance level (something even a compromised Web server could not get around.) This would be used to ensure that an intruder couldn't make off with the/etc/shadow equivilent.
8: A resurgance of tape. Disk media was cheap and improved exponentially for a while. Now, tape is starting to catch up, and offers a lot more surface area, so ariel densities are not as critical compared to reliability and storage. No matter how one slices it, tape is not going anywhere soon because nothing beats it for reliability and price. D2D2T will still remain the norm provided there is no new media revolution (like a new optical format.)
9: More technologies for deduplication. IBM has tape deduplication as well as an appliance which sits between machines and the SAN fabric and deduplicates data on the fly.
10: A push for more technologies that can be remotely run via a Web page or a SSH connection. This allows for unmanned data centers to not just be possible, but easily done.
[1]: Those businesses that didn't trade their heroes for ghosts and move to the cloud, that is. However, cloud providers use data centers.
[2]: This may be DRAM, or it may be some other mass media technology. We have been hearing about holographic storage for decades now. It would be a tier of storage with a speed level between disk and normal RAM that would be used as swap or cache.
There is always the option for a PXE boot server. That way, one can boot and install a machine directly from the network, no need to tote media around.
What would be a nice thing would be something that would be a combination of the two:
You boot a USB flash drive [1] which can get on the Internet and download signed updates to the OS. It then makes a temporary directory and slipstreams the updated packages in (perhaps keeping that directory on the USB media for faster subsequent reinstalls.)
Result -- one has an up to date install of the OS, but without having to transfer the bulk of it through an Internet connection, a lot of them being metered and expensive for bandwidth.
[1]: Ideally a USB flash drive which could take the updated partitions and slipstreamed directory, copy them to a directory, then mark it read-only so malware cannot tamper with the drive in the future.
The core E-mail protocol itself is supposed to be a brain-dead simple protocol that almost any machine can understand, thus the "S" in SMTP.
It is the additions which are used by the MTAs to allow who can and cannot connect and relay, as well as MUAs to figure out what to do with incoming messages.
Realistically, the ideal for verifying authentication would be an OpenPGP plugin and a far-reaching WoT that each user maintains. However, because certs and having domains sign outgoing mail is "good enough", that has become the standard these days.
If it gets medium-sized bands to stop by an area, that would be great... bands that are not beholden to the big labels, nor TM.
I wonder about going with a different system, but similar to Kickstarter:
1: An amount would be set for tickets. 2: Discount tickets (for each tier and seating) would be sold. 3: If the project makes it past the needed amount, people get charged. Otherwise, nobody gets charged.
The result is that people want to buy their tickets, they can. Otherwise, they pay full price if the concert is funded. No free tickets, no money being taken and refunded, it is either all or nothing.
Sometimes, I wonder if someone will be able to make a decent DC-net implementation, or if that doesn't work, perhaps use age-old remailer technologies to hide who is messaging whom, with both end to end encryption, as well as hub to hub encryption.
This would work better for non real-time messaging such as E-mail, file sending, or a SMS analogue. Of course, video and other real-time stuff this would be made difficult just due to the fact that latency forces connections to be as direct as possible.
Traffic analysis is a threat, but compared to others out there, it isn't as a big priority as just getting stuff encrypted end to end. What is really needed is for people to start using a WoT in the first place and to start making their own chains of whom to trust (and whom not to), rather than just assume that any CA shipped with the program (be it a browser, MUA, or OS) is good enough. CAs have their place, as a means of getting Bob's key to Alice, but what is really needed is for one of Bob's trusted friends/introducers to hand him Alice's key.
I know a couple uses for it. One of them, is essentially a remote terminal, assuming it has Citrix or other receiver support.
For typing stuff and general business/IT stuff (remote logins), it is a lot easier to do that with a keyboard than on a tablet, especially when dealing with a number of screen or text sessions.
Also, if the Chromebook gets stolen/seized, it is "just" a hardware loss except for saved browser preferences. An attacker might be able to tell what sites were visited with Chrome, but there would be little to no sensitive data physically on that device.
No, it isn't a game machine, but if I needed something to take out with me on a vacation trip where I had to log from remote, it would be immensely useful.
What might be interesting is to have Apple not activate numbers which are marked as stolen. Since all iPhones have to bounce off of their servers for the activation ticket process regardless of country, Apple could easily have the device flagged, perhaps with a mechanism where iOS would only boot to a screen saying to return the device to a lost/found/stolen clearinghouse. Combine this with a device kill command, and a stolen iPhone would only have value as spare parts (which is still a good amount of cash, especially screens, the back case, and batteries.)
I've seen some beaters in Austin which were worth less than $20. A lot of commuters, especially near the UT area, ride those because of the ease of bike theft. In fact, the bike locks [1] can cost more than the ride itself.
[1]: You don't want to use a cable lock unless it is the motorcycle style with the interlocking steel rings (rings that can't be bent to allow bolt cutters to cut past). So, a decent lock will set you back at least $50.
Slashdot Mirror
That is a concern, but AES encryption is not for yet another descendant of CPRM... it is because a lot of companies and government organizations require DAR (data at rest) encryption. Having this done at the HDD controller level is the best for performance reasons, and with the latest version of BitLocker, drives are recoverable (recovery info is stored in an AD schema), but still secure if someone decides to "borrow" a few drives out of a drawer.
True, that is a downside. The searches and deduplication would have to happen "behind" the encryption appliance, and the appliance might need to index stored data as an added feature (where said index is kept encrypted, of course, perhaps stashed locally.)
This means that one has to use CPU power locally instead of using something on the cloud provider side to locate data (the analog would be mounting a remotely hosted TC volume and doing a find from a workstation as opposed to just logging into the remote computer and doing a find from the shell there.) To mitigate that, one would use GNU locate and have the local side index data in the TC container, keeping that index stashed either in the container, or on the workstation.
Very true. However, there is a very large difference between passively sifting through petabytes of data looking for stuff versus actively going door to door to demand access.
Also, once the SWAT team comes by to seize the appliance, whomever the organization is that owns that will be on alert. It is a lot easier to send lawyers after active antics than it is to deal with passive monitoring (which as the courts have it, it is a normal part of Internet functioning now.)
To use PRZ's old analogy, most everyone has been sending their messages to others via postcards. Maybe it is time to start using envelopes?
First question that comes to mind. What voltage are these batteries at? 1000 amp-hours at 12 volts is a lot different than 1000 amp-hours at 120.
Gasoline gets 12,000 watt-hours as a reference.
As for these batteries, I am hoping for use in larger applications than just a skinner smartphone.
One amp-hour per gram is pretty good, assuming this is a twelve volt battery. Compare that to a deep cycle lead-acid battery that weighs about 18 kilograms and gives 150 AH or so. For the same amount of energy as that flooded wet cell, I'd just need a battery that weighed less than an ounce.
However, the big issue is energy stored per volume. Weight is one thing, but if we can get energy stored per volume even within an order of magnitude of gasoline, the game changes completely:
We can get rid of internal combustion engines completely for electric motors which do not have major energy losses due to exhaust and heat. Electric motors also have peak torque at 0 RPM.
Areas where fuel is wasted due to idling will be eliminated. A stopped electric vehicle only needs juice to keep the occupants comfortable and the computer systems going. The drivetrain needs no power unlike a gas or diesel engine which has to keep at a certain RPM level (unless stopped and started.)
Solar would become a lot more useful because there would be the ability to store that energy for use at night.
I am realistic with my threat levels. For me, the USG isn't on my list. I am more concerned about some party hacking the cloud provider I use and offering stashed directories as a large torrent file, than I am about some US government agency seeing my renassiance faire pictures.
With this in mind, I do encrypt what I store offsite with cloud disk services for archival reasons. For what I store, using an archiving program with a reliable AES implementation like WinRAR or 7Zip and a long (32+ character) passphrase is good enough. As an added bonus, some archiving utilities also have the option of adding ECC records, so if the file gets partially corrupted during the upload or download, this is likely repairable.
Realistically, what might end up happening is that some startup gets off the ground whose sole function in life is to provide an in-house encryption appliance similar to a HSM. Data goes in to the module, encrypted data gets stored in the cloud. All keys are kept in a "physically secure" 1U rack module with a USB port in front so one can back up the keys stored in the device.
Businesses will buy those encryption appliances, and IT goes on as normal.
There are good reasons to separate functions. Mainly security. That way, if someone hacks the NTP server, they don't get control of DNS, nor do they get control of the corporate NNTP server, or other functions.
The ideal would be to run those functions as VMs on a host filesystem that uses deduplication. That way, the overhead of multiple operating systems is minimized.
What would be nice would be an ARM server platform, combined with ZFS for storing the VM disk images, and a well thought out (and hardened) hypervisor. The result would be a server that can take one rack unit, but can handle all the small stuff (DNS caching, NTP, etc.)
I can see a large number of cores being useful... but with a hypervisor and a VM layer. This way, a phone can have multiple "worlds" (to use the ARM term) where work stuff is completely separate from home stuff, and there is the ability to have each client be on a separate VM. Of course, there would need to be deduplication for apps (so the MS word viewer only takes up one instance, not for each VM) and encryption for the app data, but this isn't something that is impossible.
What would be nice is to see cores that do different tasks, and a scheduler smart enough to use them. For example, one type core is mainly a GPU, another a FPU, another a slow (but energy saving) integer cruncher, another a relatively fast CPU, another a DSP, and another a FPGA. This would provide a device with immense flexibility. For optimizing calculations (such as AES which require array shifts), the FPGA can be configured and used. When the touchscreen is being used, the tasks that monitor that can be shifted from a slow core to a faster one until a few seconds elapse after the finger is removed. If the hypervisor is crunching a lot of context shifts, it can move itself to a faster core to handle the load, then back down to a slower core.
Of course, the car example is simple -- check the task at hand and find the right engine to suit. A low-wattage generator gets a one cylinder, two stroke engine. A 20,000 pound freight shipment gets a turbo diesel. A motorcycle gets a small gasoline engine.
This also would be useful if coupled with tiered storage like a mini SAN controller. SLC flash gets used for data that is more often accessed than stuff on slower MLC cells.
I would also say, not just get it in writing, but get it in writing with the "property release" form that some companies require.
This way, the abovementioned bean counter wouldn't be able to say that whomever gave it in writing didn't have authorization and raise a case of employee theft (which can get felony level quickly from the numbers on the books.)
Reason this is important is that I saw this secondhand when a company had a bunch of CRT monitors sitting around. To free up cube space, a cow-orker offered to donate them to give the company a tax break. This got cleared from his supervisor and up the chain, with paperwork. The gratitude later on? Said employee was shown the door and threatened with grand theft charges because said piece of paper wasn't "official" from the finance department.
I was unclear either. I was thinking it included some Chinese crypto algorithms that were previously secret similar to how Clipper/SKIPJACK were in the 1990s.
If the TPM chip contains additional crypto algorithms, big whoop. They wouldn't be useful for Western stuff, but for Chinese stuff, would be important (since they want their own AES for example.)
That is the only real thing I can think of which the EU would be concerned about.
Correction, unowned and disabled.
TPMs do provide some good security for what they are worth. Not perfect, but it helps immensely with laptops, because if done right, a thief has to be able to get in via the OS, as well as have the proper PIN [1], and perhaps even a USB flash drive with a keyfile on it in order to boot.
[1]: Too many wrong guesses, the TPM won't accept any PIN requests for x amount of time, the value doubling each wrong time.
I'm too lazy to bother. From what I read, TPM 2.0 will work similar to 1.2. Which means on desktop computers, it ships off, unknowned, and disabled. No need to worry/care about it.
I'm glad you pointed the code out. Having Android be able to tackle users in an elegant fashion (while making sure user A's instance of an app doesn't bang into user B's instance) is a very good thing to have.
That beats having to have a hypervisor and deduplication on the backend any day.
Splitting hairs here, Linux is the kernel, and if one really wants to be technical about it, Android can be considered a really modified Linux distribution.
The issue with Android making the jump to the desktop hinges around one issue: User support. Android uses UIDs to separate apps. How would it keep users separate, which is a must on a desktop box.
The only way I can see that happening would be a hypervisor based system with each user on their own VM, and the core filesystem everything sits on having deduplication built in (so each user's environment only saves what the user's changes are.) Then, have a system where users have one mounted filesystem for sharing between everything.
It can be done, but it would take a lot of work for it to be decently elegant. However, it done right, it would be decently secure unless an app is able to get out of the hypervisor.
Other than the fact that Android is a single-user OS, it would not be too bad on the desktop. The permission model is solid enough that a compromised Web browser wouldn't mean the whole user or machine is nailed.
Part of it is a lot of geeks cut their teeth in the industry by dealing with level 0 or level 1 phone support.
There, you get the people who oftentimes have no clue what they are doing, but yet have an attitude. This is a perfect ground for breeding the "I'm smarter than you" aura. After a certain amount of calls of "I just pulled the DIMMs out of this box and put them into this other... now why isn't my RAM drive working?", one has to deal with it some way.
Data centers likely won't be going anywhere anytime soon. Businesses [1] tend to like keeping their critical stuff in a secured spot.
What I see happening in a data center are a few changes:
1: Data center rack widths will increase. This allows more stuff to be packed in per rack unit.
2: There will be a standard for liquid cooling where CPUs, RAM, GPUs, and other components that normally use heat sinks will use water jackets. Instead of a HVAC system, just the chilled water supply and a heat exchanger would do the trick. Of course, the issue is someone making valves and fittings that are leak resistant, are quick connects (disconnect hose, it shuts off the water flow), and can handle a number of connection and disconnection cycles before giving up and leaking. There would be leak sensors to shut off automatically any damaged cooling part and the machines attached to it similar to how a CPU shuts down if its heat sink gets bumped off.
3: A move to DC power because it means that every rack unit just needs to step up and down the incoming voltage. No power supply needed. Of course, there are dangers with DC power (muscle lock), but telcos already use 48VDC. Of course, switching DC power is a PITA due to no zero crossings, thus having to deal with arcs and pitted contacts. However, there are always rack-level PDUs which can take the 208 VAC power and turn it into 12-48 VDC, with low amounts of voltage loss due to the relative short distances.
4: A move to a passive backplane type of architecture. This way, specialized CPU boards can be added as needed, as well as "external RAM" [2]. It will allow the latest/greatest network and disk protocols to be changed out as need be.
5: More high end SAN features like real time block level deduplication making it into the onboard motherboard RAID chips.
6: Hypervisors built into all motherboards where a utility like Xen or vSphere will be more of an admin shell.
7: More security appliances, which are specialized in tasks. For example, an appliance that just stores username and password hashes so when a Web server authenticates a user, it uses that. Too many wrong guesses of a user's password would result in blocks/delays on the appliance level (something even a compromised Web server could not get around.) This would be used to ensure that an intruder couldn't make off with the /etc/shadow equivilent.
8: A resurgance of tape. Disk media was cheap and improved exponentially for a while. Now, tape is starting to catch up, and offers a lot more surface area, so ariel densities are not as critical compared to reliability and storage. No matter how one slices it, tape is not going anywhere soon because nothing beats it for reliability and price. D2D2T will still remain the norm provided there is no new media revolution (like a new optical format.)
9: More technologies for deduplication. IBM has tape deduplication as well as an appliance which sits between machines and the SAN fabric and deduplicates data on the fly.
10: A push for more technologies that can be remotely run via a Web page or a SSH connection. This allows for unmanned data centers to not just be possible, but easily done.
[1]: Those businesses that didn't trade their heroes for ghosts and move to the cloud, that is. However, cloud providers use data centers.
[2]: This may be DRAM, or it may be some other mass media technology. We have been hearing about holographic storage for decades now. It would be a tier of storage with a speed level between disk and normal RAM that would be used as swap or cache.
There is always the option for a PXE boot server. That way, one can boot and install a machine directly from the network, no need to tote media around.
What would be a nice thing would be something that would be a combination of the two:
You boot a USB flash drive [1] which can get on the Internet and download signed updates to the OS. It then makes a temporary directory and slipstreams the updated packages in (perhaps keeping that directory on the USB media for faster subsequent reinstalls.)
Result -- one has an up to date install of the OS, but without having to transfer the bulk of it through an Internet connection, a lot of them being metered and expensive for bandwidth.
[1]: Ideally a USB flash drive which could take the updated partitions and slipstreamed directory, copy them to a directory, then mark it read-only so malware cannot tamper with the drive in the future.
The core E-mail protocol itself is supposed to be a brain-dead simple protocol that almost any machine can understand, thus the "S" in SMTP.
It is the additions which are used by the MTAs to allow who can and cannot connect and relay, as well as MUAs to figure out what to do with incoming messages.
Realistically, the ideal for verifying authentication would be an OpenPGP plugin and a far-reaching WoT that each user maintains. However, because certs and having domains sign outgoing mail is "good enough", that has become the standard these days.
If it gets medium-sized bands to stop by an area, that would be great... bands that are not beholden to the big labels, nor TM.
I wonder about going with a different system, but similar to Kickstarter:
1: An amount would be set for tickets.
2: Discount tickets (for each tier and seating) would be sold.
3: If the project makes it past the needed amount, people get charged. Otherwise, nobody gets charged.
The result is that people want to buy their tickets, they can. Otherwise, they pay full price if the concert is funded. No free tickets, no money being taken and refunded, it is either all or nothing.
USENET?
Sometimes, I wonder if someone will be able to make a decent DC-net implementation, or if that doesn't work, perhaps use age-old remailer technologies to hide who is messaging whom, with both end to end encryption, as well as hub to hub encryption.
This would work better for non real-time messaging such as E-mail, file sending, or a SMS analogue. Of course, video and other real-time stuff this would be made difficult just due to the fact that latency forces connections to be as direct as possible.
Traffic analysis is a threat, but compared to others out there, it isn't as a big priority as just getting stuff encrypted end to end. What is really needed is for people to start using a WoT in the first place and to start making their own chains of whom to trust (and whom not to), rather than just assume that any CA shipped with the program (be it a browser, MUA, or OS) is good enough. CAs have their place, as a means of getting Bob's key to Alice, but what is really needed is for one of Bob's trusted friends/introducers to hand him Alice's key.
I know a couple uses for it. One of them, is essentially a remote terminal, assuming it has Citrix or other receiver support.
For typing stuff and general business/IT stuff (remote logins), it is a lot easier to do that with a keyboard than on a tablet, especially when dealing with a number of screen or text sessions.
Also, if the Chromebook gets stolen/seized, it is "just" a hardware loss except for saved browser preferences. An attacker might be able to tell what sites were visited with Chrome, but there would be little to no sensitive data physically on that device.
No, it isn't a game machine, but if I needed something to take out with me on a vacation trip where I had to log from remote, it would be immensely useful.
What might be interesting is to have Apple not activate numbers which are marked as stolen. Since all iPhones have to bounce off of their servers for the activation ticket process regardless of country, Apple could easily have the device flagged, perhaps with a mechanism where iOS would only boot to a screen saying to return the device to a lost/found/stolen clearinghouse. Combine this with a device kill command, and a stolen iPhone would only have value as spare parts (which is still a good amount of cash, especially screens, the back case, and batteries.)
I've seen some beaters in Austin which were worth less than $20. A lot of commuters, especially near the UT area, ride those because of the ease of bike theft. In fact, the bike locks [1] can cost more than the ride itself.
[1]: You don't want to use a cable lock unless it is the motorcycle style with the interlocking steel rings (rings that can't be bent to allow bolt cutters to cut past). So, a decent lock will set you back at least $50.