Todays model goes much more fine grain than OSes and DBs, with component package managers a la Nuget, Bower, NPM, Composer etc. The future TFA is talking about is here already but there's no "de-emphasis of code"... If there were this hypothetical "supply chain" of vendors... What would they pass between each other anyway? Oh yeah! CODE
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
And most phones have all the horsepower and HTML engine quality to pull off a lot of the sorts of user experiences you'd like (there are still rough spots though).
The device APIs in HTML5 now cover almost all the native capabilities you would want, once ServiceWorker and push notifications are fully deployed. They actually do a -better- job when used correctly because permissions are requested as needed instead of upfront, which avoids scaring the user off as they wonder why your recipe app's update needs camera and microphone support when you add the ability for users to post a Vine video of their baked goods (for instance).
Whenever this discussion comes up, I feel like Slashdot is just filled with old crufty C++ coders who don't understand the state of the modern web, because everyone just lands flat in the "its crap" opinion instead of discussing the few missing capabilities and the specific performance issues they've seen.
The web ain't perfect (yet) but its getting better every day, and has no vendor lock in or censorship issues like the mobile walled gardens have.
Yeah, you might not want to tell people that story. If the hard drive was empty afterwards, your PHP was running as root... sure hope that PHP wasn't being run from the web server.
You do know that SpaceShipTwo was not actually directly based on that sawmill right? You sort of talk about it like right underneath the VG logo is a wooden crank and connecting rod that drives the whole thing.
Are you trying to suggest that SpaceShipTwo should be a huge interplanetary spaceship that can reach Mars? Because firstly- we actually have never done that as a species, so its not as simple as "Oh just improve it 1%". We've designed them, but we have not built them. And the designs we have are ridiculously expensive. What would VG's business plan look like if they said "Welp, we're going to sink ALL of our money into this vehicle that can reach Mars, and we are going to make money by........... Crap bankruptcy already?" Capitalism is supply and demand, there are no businesses right now which *demand* a trip out that far. It WILL happen but we are not there today.
Secondly, do you not see the benefit of having smaller *shuttle* like vehicles that can transport us between all of the stations and vehicles that we need to build out infrastructure in space?
Yeah the "its useless" crowd on this article is full of crap. Branson has mentioned moving from successful sub-orbital "tourism" into space-assisted earth-to-earth travel, which would take less time than travel by plane. Then bump everything up for orbital flight with "SpaceShip3" or something, and VG has the potential to serve as a transportation provider to the space station (or whatever comes after it). Space tourism is just how they plan to bootstrap the company.
There are a lot of interesting developments in the space industry right now and lots of long term directions that people are working toward. There is talk of mining anything and everything, and trying to work out the logistics for how that would work. For someone to point a finger at any part of the industry and say "ITS USELESS", because they don't have the foresight to see how these pieces may one day fit together, is stupid
The best way to find this information for a certain mail provider is to include 'postmaster' in the search. Admittedly I had to click around a little to find Google's unlike most other providers where it is pretty obvious (they usually have a Postmaster Services page or something).
You want to block email based on the sender address? You do know that you don't need to be authorized to send a mail as another user, right? SPF and all of that does provide some protection, but there are tons of non-SPF domains out there that ham/spam could come from and any spammer can impersonate them or just use their domains for their return addresses.
And why exactly are you so perturbed at having the spam moved instead of not received. There's no benefit at all to the spammer if Google shunts their spam into a spambox. Besides, judging by the massive amount of Slashdotters here saying Google's filter is effective, sometimes too effective, do you really want to just have Google delete what it thinks is spam, and have some important mail be entirely deleted with no record of it having existed and no practical way of recovering it? No thanks. I don't think "that's what we want".
Besides, underneath the covers ALL mail delivery systems including Google's are reacting to changes to the DNSBLs and RBLs, which is the actual working technical analogue to your "filtered address, blocked address, blocked domains", its just the sources being filtered are not email addresses but Internet ones.
You are mistaking the recent Chrome App Store events with the Google Play Store. One is an unregulated wild wild west, the other has had problems but is far far more maintained. My biggest issue with the Play Store today is the proliferation of excessive permissions which introduces the risk of Chrome Store like badness in the future (or even now!) I generally do not accept apps that need unreasonable permissions even if I really want/need it
You are always welcome to remove the Google Play Services and the Play Store from your phone in a variety of ways. Are you REALLY upset about a 75c LICENSING FEE on a $700 phone that your likely paying for by buying into a 2-year contract with a carrier who is profiting hand over fist on you?
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!
This has *always* been the case and does not change with this announcement. Google Apps and Services are not open source and you cannot redistribute them as an Android ROM provider or OEM. Look at Amazon's line of Android devices: they have their own store and no Google store, so they get Android without any restrictions. Also the Chinese Android group, which doesn't use the Google store but has their own.
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
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.
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 d
You can, for Chrome there is the beta and dev channels. I use beta chrome which I rarely have issues with. Dev chrome is very unreliable, and it should be, since it's the latest and least tested revision of the software. For IE- well no there is only a preview for IE10 which isn't a full browser (at least last I checked) so your right there.
Wow Facebook? I haven't used Opera for a long time but I'm going to look into this. User agent sniffing is a plague and it should be dealt with accordingly. GOOD web developers don't do that unless it's absolutely necessary.
I feel your pain- Mozilla is definitely not used to this sort of release model - and yes, the amount of negativity over it is indicating that. But it's growing pains -- the whole point of having major versions is so you can progressively move bugfixes and features from the latest and most unstable version up to the stable as those become proven. I guess Mozilla's just doing a shitty job of it right now.
I am definitely not speaking to Java/Flash breaking -- and yes they *are* real web technologies. They are not GOOD web technologies, but they are still necessary. But are you saying that every time Mozilla releases a Firefox, everyone who uses Java or Flash have to go and do real work to get it working again? No, your saying that there's a chance stuff like this could break- which is Mozilla's responsibility, not ours as web developers. If it's obvious that Mozilla is going to fix the problem - eventually - then tell your users to use a different browser until then if they want it to work.
A lot of developers seem to think that their website MUST WORK at every second of every day on every browser version that someone could possibly ever try. Just write to the standards, make exceptions when necessary, and when a bug happens, don't sweat it that much- just educate your users!
Slashdot Mirror
Todays model goes much more fine grain than OSes and DBs, with component package managers a la Nuget, Bower, NPM, Composer etc. The future TFA is talking about is here already but there's no "de-emphasis of code"... If there were this hypothetical "supply chain" of vendors... What would they pass between each other anyway? Oh yeah! CODE
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
And most phones have all the horsepower and HTML engine quality to pull off a lot of the sorts of user experiences you'd like (there are still rough spots though).
The device APIs in HTML5 now cover almost all the native capabilities you would want, once ServiceWorker and push notifications are fully deployed. They actually do a -better- job when used correctly because permissions are requested as needed instead of upfront, which avoids scaring the user off as they wonder why your recipe app's update needs camera and microphone support when you add the ability for users to post a Vine video of their baked goods (for instance).
Whenever this discussion comes up, I feel like Slashdot is just filled with old crufty C++ coders who don't understand the state of the modern web, because everyone just lands flat in the "its crap" opinion instead of discussing the few missing capabilities and the specific performance issues they've seen.
The web ain't perfect (yet) but its getting better every day, and has no vendor lock in or censorship issues like the mobile walled gardens have.
Yeah, you might not want to tell people that story. If the hard drive was empty afterwards, your PHP was running as root... sure hope that PHP wasn't being run from the web server.
Yeah, this is the perfect storm of stupidity. As a system administrator, I feel like I cannot have Steam on my machine anymore.
What distribution actually has --no-preserve-root as default!?!!
...
On CentOS:
# man rm
--no-preserve-root
do not treat ‘/’ specially
--preserve-root
do not remove ‘/’ (default)
You do know that SpaceShipTwo was not actually directly based on that sawmill right? You sort of talk about it like right underneath the VG logo is a wooden crank and connecting rod that drives the whole thing.
Are you trying to suggest that SpaceShipTwo should be a huge interplanetary spaceship that can reach Mars? Because firstly- we actually have never done that as a species, so its not as simple as "Oh just improve it 1%". We've designed them, but we have not built them. And the designs we have are ridiculously expensive. What would VG's business plan look like if they said "Welp, we're going to sink ALL of our money into this vehicle that can reach Mars, and we are going to make money by........... Crap bankruptcy already?" Capitalism is supply and demand, there are no businesses right now which *demand* a trip out that far. It WILL happen but we are not there today.
Secondly, do you not see the benefit of having smaller *shuttle* like vehicles that can transport us between all of the stations and vehicles that we need to build out infrastructure in space?
Yeah the "its useless" crowd on this article is full of crap. Branson has mentioned moving from successful sub-orbital "tourism" into space-assisted earth-to-earth travel, which would take less time than travel by plane. Then bump everything up for orbital flight with "SpaceShip3" or something, and VG has the potential to serve as a transportation provider to the space station (or whatever comes after it). Space tourism is just how they plan to bootstrap the company.
There are a lot of interesting developments in the space industry right now and lots of long term directions that people are working toward. There is talk of mining anything and everything, and trying to work out the logistics for how that would work. For someone to point a finger at any part of the industry and say "ITS USELESS", because they don't have the foresight to see how these pieces may one day fit together, is stupid
https://support.google.com/mai...
The best way to find this information for a certain mail provider is to include 'postmaster' in the search. Admittedly I had to click around a little to find Google's unlike most other providers where it is pretty obvious (they usually have a Postmaster Services page or something).
Good luck on your journey!
You want to block email based on the sender address? You do know that you don't need to be authorized to send a mail as another user, right? SPF and all of that does provide some protection, but there are tons of non-SPF domains out there that ham/spam could come from and any spammer can impersonate them or just use their domains for their return addresses.
And why exactly are you so perturbed at having the spam moved instead of not received. There's no benefit at all to the spammer if Google shunts their spam into a spambox. Besides, judging by the massive amount of Slashdotters here saying Google's filter is effective, sometimes too effective, do you really want to just have Google delete what it thinks is spam, and have some important mail be entirely deleted with no record of it having existed and no practical way of recovering it? No thanks. I don't think "that's what we want".
Besides, underneath the covers ALL mail delivery systems including Google's are reacting to changes to the DNSBLs and RBLs, which is the actual working technical analogue to your "filtered address, blocked address, blocked domains", its just the sources being filtered are not email addresses but Internet ones.
I see your point but its not like this is going to dramatically affect the course of the project...
You are mistaking the recent Chrome App Store events with the Google Play Store. One is an unregulated wild wild west, the other has had problems but is far far more maintained. My biggest issue with the Play Store today is the proliferation of excessive permissions which introduces the risk of Chrome Store like badness in the future (or even now!) I generally do not accept apps that need unreasonable permissions even if I really want/need it
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.
I'm glad I'm not the only one who sees the utter ridiculousness of this "news story"
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:
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 d
You can, for Chrome there is the beta and dev channels. I use beta chrome which I rarely have issues with. Dev chrome is very unreliable, and it should be, since it's the latest and least tested revision of the software. For IE- well no there is only a preview for IE10 which isn't a full browser (at least last I checked) so your right there.
Wow Facebook? I haven't used Opera for a long time but I'm going to look into this. User agent sniffing is a plague and it should be dealt with accordingly. GOOD web developers don't do that unless it's absolutely necessary.
Agreed, and I tend to be very liberal when allowing ads, because that's how these services stay afloat...
Actually no, the Chrome you are running is stored in your user directory.
I feel your pain- Mozilla is definitely not used to this sort of release model - and yes, the amount of negativity over it is indicating that. But it's growing pains -- the whole point of having major versions is so you can progressively move bugfixes and features from the latest and most unstable version up to the stable as those become proven. I guess Mozilla's just doing a shitty job of it right now.
I am definitely not speaking to Java/Flash breaking -- and yes they *are* real web technologies. They are not GOOD web technologies, but they are still necessary. But are you saying that every time Mozilla releases a Firefox, everyone who uses Java or Flash have to go and do real work to get it working again? No, your saying that there's a chance stuff like this could break- which is Mozilla's responsibility, not ours as web developers. If it's obvious that Mozilla is going to fix the problem - eventually - then tell your users to use a different browser until then if they want it to work. A lot of developers seem to think that their website MUST WORK at every second of every day on every browser version that someone could possibly ever try. Just write to the standards, make exceptions when necessary, and when a bug happens, don't sweat it that much- just educate your users!