Yeah, lets compare a 40 year old monopoly company (making money w large contracts) to a bunch of small upstart developers (making money $0.99 at a time) and laugh.
Let's not. Let's compare the mobile app market to one company. The mobile app market has a number of small upstart developers making $0.99 at a time, but it also includes companies like IBM, Microsoft, Apple, Adobe, and a large number of software houses that are 20-40 years old, several of which have been on the receiving end of antitrust lawsuits.
This is, unfortunately, the case with a number of funding bodies in academia. For example, DARPA won't pay for my membership, but will pay for the conference. My institution decided to pay for membership out of a different pot of money that doesn't have these restrictions, which ends up with a saving of a few hundred dollars on one account and a cost of a hundred dollars on another.
Ah, you're in the USA? Here, most people have pre-pay plans (being locked into a contract is generally seen as negative, unless it comes with some really good deals) and so get the phone that they bought along with their SIM and then hang onto it until it breaks or someone gives them a new one. I don't think I know anyone who pays close to $40/month on a phone bill (a fifth to a tenth of that is common and it's hard for a contract that comes with a new phone to be that cheap). At that price, I'd probably do without a mobile.
Amazon's app store is a bit better, because they're good at correlating things you've bought with things you might want to buy, so have recommendations that don't totally suck. The only reason I actually have it installed though is their free app of the day (which isn't necessarily a good thing - there are a couple of games that it's given me that have wasted a lot of my time...)
$13b is a big-sounding number. But it's not that big in comparison to some other numbers. For example, there were 75b downloads from the Apple App Store last month, so even if that $13b were just for the last month, not for the lifetime of the App Store, it would amount to less than 20 for each download. There are 1.2m apps available, so $13b means just over $10K per app. That's quite a lot for a week's work, but it's a pittance compared to the cost of developing a typical program, especially when you consider the earnings per year.
Oh, and for reference, Microsoft's revenue for the last quarter was about $20b. Which makes $13b spread between 1.2m apps seem very, very small. (I'm assuming that your $13b number is just for developers selling through the Apple App Store. If it also includes Android then it's an even more laughable number).
Finally, I never see ACM articles linked from Google. You'd imagine searches for things like "reduction of inter block artifacts in discrete wavelet transforms" should nail 5 ACM articles on the first page. Instead, I see mailing lists.
They'll show up if you use Google Scholar. If you're using the main search engine to find papers, then you're probably doing it wrong...
There is as an academic. Apparently being a member of the ACM has a negative value, because in exchange for the $99/year membership fee I typically get a $100-150 discount on attending ACM conferences. If you go to a couple of conferences a year then that's a good deal. For people outside academia, there's less relevance. ACM Queue, which provides material for 'practitioners' section of Communications of the ACM, generally has some good material, but it's all free whether your an ACM member or not.
I like the ACM as an organisation, but they're hard pressed to justify the cost of membership.
Wikipedia has a nice table of the relevant data. Per capita statistics are a bit misleading as they don't count for different levels of car ownership. Per vehicle statistics are a bit better. The UK has 6.2 fatalities per 100,000 motor vehicles (per year), whereas the USA has 13.6. Generalising this to 'Europe in general' doesn't really work though: Greece, for example, has 13.8 and Portugal has 18.
Even that doesn't tell the whole story though, because people in the UK laugh hysterically when we hear how long people in the USA think a reasonable daily commute is and so cars in the USA are likely to be driven further, which might account for the difference. Taking that into account and using the numbers for fatalities per billion km driven, the UK has 4.3 and the USA 7.6 , so under twice as many. As the grandparent said: not too far behind.
Getting the majority of people to vote for someone who actually held and was willing to act on opinions that they agree with, rather than the one who spouts platitudes and pretends to agree on a couple of specific issues. Good luck with that.
I can only assume that you rarely talk to non-geeks. I upgrade my phone roughly every 3 years and most of my non-geek friends have significantly older phones than me. Many of them get new phones only when a geeky relative upgrades and hands down their old device, so the least technical users end up with the least secure devices...
Because you can make more money if you invest more capital. If you have a project that has a 10% annual ROI and have $1m in the bank, then you can double your money if you use that as collateral and borrow $10m to invest. This is a big part of the reason why money tends to concentrate in the hands of people who already have money.
The reason that most extensions exist is that there is (or was) no way of implementing things that people want with standard C. Inline assembly is one example. All modern C compilers support it, but GCC and Microsoft's compilers use different syntax (most other compilers implement one or the other, sometimes both). Without it, you require that every time you want to use even a single instruction of platform-specific assembly code, you must write an entire function and call it.
Atomics were another big reason for extensions. Prior to C11, if you wanted atomic operations, you needed either assembly or non-standard compiler intrinsics. Efficient vector support is another one.
While that's technically true, the Ada and Fortran front ends are both using DragonEgg, which is a GCC plugin that converts GIMPLE to LLVM IR. It doesn't work well with GCC 4.7 or newer, produces poor debug info, and is now largely unmaintained. There is a Flang project to produce an LLVM front end for Fortran, but it's very immature. The Ada Labs guys were looking at producing an LLVM front end for Ada, but I don't know that they got anywhere with it.
Clang wasn't. Clang began in 2007, after Chris Lattner had moved to Apple. Before then, if you wanted to compile C code with LLVM, you had to use llvm-gcc, which was a horrible hack that took a forked version of GCC and translated one of the GCC IRs into LLVM IR before code generation.
The problem is worse on Android than on many other platforms because there are very few native shared libraries exposed to developer and there is no sensible mechanism for updating them all. If there's a vulnerability in a library that a load of developers use, then you need 100% of those developers to update the library and ship new versions of their apps to be secure. For most other systems, core libraries are part of a system update and so can be fixed centrally.
I doubt Apple has such a patent. Both of these were features of Symbian at least since EKA2 (over 10 years ago) and, I think, earlier. Apple may have a patent on some particular way of exposing this functionality to the UI, but that's about the most that they could have without it being shot down in court in 10 seconds (prior art that's in the form of a phone OS that millions of people owned is hard to refute).
Everything you ask for exists. The reason that Google, Microsoft, and Dropbox don't use them is that their entire business model depends on differentiation. If you could connect to their services with any third-party client that also worked with a server that you set up yourself and with their competitors' services, then their hold on the market becomes very tenuous. You're searching for technical solutions to business problems.
The 'you can skip in 5 seconds' ads amaze me. Presumably the people using them know that they have 5 valuable seconds that everyone can see, yet they uniformly squander them. I've almost never seen an ad that tells me anything interesting in the first 5 seconds, which isn't that surprising, but it's really surprising to me that most don't even tell me what the product is. Several that I've seen use the first 4 seconds to fade from black, then get 1 second of something incomprehensible before I hit skip.
Please correct me if I'm wrong because I may not have imagined this system properly. I was thinking the idea was that you encrypt each file with a single unique key, and then to use a public-key encryption scheme to encrypt that key. You can then send the encrypted file and the encrypted key to another user, knowing that it will need that users private key to decrypt.
Every time you upload a file, you generate a random symmetric key. You encrypt the file with this key and the key with your public key. If you want to download the file, you get the file and the encrypted key and then you decrypt the key with your private key and then decrypt the file. When you create the account, you upload your public key.
When you want to share a file with everyone, with no access control, you download the encrypted key, decrypt it, and provide it to the server. The server can then decrypt the file.
When you want to share a file with a limited set of users, you download each of their public keys (which you can cache in the client) and the encrypted symmetric key, decrypt the key, and then encrypt it once for each user. They will then only be able to access it with their client.
I'm not sure who you're 'we' as in 'internet community' is. We do have standards and off-the-shelf libraries for everything required to implement this and others have done so in the past (one of my colleagues during her PhD did back around 2006, to give one example, others have implemented more complex and flexible schemes more recently). Note that this is the simple textbook scheme for doing this kind of system. It's been implemented before and doubtless will be again. If you check the research literature then you'll find more interesting schemes.
The only problem is if you want to be able to access it from the browser, without some kind of plugin (Google actually does compile OpenSSL with Emscripten to do ASN.1 parsing, but I wouldn't recommend using it for encryption).
then you may as well just give the server the AES key and ask it to decrypt the file
But in that model, if "the server" has the key, wouldn't Dropbox have the key? I thought that was the whole thing people were freaking out about.
No, you'd have the key. If you wanted to share the file publicly, then there's no point in keeping it encrypted, so you'd provide the server with the key and it would decrypt, saving you the cost of downloading and reencrypting.
I understand what you (and the AC) are saying about storing an encrypted key on the server, and then re-encrypting the key for each new user you'd want to share with. That's a clever arrangement and I admit that I hadn't thought of it, but it still seems like it has the potential to create more complexity than most people want to deal with. It still means you need to manage various encryption keys, and we (Internet culture) seem intent on not developing a coherent system for managing encryption keys.
The client just needs one key, the RSA (or equivalent) public key. You'd need to copy this between devices, but it's relatively small (under 1KB). It's small enough to fit in a version 40 QR code quite easily, so you could set up mobile devices by displaying the QR code on your laptop screen and point the mobile device's camera at it, if you don't have any sensible way of transferring files between devices. The client then has to download the file and the associated key, decrypt the key with the locally-stored key, and then decrypt the file, but that's not something that's exposed to the user.
The anonymous poster pointed out a simpler mechanism, which is used in practice on file stores that want to be encrypted on the server. This technique also has a number of advantages. Using a symmetric cypher is generally faster than an asymmetric one and using a different key for each file is just good practice anyway as it limits the damage that certain kinds of trojan can do. If you're sharing with everyone, then you may as well just give the server the AES key and ask it to decrypt the file. If you're sharing with just a few people, then sending them a (fixed-size) key for each file is not too much overhead.
The thing that's really put me off the surgery is the improvement in contact lens technology over the last 10 years. My sight is sufficiently bad in one eye that I'd have to have an implanted contact lens, although the other could be fixed by burning the cornea. The contact lenses that I have now; however, are so thin that I don't notice that I'm wearing them most of the time and can be worn overnight. I put them in at the start of a month and then change them a month later. There's a slightly increased risk of eye infection, but they come with six monthly checkups to prevent this. I was wearing the previous generation of lenses (which were noticeably thicker) for about 10 years without serious issue, but with slight irritation around the eyelids caused by the thickness of the lens (and my eyes sometimes getting very dry, because it took a long time for the lens to dry out, so I'd forget to blink sometimes). With the newer ones, it's basically as if I had fully working eyes and if my prescription changes then I can put in different lenses next month.
There are techniques that allow searching within encrypted files, but they rely on the client creating the index. You can then search the index for an encrypted search term and, if you know the keys, interpret the answer. Getting this right is quite tricky (there are several research papers about it), so he's right, but it's not impossible.
The main reason that I suspect DropBox discourages encryption is that they rely a lot on deduplication to reduce their costs. If everyone encrypted their files, then even two identical files would have different representations server-side if owned by different users, so their costs would go up a lot.
Slashdot Mirror
Yeah, lets compare a 40 year old monopoly company (making money w large contracts) to a bunch of small upstart developers (making money $0.99 at a time) and laugh.
Let's not. Let's compare the mobile app market to one company. The mobile app market has a number of small upstart developers making $0.99 at a time, but it also includes companies like IBM, Microsoft, Apple, Adobe, and a large number of software houses that are 20-40 years old, several of which have been on the receiving end of antitrust lawsuits.
This is, unfortunately, the case with a number of funding bodies in academia. For example, DARPA won't pay for my membership, but will pay for the conference. My institution decided to pay for membership out of a different pot of money that doesn't have these restrictions, which ends up with a saving of a few hundred dollars on one account and a cost of a hundred dollars on another.
Ah, you're in the USA? Here, most people have pre-pay plans (being locked into a contract is generally seen as negative, unless it comes with some really good deals) and so get the phone that they bought along with their SIM and then hang onto it until it breaks or someone gives them a new one. I don't think I know anyone who pays close to $40/month on a phone bill (a fifth to a tenth of that is common and it's hard for a contract that comes with a new phone to be that cheap). At that price, I'd probably do without a mobile.
Amazon's app store is a bit better, because they're good at correlating things you've bought with things you might want to buy, so have recommendations that don't totally suck. The only reason I actually have it installed though is their free app of the day (which isn't necessarily a good thing - there are a couple of games that it's given me that have wasted a lot of my time...)
Oh, and for reference, Microsoft's revenue for the last quarter was about $20b. Which makes $13b spread between 1.2m apps seem very, very small. (I'm assuming that your $13b number is just for developers selling through the Apple App Store. If it also includes Android then it's an even more laughable number).
Finally, I never see ACM articles linked from Google. You'd imagine searches for things like "reduction of inter block artifacts in discrete wavelet transforms" should nail 5 ACM articles on the first page. Instead, I see mailing lists.
They'll show up if you use Google Scholar. If you're using the main search engine to find papers, then you're probably doing it wrong...
There is as an academic. Apparently being a member of the ACM has a negative value, because in exchange for the $99/year membership fee I typically get a $100-150 discount on attending ACM conferences. If you go to a couple of conferences a year then that's a good deal. For people outside academia, there's less relevance. ACM Queue, which provides material for 'practitioners' section of Communications of the ACM, generally has some good material, but it's all free whether your an ACM member or not.
I like the ACM as an organisation, but they're hard pressed to justify the cost of membership.
Wikipedia has a nice table of the relevant data. Per capita statistics are a bit misleading as they don't count for different levels of car ownership. Per vehicle statistics are a bit better. The UK has 6.2 fatalities per 100,000 motor vehicles (per year), whereas the USA has 13.6. Generalising this to 'Europe in general' doesn't really work though: Greece, for example, has 13.8 and Portugal has 18.
Even that doesn't tell the whole story though, because people in the UK laugh hysterically when we hear how long people in the USA think a reasonable daily commute is and so cars in the USA are likely to be driven further, which might account for the difference. Taking that into account and using the numbers for fatalities per billion km driven, the UK has 4.3 and the USA 7.6 , so under twice as many. As the grandparent said: not too far behind.
Getting the majority of people to vote for someone who actually held and was willing to act on opinions that they agree with, rather than the one who spouts platitudes and pretends to agree on a couple of specific issues. Good luck with that.
I'm pretty sure Ada programmers feel superior to just about anyone, yet are way down that list. I doubt move VB programmers even know what Ada is...
I can only assume that you rarely talk to non-geeks. I upgrade my phone roughly every 3 years and most of my non-geek friends have significantly older phones than me. Many of them get new phones only when a geeky relative upgrades and hands down their old device, so the least technical users end up with the least secure devices...
Because you can make more money if you invest more capital. If you have a project that has a 10% annual ROI and have $1m in the bank, then you can double your money if you use that as collateral and borrow $10m to invest. This is a big part of the reason why money tends to concentrate in the hands of people who already have money.
A compiler that is as well-designed and useable as Linux and Git? It already exists
The reason that most extensions exist is that there is (or was) no way of implementing things that people want with standard C. Inline assembly is one example. All modern C compilers support it, but GCC and Microsoft's compilers use different syntax (most other compilers implement one or the other, sometimes both). Without it, you require that every time you want to use even a single instruction of platform-specific assembly code, you must write an entire function and call it.
Atomics were another big reason for extensions. Prior to C11, if you wanted atomic operations, you needed either assembly or non-standard compiler intrinsics. Efficient vector support is another one.
While that's technically true, the Ada and Fortran front ends are both using DragonEgg, which is a GCC plugin that converts GIMPLE to LLVM IR. It doesn't work well with GCC 4.7 or newer, produces poor debug info, and is now largely unmaintained. There is a Flang project to produce an LLVM front end for Fortran, but it's very immature. The Ada Labs guys were looking at producing an LLVM front end for Ada, but I don't know that they got anywhere with it.
Clang wasn't. Clang began in 2007, after Chris Lattner had moved to Apple. Before then, if you wanted to compile C code with LLVM, you had to use llvm-gcc, which was a horrible hack that took a forked version of GCC and translated one of the GCC IRs into LLVM IR before code generation.
The problem is worse on Android than on many other platforms because there are very few native shared libraries exposed to developer and there is no sensible mechanism for updating them all. If there's a vulnerability in a library that a load of developers use, then you need 100% of those developers to update the library and ship new versions of their apps to be secure. For most other systems, core libraries are part of a system update and so can be fixed centrally.
I doubt Apple has such a patent. Both of these were features of Symbian at least since EKA2 (over 10 years ago) and, I think, earlier. Apple may have a patent on some particular way of exposing this functionality to the UI, but that's about the most that they could have without it being shot down in court in 10 seconds (prior art that's in the form of a phone OS that millions of people owned is hard to refute).
Everything you ask for exists. The reason that Google, Microsoft, and Dropbox don't use them is that their entire business model depends on differentiation. If you could connect to their services with any third-party client that also worked with a server that you set up yourself and with their competitors' services, then their hold on the market becomes very tenuous. You're searching for technical solutions to business problems.
The 'you can skip in 5 seconds' ads amaze me. Presumably the people using them know that they have 5 valuable seconds that everyone can see, yet they uniformly squander them. I've almost never seen an ad that tells me anything interesting in the first 5 seconds, which isn't that surprising, but it's really surprising to me that most don't even tell me what the product is. Several that I've seen use the first 4 seconds to fade from black, then get 1 second of something incomprehensible before I hit skip.
Please correct me if I'm wrong because I may not have imagined this system properly. I was thinking the idea was that you encrypt each file with a single unique key, and then to use a public-key encryption scheme to encrypt that key. You can then send the encrypted file and the encrypted key to another user, knowing that it will need that users private key to decrypt.
Every time you upload a file, you generate a random symmetric key. You encrypt the file with this key and the key with your public key. If you want to download the file, you get the file and the encrypted key and then you decrypt the key with your private key and then decrypt the file. When you create the account, you upload your public key.
When you want to share a file with everyone, with no access control, you download the encrypted key, decrypt it, and provide it to the server. The server can then decrypt the file.
When you want to share a file with a limited set of users, you download each of their public keys (which you can cache in the client) and the encrypted symmetric key, decrypt the key, and then encrypt it once for each user. They will then only be able to access it with their client.
I'm not sure who you're 'we' as in 'internet community' is. We do have standards and off-the-shelf libraries for everything required to implement this and others have done so in the past (one of my colleagues during her PhD did back around 2006, to give one example, others have implemented more complex and flexible schemes more recently). Note that this is the simple textbook scheme for doing this kind of system. It's been implemented before and doubtless will be again. If you check the research literature then you'll find more interesting schemes.
The only problem is if you want to be able to access it from the browser, without some kind of plugin (Google actually does compile OpenSSL with Emscripten to do ASN.1 parsing, but I wouldn't recommend using it for encryption).
then you may as well just give the server the AES key and ask it to decrypt the file
But in that model, if "the server" has the key, wouldn't Dropbox have the key? I thought that was the whole thing people were freaking out about.
No, you'd have the key. If you wanted to share the file publicly, then there's no point in keeping it encrypted, so you'd provide the server with the key and it would decrypt, saving you the cost of downloading and reencrypting.
I understand what you (and the AC) are saying about storing an encrypted key on the server, and then re-encrypting the key for each new user you'd want to share with. That's a clever arrangement and I admit that I hadn't thought of it, but it still seems like it has the potential to create more complexity than most people want to deal with. It still means you need to manage various encryption keys, and we (Internet culture) seem intent on not developing a coherent system for managing encryption keys.
The client just needs one key, the RSA (or equivalent) public key. You'd need to copy this between devices, but it's relatively small (under 1KB). It's small enough to fit in a version 40 QR code quite easily, so you could set up mobile devices by displaying the QR code on your laptop screen and point the mobile device's camera at it, if you don't have any sensible way of transferring files between devices. The client then has to download the file and the associated key, decrypt the key with the locally-stored key, and then decrypt the file, but that's not something that's exposed to the user.
The anonymous poster pointed out a simpler mechanism, which is used in practice on file stores that want to be encrypted on the server. This technique also has a number of advantages. Using a symmetric cypher is generally faster than an asymmetric one and using a different key for each file is just good practice anyway as it limits the damage that certain kinds of trojan can do. If you're sharing with everyone, then you may as well just give the server the AES key and ask it to decrypt the file. If you're sharing with just a few people, then sending them a (fixed-size) key for each file is not too much overhead.
The thing that's really put me off the surgery is the improvement in contact lens technology over the last 10 years. My sight is sufficiently bad in one eye that I'd have to have an implanted contact lens, although the other could be fixed by burning the cornea. The contact lenses that I have now; however, are so thin that I don't notice that I'm wearing them most of the time and can be worn overnight. I put them in at the start of a month and then change them a month later. There's a slightly increased risk of eye infection, but they come with six monthly checkups to prevent this. I was wearing the previous generation of lenses (which were noticeably thicker) for about 10 years without serious issue, but with slight irritation around the eyelids caused by the thickness of the lens (and my eyes sometimes getting very dry, because it took a long time for the lens to dry out, so I'd forget to blink sometimes). With the newer ones, it's basically as if I had fully working eyes and if my prescription changes then I can put in different lenses next month.
The main reason that I suspect DropBox discourages encryption is that they rely a lot on deduplication to reduce their costs. If everyone encrypted their files, then even two identical files would have different representations server-side if owned by different users, so their costs would go up a lot.