The OS would only needs to fool some malware application, not to mislead a court... or what is actually your point? There are other malware out there than the Bundestrojaner...
Does it matter whether a bad app uses crashing or uses nagging to force its users to acquiesce?
Both would be bad, especially if the crashing is done deliberately (nagging is always deliberate, I presume...). But nobody advocates either of them (well, except malware authors...)...
It's a bad app trying to strong-arm the user.
Exactly my point...
The benefit is that good apps have an opportunity to behave reliably when the user wants privacy.
True enough, pretending to grant permission may lead to a less reliable operation, but that may be the price to pay in an ecosystem where most apps couldn't be trusted to respect the user's privacy otherwise. It's a sad world, and those that "stand by watching" (while they still have a choice) are as guilty here as the actual perpetuators.
It's a critical mass thing. If 80% of the users don't object to the 10% of bad apps that don't respect privacy, then those 10% grow into 99.99% for lack of incentive, and the other 20% of users are now deprived of making that choice.
We want the app programmer not to know.... The problem are not innocently bug apps, but deliberately intrusive apps. If they get back "null", they may refuse to work until the user finally caves in and grants them access (to contact database, location data,...), that's the whole point.
An app which refuses to acknowledge the possibility that it might be denied permission, is an app you should not use.
The problem is, most users cave for such pressure.
Which means that suddenly you might be in a situation where all apps for a given purpose might do this. Then even the reasonable users have to either cave in or just accept that they have to do without any kind of app to fulfil this purpose.
I was in such a situation recently, when needing a replacement filter basket for my espresso machine... and had to notice that all online shops selling such spare parts would force me to accept their intrusive javascript. Eventually I caved...
It's really trivial to handle, especially for a non-critical app feature.
Problem is, if rather than just disabling a single feature, the app stops to work altogether...
Accessing the framework APIs will prompt the system to ask for permission, on behalf of the application. Basically, most APIs will work irregardless of what the user chooses. What those APIs return is directly related to the users choice- for example, if the user says "no" when the application attempts to determine your location via Core Location, then the CL APIs will still work- they'll just return useless information (basically hardcoded to nothing). The other APIs work in the same way.
This was done for backwards compatibility (so applications don't break just because the privacy stuff decided you can't get access to XYZ- the APIs for XYZ still work as expected, they just don't return any usable information) and so that applications can't side step the process of asking for permission but attempting to access the APIs anyways.
Very sensible choice. Why can't Android do the same? Or for that matter, Javascript on desktop browsers?
It is possible to circumvent all of this by going around the system frameworks, but that is not trivial in the least- and Apple will smack you down hard for even attempting to access the private APIs you need to do so. You either go through their public APIs and get on the app store, or find some other way onto user devices (in which case the user is responsible for whatever stupidity they're going to run as root on their handheld).
Now, this is less optimal. The OS or runtime should enforce well behavedness, not the app-store. There might be many reason why a user might bypass the app-store (such as getting apps that compete with Apple's built-in functionality, or are not up to Apple's morality standards), he should not be punished for this choice by having the app bypass system security...
In java, applets have to respect the sandbox rules no matter where you got it from. There is just no way to use "private APIs" that give extra rights. It's enforced by the run-time (well, unless there are security holes in that runtime, but that is a different discussion...).
... is that if apps are denied permission, they may refuse to work (even though the permission requested might not actually needed for the app's official purpose).
So, what we would need is a change in how permission refusal is communicated (or not communicated) to the app. The OS should always tell the app "yes you got permission", but then just fake the action (return plausible but fake location data, plausible but fake adresses, etc.). Or fail with a code not linked to permission (pretend that there is no cellular network available if user refused permission to use it)
That way, it will be much more difficult to pressure users into granting apps each and every right they ask for...
My mail to my house is push, the fact that I am not there to read it does not change that.
But your mailbox is still there, and most importantly for this discussion: the road that leads to your house is there as well.
Even out of band will have to be received by something to wake the rest of the device.
But push allows the system to be only woken up when there is indeed mail. Think of it like the postman sounding his bugle to signal the people inside the castle that he is there, and they can lower the draw bridge to let him in. The alternative would be for them to set their alarm clock to each full hour, and go check to see whether he was there... Guess which is the most efficient one?
Maybe they are afraid of
step 1) Give away inventory for free at schools etc
step 2) Schools find a way to root devices and install Linux (Android,...) on them
You use keep alives to tell the network you need to keep this IP, they are very small and very infrequent.
But are they supported universally? I don't believe so, especially given the worldwide IP address shortage...
When you wake to send that, and you only wake a tiny little bit you check for the new email packet.
But then, it's not really push any longer... If you only "wake" once per hour, you'd still have to wait up to an hour to get that notification. "Real" push systems (based on some out-of-band signalling) might be faster.
If the phone brings down its IP connection while some TCP flows are still open, it might not be able to re-attach to these, as it will most probably get a different IP address once it brings up the physical connection again. Not to mention that the server would have no way of sending a packet to the mobile during this "sleeping" phase...
If on the other hand it doesn't bring down the IP connection, it might incur roaming fees, depending on commercial offers, contractual setups etc. If user is lucky, and is charged by traffic, then there will be no problem (almost no packets exchanged during idle). If on the other hand, he is billed over time (like some Austrian and Eastern European operators do), he'd still be stuck with a hefty roaming bill...
Yes, but that only works while you are connected to the server, which needs a (potentially expensive) IP connection.
True push might "wake up" your phone with a special SMS when a mail is ready, and then the phone only needs to establish the connection when needed, rather than keeping it up permanently, potentially incurring roaming fees.
At least with IMAP over SSL I can be reasonably sure not too many folks are reading my email.
Still depends on how RIM's infrastructure is set up, whether they actually validate the certificates of the mail servers they connect to.
If not, the passwords are still within the NSA's reach.
Theoretically, anybody with a blackberry should be able to test this by setting up a mail server with a deliberately bad certificate: if Blackberry can still log in, it means that it doesn't check the certificate!
So, since Ballmer is alive, throwing chairs is now good?
Well, usually, exercise is considered to be good for your health (and thus longevity...). However, looking at Ballmer, he would benefit from throwing more chairs, not less!
... why are certification agencies issuing certificates for such fake domains? Even if the domains remain non-existant, it's asking for trouble!
Just imagine if company A asks for a certificate for mail.corporate, but then uses it for industrial espionage against company B's mail.corporate server...
We could call a vote of no confidence in congress.
In Luxembourg, we did exactly that. But the bad news is that even though the Prime Minister stepped down, he will still be running in the elections to replace himself.
... and we have a sufficient number of elderly (or just disconnected...) people who don't grasp the seriousness of the matter that he might actually win. Weird world.
No proof, but it wouldn't have been the first time in history. The opening night of Eurodisney Paris was marred by a terrorist attack against one of the power lines to the parc. Fortunately, this bomblet didn't have any impact on the opening ceremony, thanks to a redundant power supply.
Even if it might not succeed the first time (nor the second,...), voting third parties still send a signal.
A good strategy:
if you've got a republican president that behaves like a republican (Bush vs. Obama), vote democrat!
if you've got a democrat president that behaves like a republican (now), vote third party! The outcome will be republican at first, but hopefully every time this situation happens, third parties will be getting bigger and bigger until they make it. Think long term.
... and, as many people here say: Snowden did not actually reveal anything which most of us didn't already know or could reasonably have guessed. Yet, despite the obviousness of his revelations, the US government is sufficiently pissed off at him to risk an international diplomatic incident in order to get him.
Or the FBI was been tipped off and missed both 9/11 and the Boston Marathon bombers?
... or more appropriately, that they have deliberately missed the hints about both bombings. You know, it's in their best interest to let the occasional act of terrorism happen, and the bigger the better. Indeed, such events mean more funding, and laws more favorable to them.
Currently, in Luxembourg there is a lawsuit going on about terrorist activity in the eighties. And everything points towards actors within the government. And, this is not just some conspiracy bullshit, this is serious enough that many people call for the resignation of the Prime Minister.
So, if the Lux government can do state terrorism, so can the US government! This is being proved in a court of law after all, and not just exposed on a shady blog.
Slashdot Mirror
The OS would only needs to fool some malware application, not to mislead a court... or what is actually your point? There are other malware out there than the Bundestrojaner...
Does it matter whether a bad app uses crashing or uses nagging to force its users to acquiesce?
Both would be bad, especially if the crashing is done deliberately (nagging is always deliberate, I presume...). But nobody advocates either of them (well, except malware authors...)...
It's a bad app trying to strong-arm the user.
Exactly my point...
The benefit is that good apps have an opportunity to behave reliably when the user wants privacy.
True enough, pretending to grant permission may lead to a less reliable operation, but that may be the price to pay in an ecosystem where most apps couldn't be trusted to respect the user's privacy otherwise. It's a sad world, and those that "stand by watching" (while they still have a choice) are as guilty here as the actual perpetuators.
It's a critical mass thing. If 80% of the users don't object to the 10% of bad apps that don't respect privacy, then those 10% grow into 99.99% for lack of incentive, and the other 20% of users are now deprived of making that choice.
We want the app programmer not to know.... The problem are not innocently bug apps, but deliberately intrusive apps. If they get back "null", they may refuse to work until the user finally caves in and grants them access (to contact database, location data, ...), that's the whole point.
An app which refuses to acknowledge the possibility that it might be denied permission, is an app you should not use.
The problem is, most users cave for such pressure.
Which means that suddenly you might be in a situation where all apps for a given purpose might do this. Then even the reasonable users have to either cave in or just accept that they have to do without any kind of app to fulfil this purpose.
I was in such a situation recently, when needing a replacement filter basket for my espresso machine... and had to notice that all online shops selling such spare parts would force me to accept their intrusive javascript. Eventually I caved...
It's really trivial to handle, especially for a non-critical app feature.
Problem is, if rather than just disabling a single feature, the app stops to work altogether...
Just learned from another post that this is actually what iOS is doing. Kudo's for Apple if this is the case, for once they are doing something right!
Accessing the framework APIs will prompt the system to ask for permission, on behalf of the application. Basically, most APIs will work irregardless of what the user chooses. What those APIs return is directly related to the users choice- for example, if the user says "no" when the application attempts to determine your location via Core Location, then the CL APIs will still work- they'll just return useless information (basically hardcoded to nothing). The other APIs work in the same way.
This was done for backwards compatibility (so applications don't break just because the privacy stuff decided you can't get access to XYZ- the APIs for XYZ still work as expected, they just don't return any usable information) and so that applications can't side step the process of asking for permission but attempting to access the APIs anyways.
Very sensible choice. Why can't Android do the same? Or for that matter, Javascript on desktop browsers?
It is possible to circumvent all of this by going around the system frameworks, but that is not trivial in the least- and Apple will smack you down hard for even attempting to access the private APIs you need to do so. You either go through their public APIs and get on the app store, or find some other way onto user devices (in which case the user is responsible for whatever stupidity they're going to run as root on their handheld).
Now, this is less optimal. The OS or runtime should enforce well behavedness, not the app-store. There might be many reason why a user might bypass the app-store (such as getting apps that compete with Apple's built-in functionality, or are not up to Apple's morality standards), he should not be punished for this choice by having the app bypass system security...
In java, applets have to respect the sandbox rules no matter where you got it from. There is just no way to use "private APIs" that give extra rights. It's enforced by the run-time (well, unless there are security holes in that runtime, but that is a different discussion...).
So, what we would need is a change in how permission refusal is communicated (or not communicated) to the app. The OS should always tell the app "yes you got permission", but then just fake the action (return plausible but fake location data, plausible but fake adresses, etc.). Or fail with a code not linked to permission (pretend that there is no cellular network available if user refused permission to use it)
That way, it will be much more difficult to pressure users into granting apps each and every right they ask for...
My mail to my house is push, the fact that I am not there to read it does not change that.
But your mailbox is still there, and most importantly for this discussion: the road that leads to your house is there as well.
Even out of band will have to be received by something to wake the rest of the device.
But push allows the system to be only woken up when there is indeed mail. Think of it like the postman sounding his bugle to signal the people inside the castle that he is there, and they can lower the draw bridge to let him in. The alternative would be for them to set their alarm clock to each full hour, and go check to see whether he was there... Guess which is the most efficient one?
Maybe they are afraid of ...) on them
step 1) Give away inventory for free at schools etc
step 2) Schools find a way to root devices and install Linux (Android,
You use keep alives to tell the network you need to keep this IP, they are very small and very infrequent.
But are they supported universally? I don't believe so, especially given the worldwide IP address shortage...
When you wake to send that, and you only wake a tiny little bit you check for the new email packet.
But then, it's not really push any longer... If you only "wake" once per hour, you'd still have to wait up to an hour to get that notification. "Real" push systems (based on some out-of-band signalling) might be faster.
If on the other hand it doesn't bring down the IP connection, it might incur roaming fees, depending on commercial offers, contractual setups etc. If user is lucky, and is charged by traffic, then there will be no problem (almost no packets exchanged during idle). If on the other hand, he is billed over time (like some Austrian and Eastern European operators do), he'd still be stuck with a hefty roaming bill...
IMAP even supports push via IMAP IDLE.
Yes, but that only works while you are connected to the server, which needs a (potentially expensive) IP connection.
True push might "wake up" your phone with a special SMS when a mail is ready, and then the phone only needs to establish the connection when needed, rather than keeping it up permanently, potentially incurring roaming fees.
At least with IMAP over SSL I can be reasonably sure not too many folks are reading my email.
Still depends on how RIM's infrastructure is set up, whether they actually validate the certificates of the mail servers they connect to.
If not, the passwords are still within the NSA's reach.
Theoretically, anybody with a blackberry should be able to test this by setting up a mail server with a deliberately bad certificate: if Blackberry can still log in, it means that it doesn't check the certificate!
can you hear my packets now?
ping -a linux.org
There are plenty of New-Yorkers who have iPhones...
So, since Ballmer is alive, throwing chairs is now good?
Well, usually, exercise is considered to be good for your health (and thus longevity...). However, looking at Ballmer, he would benefit from throwing more chairs, not less!
Just imagine if company A asks for a certificate for mail.corporate, but then uses it for industrial espionage against company B's mail.corporate server...
We could call a vote of no confidence in congress.
In Luxembourg, we did exactly that. But the bad news is that even though the Prime Minister stepped down, he will still be running in the elections to replace himself.
Terribly amusing in the fact that the federal agents would probably be the one making arrests and escorting the security out of the building.
... thereby settling the difficult question "how to prove a fed"...
... i just searched for Prism within the comments, and not a single hit... I herewith change this :-)
Proof ? Any credible material, anywhere ?
No proof, but it wouldn't have been the first time in history. The opening night of Eurodisney Paris was marred by a terrorist attack against one of the power lines to the parc. Fortunately, this bomblet didn't have any impact on the opening ceremony, thanks to a redundant power supply.
A good strategy:
I'm so glad I live in a country that can't afford a massive surveillance program like this.
Are you sure? Even a small country such as Luxembourg can afford to have a (small) intelligence agency, still capable of creating a big mess!
No country is too small to spy, no person is too insignificant to be spied upon!
They are surely not concerned about what he has revealed, but more about what he might yet reveal (or confirm) in the future...
Or the FBI was been tipped off and missed both 9/11 and the Boston Marathon bombers?
... or more appropriately, that they have deliberately missed the hints about both bombings. You know, it's in their best interest to let the occasional act of terrorism happen, and the bigger the better. Indeed, such events mean more funding, and laws more favorable to them.
Currently, in Luxembourg there is a lawsuit going on about terrorist activity in the eighties. And everything points towards actors within the government. And, this is not just some conspiracy bullshit, this is serious enough that many people call for the resignation of the Prime Minister.
So, if the Lux government can do state terrorism, so can the US government! This is being proved in a court of law after all, and not just exposed on a shady blog.