Forgot your password?

Comment: Re:Oe noes! A compiler bug! (Score 1) 695

by DrXym (#47548213) Attached to: Linus Torvalds: "GCC 4.9.0 Seems To Be Terminally Broken"
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.

Comment: Re:We should add our own encryption??? (Score 1) 175

by DrXym (#47531135) Attached to: Dropbox Head Responds To Snowden Claims About Privacy
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.

Comment: Re:We should add our own encryption??? (Score 1) 175

by DrXym (#47531079) Attached to: Dropbox Head Responds To Snowden Claims About Privacy
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.

Comment: Re:We should add our own encryption??? (Score 1) 175

by DrXym (#47529367) Attached to: Dropbox Head Responds To Snowden Claims About Privacy
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.

Comment: Re:We should add our own encryption??? (Score 1) 175

by DrXym (#47523119) Attached to: Dropbox Head Responds To Snowden Claims About Privacy
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.

Comment: Re:We should add our own encryption??? (Score 2) 175

by DrXym (#47523015) Attached to: Dropbox Head Responds To Snowden Claims About Privacy

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.

Comment: We should add our own encryption??? (Score 2, Insightful) 175

by DrXym (#47521091) Attached to: Dropbox Head Responds To Snowden Claims About Privacy
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.

Comment: Re:Why ODF? (Score 1) 164

by DrXym (#47514125) Attached to: UK Cabinet Office Adopts ODF As Exclusive Standard For Sharable Documents
Saying a file contains Korean is a meaningless statement say unless the doc unambiguously tells you the encoding. Otherwise you're just guessing. If the XML file says it is encoded as US-ASCII but contains shift bits or extended chars then your XML parser would be fully within its rights to throw your non-compliant file out on its ass. If you're lucky it would allow the chars through but it would still be up to your app to heuristically figure out what they meant. So no you can't just shove some Korean in there without dropping a clue of some kind (which isn't the font either).

That is of course why software tends to use Unicode is used these days. A file can unambiguously include the chars it uses and the codepages they come from. How they are stored is where an encoding comes in. UTF-8 tends to be a popular encoding of Unicode because legacy tools tend to cope with it better and the files can be a bit smaller than UTF-16 depending on the contents (amount of markup vs text).

Comment: Re:Why ODF? (Score 1) 164

by DrXym (#47514049) Attached to: UK Cabinet Office Adopts ODF As Exclusive Standard For Sharable Documents
ODT contains printable characters. Unzip an .odt file - all the content is XML. Of course there may also be pictures and diagrams in there too but that's why its a zip file in the first place. But perhaps you mean human only characters. Well throw the content through pandoc or any other converter.

Comment: Re:Why ODF? (Score 1) 164

by DrXym (#47514019) Attached to: UK Cabinet Office Adopts ODF As Exclusive Standard For Sharable Documents

Why do we have to use something so complicated and unreadable without certain software? Something like markdown or even LaTeX if you have smart users would be better.

A bit condescending there. "Smart users" might prefer their time to be spent more productively with a WYSIWYG word processor than learning some stupid markup language just because the file format is potentially a bit simpler.

Besides, I'm sure someone could produce an ODT to Markdown / Latex tool if they wished. Both sides are fairly well documented and open standards after all.

Comment: Re:this is great news! (Score 1) 94

by DrXym (#47513743) Attached to: Open-Source Blu-Ray Library Now Supports BD-J Java
Tinfoil hat off please. The "unknown code" is on a Blu Ray is a brain dead jar file running atop of a J2ME profile VM. It has a very limited view of the world that allows it to stream video, trickplay, display graphics, receive limited input, talk with the internet, and access to limited storage.

If you are paranoid about it you could unplug the internet cable. After all, if you're worried about what your Blu Ray disc is capable of then you should also be worried about what ALL the software on the device is capable of. e.g. the Netflix app, BBC iPlayer, PS3 games or whatever else is on there.

Comment: What an utter waste of money (Score 1) 285

by DrXym (#47506013) Attached to: How One School District Handled Rolling Out 20,000 iPads
I'm sure school kids do love their ridiculously expensive luxury tablets. A more fiscally responsible school system would have used cheaper tablets, or even required parents to buy them from a shortlist of devices which supported some minimum spec (e.g. ability to run 6 hours on a charge, read epub format books, capacitive screen, 8" or larger etc.)

Comment: Re:It was pretty cool in its day (Score 2) 192

by DrXym (#47499703) Attached to: The Almost Forgotten Story of the Amiga 2000
Most demos and games would use vsync as their timer so theoretically they would cycle at 25/30hz regardless of CPU. Probably the biggest compatibility issue were demos and games that made bad assumptions about the memory architecture (e.g. the amount of fast/slow memory), or the addressable space (e.g. using the top 8 bits of registers for something else), or use self modifying code or some other trick which would consequently fail hard on a later CPU.

The bigger failing IMO was that all the software hitting the custom hardware made it increasingly difficult for the platform to support higher resolutions, pixel bit depths and stuff like virtual memory. It was left to 3rd parties to provide a solution but by that point it was already too late.

If at first you don't succeed, you must be a programmer.