Comment Re:OK... (Score 1) 205
I see your point but its not like this is going to dramatically affect the course of the project...
Solution: Buy a Google Nexus device: No 75c fee to worry about because it'd just go right back into their pocket anyway! Lean into the wind!
People put the Google services/apps on their custom rom phones separately, the custom roms rarely attempt to bundle or automate this because it's against Google's wishes.
Let's be fair about what Google really is. They take open source projects and profit from them. Now Apple has done this with Safari although I credit Apple for basically now giving away OS X and of course Safari has always been free.
Apple only gives OS X away because they have a problem with getting all the Macs to upgrade as nicely as the iOS users do. It has nothing to do with giving back. Apple LITERALLY takes open source projects and profits from them *and gives back only what is required of them by license*. Google gives back as much as it takes. If you think otherwise, my guess is you do not write code.
Meanwhile Google *literally* gives away all of Android except the bits that represents the Google part of the equation. Wow, are you trolling here??
Google to me is simply taking advantage of open source projects and while I don't see much in a legal problem with what Google does. I have issue with Google on so many levels with what they do. Google Play is certainly something I think Google already profits from. So why charge OEM's for something that is basically a web applications? The benefit its seems to me being installed on OEM's is all Google's.
I think that you are under the impression that a large portion of Android was not WRITTEN by Android the company which Google bought and subsequently open sourced. Android sits on top of Linux. So Google "took advantage" of the Linux stack, and then *gave back to the community* by open sourcing the rest of Android.
Additionally, the licensing fees here are for the GOOGLE APPS which were never open source, and Google is not taking advantage of ANY community members here. No one who is serious about open source cares.
Maybe I am missing something? But for me I have become real tired of Google the nickel and dimer of everything. From the government fuel breaks for their corporate jets to pushing Google + on everyone because it sucks and nobody really wants it. If you look at Google on a wider vision, its all about gathering data about your. Not to be paranoid but if you deny Google is not collecting this data then you are a fool.
Google is the nickel and dimer here?? When Android has been and continues to be free for OEMs? The Play Store, Play Services and the Google applications have ALWAYS been how Google maintains control over Android, this is not news. Also, no one denies Google is collecting data about us. But if you think that everyone else is NOT doing that, then *you* are a fool.
"Add that these proprietary applications and the proprietary Google Play Services are the primary areas for Android innovation and development and you end up with an operating system that is less and less 'free' in the freedom and cost senses of the word."
Bullshit. Charging miniscule amounts of money at the OEM level for Android does not affect my ability to install any application I want (or I have written), change central elements of the OS via addons, or dig down and read the source code if I wish. How, exactly, does Google monetizing Android stop any of that? Because I am locked out on the other platforms but at least on Android I have freedom!
And 75c up front on a device? Yes that WILL make it difficult to buy that new $700 phone I wanted! 75c is a LOT of money when you are spending that much, isn't it? And all of the other ways Android monetizes the platform are mostly indirect, as a result of the ecosystem.
Also, "Google Play Services" are the "primary areas" for "Android innovation", what the hell does that mean? I think TFS must have been written by someone butthurt by how awesome Android is and how popular it has become. Suck it up, Android is awesome.
Also (not to double post but), while I could have tested the assertion that browsers do not cache HTTPS resources, I think I will just let StackOverflow handle that one.
By default web browsers should cache content over HTTPS the same as over HTTP, unless explicitly told otherwise via the HTTP Headers received
http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https
That's from the accepted answer with 79 up votes. The second answer which has 119 upvotes says:
As of 2010, all modern, current-ish browsers cache HTTPS content by default, unless explicitly told not to.
A user should also always be warned when a post request is being resubmitted, since the HTTP RFC's only says get, head, put and delete should be idempotent.
RFC2616:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
While I agree with your sentiment here (I would prefer my browser to just not save any POST data at all for tab recovery since its so extremely rare that doing so would actually be useful), the RFC section you quote does not specify anything about persistence of resources to backing storage. It simply indicates the way browsers should treat these resources in a general sense. And according to the verbiage you have provided, Safari, Chrome and Firefox are all working as expected, because that paragraph is actually telling the browsers that automatic resubmission of non-GET requests can (and almost always does) have side effects (such as doing a duplicate post to a forum for instance).
Indeed my original post indicates briefly that I was already well-aware of this distinction between GET requests being idempotent (ie has no side effects) and other requests not being safe for resubmission. All modern standards-compliant browsers warn the users before resending the results of POST requests (Are you sure you want to resubmit?). Furthermore, none of these three major browsers (Chrome, Safari, Firefox) will act upon POST requests when they are pulled out of the session recovery feature.
Although respecting idempotency of non-GET requests is not at issue in this topic, I nonetheless tested this as a side effect (huzzah) of seeing how common the storage of POST data for recovery actually is.
Chrome
Chrome has an interesting behavior when it comes to storing POST data for reopening later, it appears to save the response content of an HTTP POST and does not resubmit the POST request. The user is presented with the content they saw when they initially sent the POST request. Nonetheless one can refresh (with Are you sure you want to resubmit) and the data will be resent in a new POST request. So Chrome is storing HTTP POST data for reuse when the tab is restored.
For HTTPS POST resources however, Chrome will _not_ automatically restore the page content from its backing store (and by implication likely does not save it) and also will not resend the request until the user manually refreshes the page. HOWEVER, at that point all of the original data from the first POST request is resent. Thus HTTPS POST data _is_ persisted by Chrome.
Firefox
Firefox has completely different behavior. From my testing it will save POST resources as GET resources, and when they are restored, I receive a new fresh GET request from my test server. So, Firefox is NOT saving POST data for reuse upon tab recovery.
Conclusion
I'm not saying that the RFC doesn't matter because it does. Chrome should be changed to be more in line with it. Regardless of whether it is best practice for browser makers to persist this data or not, my argument about the unreliable exploitation of this problem stands because the only time this is a problem is when a website delivers a POST response without an immediate redirect, which all sites SHOULD be doing.
The only time this isn't the case is when the resource presenting the login HTML form is also the action of the form it contains (or some variant of this situation). Now *that* is a bad practice that remains bad no matter what browser you are using.
Test Methods
Browser versions I tested with:
I created a simple PHP script (post.php) and hosted it on my HTTPS-capable test server:
<?php
echo "foo is: ".(isset($_POST['foo']) ? $_POST['foo'] : '<em>not present</em>')."<br/>";
echo "user input is: ".(isset($_POST['user']) ? $_POST['user'] : '<em>not present</em>')."<br/>";
echo "random number: ".mt_rand()."<br/>";
echo "request method: ".$_SERVER['REQUEST_METHOD']."<br/>";
?>
<form action="?" method="post">
<input type="hidden" name="foo" value="bar:<?= mt_rand() ?>"
User input: <input type="text" name="user" value=""
<button>Go</button>
</form>
I then submitted a request using this test page, saved the content outside the browser in a scratchpad, then force killed my local browsers and restored them. I repeated the tests both with HTTP and HTTPS to see the difference. The random numbers act as nonces so that I can immediately tell whether a request has been resent without looking in the logs (though I did watch the logs for verification)
All this article means is that Google has a bug to fix with regards to the post back response on the GMail login page.
Some in this discussion say things like:
along with the password and login.
from the article: "the login and password are not encrypted (see the red oval in the screenshot).
Let's be clear here. The only time that any browser's session restore feature would store your username and password is because it's part of the HTTP request itself. An HTTP request can be a GET or a POST. Good web developers never send sensitive information in a GET, nor should a GET actually _do_ anything other than get a resource. POST requests should be used for this instead, which do not convey the private information in the URL bar. Now, POST requests are not inherently more secure than GETs, and the data they pass is actually in the same format as the data in URL-based GET requests, and just as visible to observers on the network. I'm just getting some of the technical background set for all of the (clearly *very*) technical people who read Slashdot these days.
The "problem" is that older versions of Safari stores the details of POST requests "unencrypted". Which is fine because any encryption is meaningless if decryption can be done without user intervention. You would not encrypt some file and then place the key next to it and then store it that way would you? Nonetheless, this is exactly what happens when the encryption key is stored on the same volume as the encrypted file. If it can be found by software then it can be found by an attacker.
The really funny part is that this looks like the page Safari saved was a GMail login attempt which was unsuccessful (duh? the credentials are clearly not real). Google is doing authentication (almost) the right way here fellas, the only time that using GMail involves having your plaintext credentials in a POST request is during login and login alone. From there on out it's just record keeping (valid session list on the server, and a known session ID in the hands of each client).
You can see this for yourself by opening up an Incognito session and going to gmail.com, and typing fake credentials (i don't know, "kaspersky_user" and "kaspersky_pass" come to mind for some reason), then on the "Invalid login" page, hit refresh. You will be prompted by your browser to resend the login credentials. There! You see that the browser _still has_ your login credentials from before! AMAZING! Did you know that if you leave that tab untouched for three days your creds will still be resent again when you finally refresh??
Safari like any other browser with a restore session feature, saves that POST data. Because it's just POST data to the browser. And if you are sitting on a page that is itself the result of a POST request, the browser MUST save that data if it intends to give you the same page when you return... by both specification and convention. Google can fix this particular issue by redirecting their invalid logins back to GET requests like the rest of the civilized world. That protects their users account credentials from inadvertent storage on disk.
The more interesting part is how someone would think that this would be immediately dangerous, because had the user successfully logged in, they would not have been sitting on that POST request would they! That's right the credentials would have long vanished and would never have made their way to disk. The only time this would happen in practicality is when the credentials were NOT correct. Don't get me wrong, that can still be valuable to an attacker, but its a Google bug not a Safari one anyway. Nonetheless in GMail's situation, this is a rare and definitely not reliably exploitable issue from the perspective of potential attackers.
I cannot stress enough that credential leaks within a session backing file on a hard disk is only a problem when the site itself messes up or is written improperly and/or insecurely. And on the local side: If you don't trust the programs running on your user account, or you are not correctly using the multi-user capabilities of your operating system, you can't really trust anything you do on it, and you can't really complain either. Because the industry already gave you the tools to protect yourself and you just didn't use them because you were lazy.
Remember, UNIX spelled backwards is XINU. -- Mt.
