To my knowledge, Apple doesn't do RAM access. Some law-enforcement forensic analysts might, but I don't know of iOS RAM-capture tools that actually work. The whole field is poorly-understood.
"Active" here almost certainly means "not deleted". LE analysts usually ask if you can access deleted data.
The story here is that Apple can unlock and access the files on an unencrypted iPhone. That shouldn't come as a surprise to anyone. You can do that without Apple's help, and you can do it to unencrypted Android phones, unencrypted hard drives, and pretty much any unencrypted data-storing device you have physical access to.
In the latter case, they're actually talking about you (party A) sharing a file that contains links. That file is shared to party B, who clicks on one of the links. The target of the link is a website, party C. The URL to the shared file is exposed to party C via the Referer header, which contains the URL to the shared file.
This exposure is non-obvious even to technical people, but it's commonplace. Paths get leaked all over the place, so information in paths absolutely must not be considered secure. For instance, TrueCrypt volumes (residing on non-encrypted systems) tend to leak paths to lots of their contents, via operating system features, to unencrypted space.
It's an extremely common design, and they also implement the other major alternative -- sharing with individuals that use per-user authentication. You can share Dropbox files either way (or both ways at once).
More simple, though "differently convenient", is to use the Dropbox sharing feature. The one where you share to individual users rather than making a public link. I thought the Dropbox application was pretty clear about the fact that the links were fundamentally public (though I'm in security, so I read things differently). The user-based sharing is less convenient, in that it requires some degree of "registration" with Dropbox to use it, but it has actual access controls.
If there's a "shared link" to the data, as you say, you should treat it as public. This is classic "security through obscurity" -- the only thing restricting access is that people don't happen to know the URL, but URLs turn out to be quite discoverable.
If you want to be superstitious about ECC, suit yourself. I have no doubt that the NSA would like to discourage the use of ECC and curve 25519 in particular.
Actually, they promote elliptic-curve cryptography. All of the Suite B asymmetric ciphers have moved from factoring problems to elliptic-curve ones.
Now, that leaves people in a sticky situation. See, they have some reason to distrust ciphers promoted by NSA. But NSA used to promote using DH/RSA.
Mathematicians in the public space have been making interesting progress in solving the factoring problem. Quantum computers, which can probably solve factoring problems efficiently, have started to appear in very limited contexts (very limited). Public-space crypto experts are getting uncomfortable with the security of RSA as a result. The NSA, besides spying on people, is *also* tasked with helping US interests maintain computer and signals security. The NSA has a lot of good mathematicians and a lot of advanced computing resources. The NSA now advocates that nobody that is storing data that the government considers valuable use RSA or Diffie-Hellman any more. What do you suppose that might all mean?
It may be a case of "you're damned if you do, you're damned if you don't". But using RSA seems to be a lot more damning.
Strictly speaking, yes. Though it would be hard to fault people for not bothering with the vaccine, given its very small benefit.
However, in that hypothetical scenario, your error is much larger than your difference -- statistically, the number of lives that it saves versus kills are the same.
If a vaccine isn't safe but it is effective, then the negative effects of killing a few people directly might be considered to be outweighed by the positive effects of indirectly saving even more.
If a vaccine kills fewer people than it saves, then it's pretty safe.
See, within the US or when targeting Americans, the Constitution and other laws apply.
When the US kills non-citizens on foreign soil, there's no US law against it. That's because that's armed combat. (It might also be a covert operation, in which case whether it's legal is up to the country in which it took place. It's probably not legal.) Dealing with other countries killing your citizens within your borders has traditionally been dealt with through this thing called "war", and, more recently, through the UN and other international alliances.
You could charge a fortune, and people would happily pay it, to have old-timey carriages pulled by robotic animals in New York City. That just screams "shut up and take my money".
An Aeropress doesn't make espresso. It makes a good drink, and it does it decently well, but you're comparing different coffee beverages. (Could the beverage made by a $30 Aeropress satisfy many people just as well as espresso. Sure!)
Formica doesn't have anywhere near the mechanical and chemical properties of granite or other high-end countertops. If all you want is something that will hold up cutting boards and room-temperature objects, they do the same thing, yes. But a granite countertop is practically indestructible.
Because the depth-of-field effect generated by your eyes depends on the distance to the subject, which is largely flat in 3D movies. They can't add DoF blur because they don't know where your eye will focus. They can put the most-obvious object in focus and then the other objects will be blurred, but if you focus your eyes on them, they won't come in to focus, which is not how your eyes normally work. (The same is true in 2D movies, naturally, but there isn't the illusion of the ability to focus in those.) They can make all objects in focus (if they can light the scene enough to use a small enough aperture), but then you won't get the correct DoF blur generated by your eyes.
You know, your eyes have a substantial depth-of-field effect, too. You often don't notice, because your mental ability to pay attention to objects is tied pretty strongly to where your eyes are actually focusing, so anything you look at is in focus (because you focus on what you're looking at). However, you can really notice when you look at images that have deep DoF or, say, 3D movies (where they can't possibly get the DoF right).
He seems to be mixing some terms a little bit. Correcting distortion lowers sharpness -- though for any image displayed only at 1080p, it probably makes no difference. Correcting some other aberrations, like chromatic aberration (CA) lowers contrast (and sharpness). Higher sensitivity in a digital sensor lowers contrast a whole lot more, though. That, and poorly-controlled lens flare, usually the major driver of low-contrast images out of smartphones. If you take a picture in daylight, don't point it right at the sun, and have a clean lens, the picture comes out pretty good.
I don't have a good sense as to how good the smartphone lenses are now. But people are now making pancake lenses for interchangeable-lens cameras that are tiny and of very high quality. I suspect that it's not to hard to engineer good smartphone lenses, either.
The problem is that with such a small sensor, you need very bright lenses to get shallow depth of field or good low-light performance, and those are just plain hard to make.
Real security is very hard. But really, real [lots of things in programming] are very hard if you want them done right. It's certainly possible for a higher-level language to expose the capabilities necessary to do things right. But if they don't, then it's a bad situation.
...you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.
Only if you've set that part of your stack to locked. Otherwise it could get paged out to disk. Thanks to the fun of timing on computers, the amount of actual time that passes between "receive [into memory]" and "zero out" is arbitrarily long.
So if C is so bad why should we trust the languages that are implemented in it? You do realize that most of these "safe" languages are written in C, right?
I'm just going to link to a previous comment where I answered the same question.
TLDR: Languages aren't "written in" anything, and the language the compiler is written in has no bearing on the capabilities of the language it compiles. (We're all Turing complete here.)
For one, you need to be able to correlate your requests with the other party's responses in a way that is non-replayable (regardless of the encryption used).
The payload is of variable length so that heartbeats can be used for path MTU discovery.
Just because someone "sees no reason" for a design decision doesn't mean there is no reason.
The heartbeat spec isn't necessarily a great design, but it's by no means the problem. If you can't implement what is essentially ping that passes two variable length data fields, what hope do you have of being able to implement anything useful?
And what languages are these languages themselves written in?
Languages aren't written in anything. (Though, the specification for a language could be written in English, for instance.) Compilers and interpreters are written in a language.
and if those languages are dangerous to directly write apps in, then surely they must be equally dangerous to write the compilers and platforms on which your non-VM language runs.
A program isn't run by a compiler, it's compiled by a compiler. There's a pretty significant difference.
There's also a significant difference between writing an application in C and writing an application in a language that is compiled by a compiler written in C. For one, the compiler has a much smaller attack surface. There is a lot less code in the compiler than there is in the set of applications written in that language. For another, vulnerabilities aren't magically transitive like that. Imagine a language, M, that is just like C, but it is impossible to create a buffer overrun. The M compiler is written in C. It contains a buffer overrun bug. That doesn't magically make M source code compiled with this compiler also contain a buffer overrun. To say it another way: the features of the language the compiler is written in don't really matter for the security of a compiled application, it's the quality of the implementation of the compiler -- the compiler needs to produce a binary that actually has the properties of the language it's compiling for.
At some point you're working with something written in C, C++ or assembler
No, you're not. Traditionally, a compiler is written in the same language that it compiles: so a C++ compiler is written in C++ and a Forth compiler is written in Forth. (Realistically, most are now written in C as a component of GCC.)
Slashdot Mirror
The appropriate paranoid step is enabling encryption. Then, turn off your phone if you suspect it may be taken from you.
To my knowledge, Apple doesn't do RAM access. Some law-enforcement forensic analysts might, but I don't know of iOS RAM-capture tools that actually work. The whole field is poorly-understood.
"Active" here almost certainly means "not deleted". LE analysts usually ask if you can access deleted data.
The story here is that Apple can unlock and access the files on an unencrypted iPhone. That shouldn't come as a surprise to anyone. You can do that without Apple's help, and you can do it to unencrypted Android phones, unencrypted hard drives, and pretty much any unencrypted data-storing device you have physical access to.
They do that by design. Referer is part of the spec. URLs -- or GET requests in general -- should not contain any private data. It's even CWE-598.
In the latter case, they're actually talking about you (party A) sharing a file that contains links. That file is shared to party B, who clicks on one of the links. The target of the link is a website, party C. The URL to the shared file is exposed to party C via the Referer header, which contains the URL to the shared file.
This exposure is non-obvious even to technical people, but it's commonplace. Paths get leaked all over the place, so information in paths absolutely must not be considered secure. For instance, TrueCrypt volumes (residing on non-encrypted systems) tend to leak paths to lots of their contents, via operating system features, to unencrypted space.
It's an extremely common design, and they also implement the other major alternative -- sharing with individuals that use per-user authentication. You can share Dropbox files either way (or both ways at once).
More simple, though "differently convenient", is to use the Dropbox sharing feature. The one where you share to individual users rather than making a public link. I thought the Dropbox application was pretty clear about the fact that the links were fundamentally public (though I'm in security, so I read things differently). The user-based sharing is less convenient, in that it requires some degree of "registration" with Dropbox to use it, but it has actual access controls.
If there's a "shared link" to the data, as you say, you should treat it as public. This is classic "security through obscurity" -- the only thing restricting access is that people don't happen to know the URL, but URLs turn out to be quite discoverable.
Dead. Where it belongs.
So start using ECC and give the NSA the finger.
If you want to be superstitious about ECC, suit yourself. I have no doubt that the NSA would like to discourage the use of ECC and curve 25519 in particular.
Actually, they promote elliptic-curve cryptography. All of the Suite B asymmetric ciphers have moved from factoring problems to elliptic-curve ones.
Now, that leaves people in a sticky situation. See, they have some reason to distrust ciphers promoted by NSA. But NSA used to promote using DH/RSA.
Mathematicians in the public space have been making interesting progress in solving the factoring problem. Quantum computers, which can probably solve factoring problems efficiently, have started to appear in very limited contexts (very limited). Public-space crypto experts are getting uncomfortable with the security of RSA as a result. The NSA, besides spying on people, is *also* tasked with helping US interests maintain computer and signals security. The NSA has a lot of good mathematicians and a lot of advanced computing resources. The NSA now advocates that nobody that is storing data that the government considers valuable use RSA or Diffie-Hellman any more. What do you suppose that might all mean?
It may be a case of "you're damned if you do, you're damned if you don't". But using RSA seems to be a lot more damning.
Strictly speaking, yes. Though it would be hard to fault people for not bothering with the vaccine, given its very small benefit.
However, in that hypothetical scenario, your error is much larger than your difference -- statistically, the number of lives that it saves versus kills are the same.
If a vaccine isn't safe but it is effective, then the negative effects of killing a few people directly might be considered to be outweighed by the positive effects of indirectly saving even more.
If a vaccine kills fewer people than it saves, then it's pretty safe.
Outside of US territory.
See, within the US or when targeting Americans, the Constitution and other laws apply.
When the US kills non-citizens on foreign soil, there's no US law against it. That's because that's armed combat. (It might also be a covert operation, in which case whether it's legal is up to the country in which it took place. It's probably not legal.) Dealing with other countries killing your citizens within your borders has traditionally been dealt with through this thing called "war", and, more recently, through the UN and other international alliances.
This idea is not getting modded up enough.
You could charge a fortune, and people would happily pay it, to have old-timey carriages pulled by robotic animals in New York City. That just screams "shut up and take my money".
An Aeropress doesn't make espresso. It makes a good drink, and it does it decently well, but you're comparing different coffee beverages. (Could the beverage made by a $30 Aeropress satisfy many people just as well as espresso. Sure!)
Formica doesn't have anywhere near the mechanical and chemical properties of granite or other high-end countertops. If all you want is something that will hold up cutting boards and room-temperature objects, they do the same thing, yes. But a granite countertop is practically indestructible.
Because the depth-of-field effect generated by your eyes depends on the distance to the subject, which is largely flat in 3D movies. They can't add DoF blur because they don't know where your eye will focus. They can put the most-obvious object in focus and then the other objects will be blurred, but if you focus your eyes on them, they won't come in to focus, which is not how your eyes normally work. (The same is true in 2D movies, naturally, but there isn't the illusion of the ability to focus in those.) They can make all objects in focus (if they can light the scene enough to use a small enough aperture), but then you won't get the correct DoF blur generated by your eyes.
It hasn't been boiled, and it actually spoils pretty quickly, mostly with a combination of lactobacillus and enteric bacteria.
You know, your eyes have a substantial depth-of-field effect, too. You often don't notice, because your mental ability to pay attention to objects is tied pretty strongly to where your eyes are actually focusing, so anything you look at is in focus (because you focus on what you're looking at). However, you can really notice when you look at images that have deep DoF or, say, 3D movies (where they can't possibly get the DoF right).
He seems to be mixing some terms a little bit. Correcting distortion lowers sharpness -- though for any image displayed only at 1080p, it probably makes no difference. Correcting some other aberrations, like chromatic aberration (CA) lowers contrast (and sharpness). Higher sensitivity in a digital sensor lowers contrast a whole lot more, though. That, and poorly-controlled lens flare, usually the major driver of low-contrast images out of smartphones. If you take a picture in daylight, don't point it right at the sun, and have a clean lens, the picture comes out pretty good.
I don't have a good sense as to how good the smartphone lenses are now. But people are now making pancake lenses for interchangeable-lens cameras that are tiny and of very high quality. I suspect that it's not to hard to engineer good smartphone lenses, either.
The problem is that with such a small sensor, you need very bright lenses to get shallow depth of field or good low-light performance, and those are just plain hard to make.
Why do you want to add a grammatical error to the Constitution? It's apparently hard enough to interpret as it is.
It doesn't need to be better than the market. It needs to be better than the market minus capital gains taxes and broker fees.
Depending on what you're using the money for, capital gains taxes may be zero. And 10% is worse than the index funds after fees -- this year.
Real security is very hard. But really, real [lots of things in programming] are very hard if you want them done right. It's certainly possible for a higher-level language to expose the capabilities necessary to do things right. But if they don't, then it's a bad situation.
10% wasn't better than the market last year. (It is, however, a very solid rate of return.)
...you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.
Only if you've set that part of your stack to locked. Otherwise it could get paged out to disk. Thanks to the fun of timing on computers, the amount of actual time that passes between "receive [into memory]" and "zero out" is arbitrarily long.
So if C is so bad why should we trust the languages that are implemented in it? You do realize that most of these "safe" languages are written in C, right?
I'm just going to link to a previous comment where I answered the same question.
TLDR: Languages aren't "written in" anything, and the language the compiler is written in has no bearing on the capabilities of the language it compiles. (We're all Turing complete here.)
For one, you need to be able to correlate your requests with the other party's responses in a way that is non-replayable (regardless of the encryption used).
The payload is of variable length so that heartbeats can be used for path MTU discovery.
Just because someone "sees no reason" for a design decision doesn't mean there is no reason.
The heartbeat spec isn't necessarily a great design, but it's by no means the problem. If you can't implement what is essentially ping that passes two variable length data fields, what hope do you have of being able to implement anything useful?
And what languages are these languages themselves written in?
Languages aren't written in anything. (Though, the specification for a language could be written in English, for instance.) Compilers and interpreters are written in a language.
and if those languages are dangerous to directly write apps in, then surely they must be equally dangerous to write the compilers and platforms on which your non-VM language runs.
A program isn't run by a compiler, it's compiled by a compiler. There's a pretty significant difference.
There's also a significant difference between writing an application in C and writing an application in a language that is compiled by a compiler written in C. For one, the compiler has a much smaller attack surface. There is a lot less code in the compiler than there is in the set of applications written in that language. For another, vulnerabilities aren't magically transitive like that. Imagine a language, M, that is just like C, but it is impossible to create a buffer overrun. The M compiler is written in C. It contains a buffer overrun bug. That doesn't magically make M source code compiled with this compiler also contain a buffer overrun. To say it another way: the features of the language the compiler is written in don't really matter for the security of a compiled application, it's the quality of the implementation of the compiler -- the compiler needs to produce a binary that actually has the properties of the language it's compiling for.
At some point you're working with something written in C, C++ or assembler
No, you're not. Traditionally, a compiler is written in the same language that it compiles: so a C++ compiler is written in C++ and a Forth compiler is written in Forth. (Realistically, most are now written in C as a component of GCC.)