The clue was where I said Surface Pro 2/3. It sits somewhere between the 2 and 3 in terms of spec. It has a similar form factor as the 3, a choice of i3/i5 processor, similar storage and RAM options and a resolution of the Surface 2. It's a lot cheaper and comes with proper chiclet keyboard which also adds some extra ports and speakers.
I haven't had such problems with the Miix. My biggest gripe is the touch pad doesn't have software for me to set up gestures (e.g. vertical scroll), and the keyboard stand is perfectly fine for desks but it isn't much good for perching in bed - it's too easy for the tablet to topple forward.
RT was a stillborn concept from the beginning. Windows without Windows compatibility is a stupid idea. It was even worse for having a desktop mode and all that bloat as a kludge to support a half baked port of MS Office.
Perhaps it might have enjoyed more success if they had added x86 emulation and LLVM-esque runtime support to Visual Studio and C++ so a large portion of desktop apps could be recompiled for it.
It's similarly specced to a Surface Pro 2/3 but considerably cheaper and includes a keyboard. I think by far the biggest issue with the Surface Pro is the keyboard is a pricey extra for an already pricey tablet.
If they bundled the keyboard with these things they'd sell a hell of a lot more of them. They're not bad devices, just too expensive. And let's be blunt, Windows without a keyboard is worse than fucking useless.
Not necessarily. The FBI could have supplied Google & Microsoft with a long list of md5 / sha1 hashcodes for abuse images which they obtained in raids or forums and these providers have programmed their system to raise a flag whenever they get a hit. Then a human might go in to confirm the match and from there its just a matter of informing the police. It may well be there are other ways of "fingerprinting" an image that are more resilient than a hash code and still useful enough for matching pictures against a known set of bad ones.
Perhaps it will come out in the trial how the file was identified.
Anyway it's more proof (if any were needed) why it's an incredibly bad idea to use a cloud service to store anything illegal. At least encrypt the data. Better yet don't put it up there at all.
I'm sorry but parents DO have a right to complain. Apple / Google / Microsoft are facilitators of a system which not only encourages but profits from games charging money for in-app purchases. It means that the controls are begrudging implemented and usually flipped to off position by default. And it is not hard to find games aimed at young kids where the game encourages the player to purchase $50-100 bundles of coins, skins or whatever. They don't want to tip the applecart so to speak.
And yeah parental responsibility does come into it but so does the power of the default. The default for kid rated games should be purchase restrictions. If the account holder wants to flip it the other way they can do so, but that should be the default. And in being the default it would change the landscape of these games for the better since they'd have to focus on engaging game play instead of skinner box random rewards for cash as they do now.
Impose a maximum in-game purchase to the game's rating and impose a maximum spend per account per month. i.e. an E for everyone game may have a max spend of $5. If a user wants to override these settings then they can from the account settings. The power of the default mean the majority won't and thus people will be protected from nasty surprises. Oh and ban more than 1 in game currency that maps onto real world money and require them to show a dollar / euro / pound value against any purchase that uses it.
Aside from protecting users it deters games from being glorified skinner boxes with cow-clicker complexity and micropayments galore and encourages producers to start making actual games again.
The Wii U is the filling in a shit sandwich. On one side it has the PS3 & 360 which are technically comparable yet cheaper and have a massive catalogue of games and industry support. On the other side they have the PS4 and XB1 which are technically superior, rapidly picking up steam and have industry support. They're in the middle with no industry support and few if any reasons to justify themselves to consumers over other choices.
The problem is fundamentally one of Nintendo's own making. They cynically set out to make the lowest spec console they could get away (basically parity with the PS3/360) and charged a premium for a gimmick. Consumers didn't buy it (probably remembering the Wii, remote, balance board + assorted shit gathering dust in the cupboard) and without the sales the 3rd parties slipped away.
A single title like MarioKart is a shot in the arm but it can't turn the ship around by itself. Nintendo will have to hope they can keep throwing out good titles for long enough that sales pick up and some 3rd parties come back. Personally I think they should be looking to emerging markets and price their console at those markets.
Shame so many of them chose death over sharing, isn't it? Even if they still die, their platform could live on indefinitely. Think of what would have happened if it weren't for the x86 clones.
Because open & open source consoles have such a long and glorious history. And I include forcibly opened consoles in that list, those which have been cracked.
Opening the console up either voluntarily or involuntarily would be the final nail in the coffin for their platform.
The main problem with The Hobbit is (as Bilbo might say) it feels thin, like butter scraped over too much toast. There's too little story to work with to justify 3 3-hour movies.
Maybe Peter Jackson will release a limited abbreviated edition on Blu Ray to make up for this. Anyway the middle instalment was pretty good (thanks to Smaug) though both it and the first movie are guilty of some utterly pointless detours and WTF moments particularly any time Radaghast appeared on screen.
In practice Android has several reputable stores - Google & Amazon Appstore and there is a second tier of stores which some standard of validation / vetting Samsung Apps, GetJar, F-droid, Appslib, SlideME etc.
At the end of the day, android gives users the freedom to choose where they get apps from. But freedom implies the freedom to do stupid things. It won't stop a user installing warez if they want, but if they get owned it's their own damned fault. Not much different from what happens on a PC or Mac really.
That said I don't think Android does enough to protect users from malicious or rogue apps, e.g. allowing the device to deny a permission to the app even if it claims to need it. Cyanogenmod demonstrates it can be added, but Google haven't seen fit to provide that functionality in the stock android code.
I bet virtually all malware on Android originates not from the official store but from idiots downloading and install apks from the wild or some dodgy Chinese app store - "this cracked Candy Crush says it needs access to make calls, send & receive SMS messages, access to my contacts, my Google accounts and email but I really want to play so I'm going to click through this obvious red flag and wonder later why my phone is calling premium numbers in Ouagadougou at 3am and why I have 10 missed calls from Visa loss prevention".
I'm pretty certain Google has systems in place (as well as an after the fact kill function) to eradicate malicious apps that find their way onto the app store. Doubtless there are some there but they're background noise.
Cell carriers don't have to distribute it. Google could use their Play service and patch devices regardless of what the carrier did. They could even scan devices for active use of the exploit.
Hollow out Nokia until its just a shell valuable only for its IP, transfer everything else worth keeping into Microsoft proper and discard the rest. Wouldn't be surprised if the "Nokia" brand gets sold onto to some Asian / Indian outfit in a few years hence.
If it's unreachable code then it is indicative of a bug - someone has written code which they *think* does something but doesn't do anything. Now perhaps the programmer deliberately commented something out or surrounded with an "if (false)" block but even so at the very least the compiler should generate a warning and in some cases an error.
False security. If you're paranoid that Dropbox sends your password back then you shouldn't be using it at all. Period. It wouldn't be hard for them to infer that the frequently changing, fixed size random file they were stashing was a truecrypt volume and for them to enumerate the mount points to see what was in it.
Please read what I wrote. Dropbox could offer to encrypt a protected folder. By default that could be passphrase based encryption. The encryption could be pluggable to allow other forms of encryption. The passphrase based encryption source / algorithm could be submitted for review.
"This could be as simple as providing a settings screen where the user enters a passphrase and once enabled all files within a protected folder are encrypted before they leave the client."
You are utterly failing to read my post. I didn't say server side encryption.
Read my original message. I was never pushing for server side encryption. As far as I'm concerned server side encryption is pretty worthless. It might stop an employee stealing data without authorization but it doesn't stop the government, or any 3rd party armed with a subpoena coming in and taking your stuff. But DropBox has fat clients. They can implement encryption on the client side before it ever reaches the server. They could also make the encryption pluggable so somebody with a hard token, or a fingerprint scanner, or some weird ass corporate policy could plug their own solution in. It doesn't mitigate all attacks naturally but it does protect users from DropBox being compromised, or being served with some narrow or broad demand to access certain data.
1) Then you put a big warning on the feature making it clear that the user must remember their passphrase. You could also make it only work on a folder explicitly called Protected to hammer this home.
2) Most encryption schemes compress before encrypting. So nothing is lost there. As for de-duplication, I don't see that being a huge concern because a) even if encryption is an option most people won't use it and b) When TFA has dropbox's head honcho saying "We think of encryption beyond that as a users choice."
3) That argument doesn't really fly at all. Security is not an all or nothing thing. Different security serves different purposes and can mitigate different attacks. e.g. encrypting data client side means that if Dropbox's servers were compromised or their users database was stolen that my data is still secure.
Basic Dropbox is, none of the other options are. And besides, why is that an excuse? If they can encrypt data as they send it, and as they store it on the cloud, why is it impossible to encrypt it on the client, or provide an API to allow a 3rd party to encrypt it?
Furthermore, as it is the paid service that pays their wages, why aren't they implementing a feature that customers, particularly corporates would pay for and which would enhance their reputation for secure storage?
If you want encryption, then fine, do it yourself. You obviously know that your stuff won't be indexable or shareable so won't be calling for support or slagging Dropbox off online when you find indexing and sharing not working.
Well that's a stupid argument right there. I wonder if car companies apply it too - well if you want an airbag in your car why don't you install it yourself? Just because a single individual has the technical wherewithal to implement something doesn't excuse the company for not implementing it in the first place, particularly when it is a feature that many people want.
There's room to suggest Dropbox should offer a pay-for encrypted service. The thing is, no matter how well they do it, it'll always be vulnerable to government interference, and it'll never be fully trusted anyway. BYO means no government interference and trust *for the relatively small number of people who care* without raising the costs too much for the multitudes who don't.
No it won't. The point of a well designed client side encryption is Dropbox simply have no idea what they are storing on their servers. Government can interfere until the cows come home but Dropbox have no idea what is in those files.
Hi Dropbox, stop blaming users. You are in the strongest position possible to offer encryption in Dropbox because it's your software. You know the triggers that cause files to be exchanged. You know the optimal way to minimize network traffic. If you can send and receive files, then why can't you also encrypt / decrypt files in this step? This could be as simple as providing a settings screen where the user enters a passphrase and once enabled all files within a protected folder are encrypted before they leave the client. This encryption could also scramble file names and break up large files into parts to obfuscate their size.
Yes you'd have to warn the user that a protected folder means exactly that and there are restrictions on what you can do with it, e.g. access in some dropbox clients, web browsers, sharing to others. People will get it.
Even better, this encryption / decryption could be thrown open as a pluggable API so 3rd parties could write their own encryption protocols to whatever personal or corporate standard they desired. For transparency the aforementioned passphrase encryption could even be supplied for review.
Same goes for Skydrive, Google Drive etc. There is no excuse for not offering encryption. Not that I'm in the tinfoil hat camp to think this is to facilitate monitoring (although it does). More likely it's because these cloud storage servers use file hashing to spare themselves the bother of storing 1,000,000 copies of the same file. It still sucks though and even if the option is off by default, encryption of at least one folder should be provided.
Slashdot Mirror
We cured your husband's cancer but we accidentally vegetablised him by blocking a few veins in his brain with liquid metal.
The clue was where I said Surface Pro 2/3. It sits somewhere between the 2 and 3 in terms of spec. It has a similar form factor as the 3, a choice of i3/i5 processor, similar storage and RAM options and a resolution of the Surface 2. It's a lot cheaper and comes with proper chiclet keyboard which also adds some extra ports and speakers.
I haven't had such problems with the Miix. My biggest gripe is the touch pad doesn't have software for me to set up gestures (e.g. vertical scroll), and the keyboard stand is perfectly fine for desks but it isn't much good for perching in bed - it's too easy for the tablet to topple forward.
Perhaps it might have enjoyed more success if they had added x86 emulation and LLVM-esque runtime support to Visual Studio and C++ so a large portion of desktop apps could be recompiled for it.
If they bundled the keyboard with these things they'd sell a hell of a lot more of them. They're not bad devices, just too expensive. And let's be blunt, Windows without a keyboard is worse than fucking useless.
Thanks for the link. Yes exactly that sort of thing.
Perhaps it will come out in the trial how the file was identified.
Anyway it's more proof (if any were needed) why it's an incredibly bad idea to use a cloud service to store anything illegal. At least encrypt the data. Better yet don't put it up there at all.
And yeah parental responsibility does come into it but so does the power of the default. The default for kid rated games should be purchase restrictions. If the account holder wants to flip it the other way they can do so, but that should be the default. And in being the default it would change the landscape of these games for the better since they'd have to focus on engaging game play instead of skinner box random rewards for cash as they do now.
Thanks Ayn for completely understanding the problem.
Aside from protecting users it deters games from being glorified skinner boxes with cow-clicker complexity and micropayments galore and encourages producers to start making actual games again.
The problem is fundamentally one of Nintendo's own making. They cynically set out to make the lowest spec console they could get away (basically parity with the PS3/360) and charged a premium for a gimmick. Consumers didn't buy it (probably remembering the Wii, remote, balance board + assorted shit gathering dust in the cupboard) and without the sales the 3rd parties slipped away.
A single title like MarioKart is a shot in the arm but it can't turn the ship around by itself. Nintendo will have to hope they can keep throwing out good titles for long enough that sales pick up and some 3rd parties come back. Personally I think they should be looking to emerging markets and price their console at those markets.
Shame so many of them chose death over sharing, isn't it? Even if they still die, their platform could live on indefinitely. Think of what would have happened if it weren't for the x86 clones.
Because open & open source consoles have such a long and glorious history. And I include forcibly opened consoles in that list, those which have been cracked.
Opening the console up either voluntarily or involuntarily would be the final nail in the coffin for their platform.
Maybe Peter Jackson will release a limited abbreviated edition on Blu Ray to make up for this. Anyway the middle instalment was pretty good (thanks to Smaug) though both it and the first movie are guilty of some utterly pointless detours and WTF moments particularly any time Radaghast appeared on screen.
At the end of the day, android gives users the freedom to choose where they get apps from. But freedom implies the freedom to do stupid things. It won't stop a user installing warez if they want, but if they get owned it's their own damned fault. Not much different from what happens on a PC or Mac really.
That said I don't think Android does enough to protect users from malicious or rogue apps, e.g. allowing the device to deny a permission to the app even if it claims to need it. Cyanogenmod demonstrates it can be added, but Google haven't seen fit to provide that functionality in the stock android code.
I'm pretty certain Google has systems in place (as well as an after the fact kill function) to eradicate malicious apps that find their way onto the app store. Doubtless there are some there but they're background noise.
Cell carriers don't have to distribute it. Google could use their Play service and patch devices regardless of what the carrier did. They could even scan devices for active use of the exploit.
Hollow out Nokia until its just a shell valuable only for its IP, transfer everything else worth keeping into Microsoft proper and discard the rest. Wouldn't be surprised if the "Nokia" brand gets sold onto to some Asian / Indian outfit in a few years hence.
If it's unreachable code then it is indicative of a bug - someone has written code which they *think* does something but doesn't do anything. Now perhaps the programmer deliberately commented something out or surrounded with an "if (false)" block but even so at the very least the compiler should generate a warning and in some cases an error.
False security. If you're paranoid that Dropbox sends your password back then you shouldn't be using it at all. Period. It wouldn't be hard for them to infer that the frequently changing, fixed size random file they were stashing was a truecrypt volume and for them to enumerate the mount points to see what was in it.
Please read what I wrote. Dropbox could offer to encrypt a protected folder. By default that could be passphrase based encryption. The encryption could be pluggable to allow other forms of encryption. The passphrase based encryption source / algorithm could be submitted for review.
"This could be as simple as providing a settings screen where the user enters a passphrase and once enabled all files within a protected folder are encrypted before they leave the client." You are utterly failing to read my post. I didn't say server side encryption.
Read my original message. I was never pushing for server side encryption. As far as I'm concerned server side encryption is pretty worthless. It might stop an employee stealing data without authorization but it doesn't stop the government, or any 3rd party armed with a subpoena coming in and taking your stuff. But DropBox has fat clients. They can implement encryption on the client side before it ever reaches the server. They could also make the encryption pluggable so somebody with a hard token, or a fingerprint scanner, or some weird ass corporate policy could plug their own solution in. It doesn't mitigate all attacks naturally but it does protect users from DropBox being compromised, or being served with some narrow or broad demand to access certain data.
2) Most encryption schemes compress before encrypting. So nothing is lost there. As for de-duplication, I don't see that being a huge concern because a) even if encryption is an option most people won't use it and b) When TFA has dropbox's head honcho saying "We think of encryption beyond that as a users choice."
3) That argument doesn't really fly at all. Security is not an all or nothing thing. Different security serves different purposes and can mitigate different attacks. e.g. encrypting data client side means that if Dropbox's servers were compromised or their users database was stolen that my data is still secure.
You realise dropbox is free, right?
Basic Dropbox is, none of the other options are. And besides, why is that an excuse? If they can encrypt data as they send it, and as they store it on the cloud, why is it impossible to encrypt it on the client, or provide an API to allow a 3rd party to encrypt it? Furthermore, as it is the paid service that pays their wages, why aren't they implementing a feature that customers, particularly corporates would pay for and which would enhance their reputation for secure storage?
If you want encryption, then fine, do it yourself. You obviously know that your stuff won't be indexable or shareable so won't be calling for support or slagging Dropbox off online when you find indexing and sharing not working.
Well that's a stupid argument right there. I wonder if car companies apply it too - well if you want an airbag in your car why don't you install it yourself? Just because a single individual has the technical wherewithal to implement something doesn't excuse the company for not implementing it in the first place, particularly when it is a feature that many people want.
There's room to suggest Dropbox should offer a pay-for encrypted service. The thing is, no matter how well they do it, it'll always be vulnerable to government interference, and it'll never be fully trusted anyway. BYO means no government interference and trust *for the relatively small number of people who care* without raising the costs too much for the multitudes who don't.
No it won't. The point of a well designed client side encryption is Dropbox simply have no idea what they are storing on their servers. Government can interfere until the cows come home but Dropbox have no idea what is in those files.
Yes you'd have to warn the user that a protected folder means exactly that and there are restrictions on what you can do with it, e.g. access in some dropbox clients, web browsers, sharing to others. People will get it.
Even better, this encryption / decryption could be thrown open as a pluggable API so 3rd parties could write their own encryption protocols to whatever personal or corporate standard they desired. For transparency the aforementioned passphrase encryption could even be supplied for review.
Same goes for Skydrive, Google Drive etc. There is no excuse for not offering encryption. Not that I'm in the tinfoil hat camp to think this is to facilitate monitoring (although it does). More likely it's because these cloud storage servers use file hashing to spare themselves the bother of storing 1,000,000 copies of the same file. It still sucks though and even if the option is off by default, encryption of at least one folder should be provided.