Transifex website, where many open-source distros and other projects host their translation environment, has made some alterations to the way traffic occurs after users log in. There are no good cookies anymore that I can trace. I had to disable adblock to be able to stay logged in.
Is this a wider trend?
When you log in to websites, what security measures do you take? Do you check/modify the headers and the referrer that your browser sends to the server? Do you take a look what headers the server replies with? Do you count the cookies? Is your browser set to erase history at close? Share your habits and tips.
Browserspy.dk (http://browserspy.dk/) (by a Mozilla fan) has been my source of insight how deeply a website can look into the browser and into the system. Plugins, history, cookies, headers, and whatnot. Not just the user agent.
Does anyone know more such websites? I don't mean a test page that crashes the browser. I mean something that informs about how your browser behaves.
If you're concerned about fingerprinting when logging in into a website where you have cookies enabled anyway, have you considered using a browser only for logins?
Keep also in mind that a browser that doesn't reveal almost nothing still can have an unique fingerprint.
Keeping and evaluating fingerprint databases means more work and expense for the website owner, something that hardly pays.
Which of the items your browser reveals, are you concerned most about? Some of those detected by Browserspy.dk can be avoided.
I'm concerned if you know of a similar website like Browserspy.dk :)
I use multiple browsers and, yes, one is so-called home browser which is basically meant to log me in to a bunch of forums and portals when I open it. In addition to a home browser, I have the so-called system default, most prominently featured in menus and icons. I use the system default for random browsing usually with cookies near-completely turned off, with adblock, etc. Then I have a so-called reading browser (Opera used to have very good user CSS support for this) and more, some browsers just for the fun of trying out browsers.
I occasionally change my home browser. For example a year ago I switched from Opera 12 to Opera 11. Hopefully Otter will be able to become my next home browser.
I worry more about the convenience of managing cookies, passwords, user agents, headers, referrers etc. I worry about convenience because I want those things to be simple. Of course it would be nice when the bowser handles them safe too.
I worry more about the convenience of managing cookies, passwords, user agents, headers, referrers etc.
And for some incomprehensible reason Firefox has been making great strides toward making all that harder since version 4. :(
I'm concerned if you know of a similar website like Browserspy.dk :)
AFAIK EFF has one. It is poorer than Browserspy.dk, so I didn't bother to bookmark it.
I worry more about the convenience of managing cookies, passwords, user agents, headers, referrers etc. I worry about convenience because I want those things to be simple. Of course it would be nice when the bowser handles them safe too.
Cookies?
Most of the time I'm in private mode. If I have to enable cookies for some stupid sites, they will be gone after closing the tab.
Passwords?
I have my login cookies. I need my passwords seldom. Most of them are stored in my memory. In case of a memory leak, I have them stored encrypted on my HD.
I've never used a password manager.
User Agent?
I could fake it easily but don't see any reason for doing so.
Referrer?
You can disable it within the browser or just open links in new tabs.
And for some incomprehensible reason Firefox has been making great strides toward making all that harder since version 4. :(
I don't like the path Firefox is going but with a few extensions it stil comes closest to Opera Presto.
@ersi, this should be interesting in this case:
https://github.com/Emdek/otter/issues/27
Although so far there is no progress on that topic, expect standard disabling of referrer, user agent switching (what about an option to set random one for each request?) and cookie policies.
Let's hope something good will come out of it, Emdek :)
In year 2001 or so, when WAP-browsing with the mobile phone given to me by my employer, I landed on http://wap.gemal.dk/ along with its WAP version of Browserspy. It was one of the first foreign WAP sites I ever visited. This is how I found Browserspy.
Cookies?
Most of the time I'm in private mode. If I have to enable cookies for some stupid sites, they will be gone after closing the tab.
A few years ago private mode did not even exist and I'm still uncomfortable with it. I can't figure out how it could be useful. Blocking cookies used to be common sense. However, blocking all cookies prevents logging in to forums and such.
What I'd like to see is a "preserve" option for individual cookies, like in Dooble browser. It should work like pin tabs. When you pin a tab, then "Close all tabs" won't apply to those tabs. Similarly, preserved cookies would be exempt from "Clear all cookies".
Dooble is pretty private, by the way. You can't even use it properly without creating a master password for it first.
Passwords?
I have my login cookies. I need my passwords seldom. Most of them are stored in my memory. In case of a memory leak, I have them stored encrypted on my HD.
I have not found any user-friendly way to encrypt stuff selectively. Looks like the best way is to install the entire opsys encrypted in the first place. The worst problem with encryption is that you still need a password for un-encryption and this password is of course not encrypted anywhere. Just like master password in some browsers. FF removed its master password option lately, I have heard.
I've never used a password manager.
I do. I have never synced passwords over cloud though. This idea always sounded kind of spooky.
User Agent?
I could fake it easily but don't see any reason for doing so.
Not so long ago e.g. bank websites outright demanded fake user agents.
Referrer?
You can disable it within the browser or just open links in new tabs.
Along with cookies, referrer is the thing that enables you to browse around forums and such. It suffices to send some kind of referrer, any kind really, but what most browsers tend to do is to send exactly the last visited page. Privacy expert QuHno for example thinks the best idea would be if browsers send to the requesting server its own domain - just the domain part https://vivaldi.net/forum/browsers/70-improving-your-favorite-web-browser#1592
In Elinks the referrer can be customised to anything. I can type BillGatesForPresident.com if I want.
A few years ago private mode did not even exist and I'm still uncomfortable with it. I can't figure out how it could be useful. Blocking cookies used to be common sense. However, blocking all cookies prevents logging in to forums and such.
In my understanding it means as much as starting a separate session (akin to opera -pd /tmp), except within your regular environment.
What I'd like to see is a "preserve" option for individual cookies, like in Dooble browser. It should work like pin tabs. When you pin a tab, then "Close all tabs" won't apply to those tabs. Similarly, preserved cookies would be exempt from "Clear all cookies".
Dooble is pretty private, by the way. You can't even use it properly without creating a master password for it first.
Note that the arrival of site preferences in Opera 8 made some people decide to browse around with, instead of
new page and
close page,
new page & disable javascript and
close page & disable javascript.
I don't know how usable the 2014 web would be with it, but if your suggestion were implemented, one could do something like
close/new page & disable javascript & clear all cookies.
I don't know how usable the 2014 web would be with it, but if your suggestion were implemented, one could do something like close/new page & disable javascript & clear all cookies.
And what sense does it make?
With any decent browser you can enable/disable scripting/cookies on the fly. It takes a single click.
You have to enable cookies but don't want to keep them, simply enable cookies and open a new private tab/window. You can do it with any decent browser. After closing the private tab/window, cookies are gone.
Privacy expert QuHno for example thinks the best idea would be if browsers send to the requesting server its own domain - just the domain part.
My lokal filtering proxy can do that but I don't use that feature because of 2 reasons:
1. This would be a very unique behaviour of my browser any admin could easily detect.
2. You will get access denied to some resources if the referrer isn't the one it is supposed to be (main_domain.com/blablabla/).
Some admins don't like their resources to be hot linked.
Simply open new links in new tabs and the privacy issue with referrers is solved.
And what sense does it make?
With any decent browser you can enable/disable scripting/cookies on the fly. It takes a single click.
That's rather the point. If you prefer to browse with these things off but occasionally want to enable them, you could either keep toggling things manually and risk forgetting or you could automate the process.
You have to enable cookies but don't want to keep them, simply enable cookies and open a new private tab/window. You can do it with any decent browser. After closing the private tab/window, cookies are gone.
And why on earth would you want to perform fifty extra steps every single time if enabling these things is the exception? ;) Besides, private window has other consequences like no history.
And what sense does it make?
With any decent browser you can enable/disable scripting/cookies on the fly. It takes a single click.
That's rather the point. If you prefer to browse with these things off but occasionally want to enable them, you could either keep toggling things manually and risk forgetting or you could automate the process.
It's rather hard to forget since you have the settings on your address bar. :)
Automating the process? Which process? Sometimes you want them on, most of the time off.
And why on earth would you want to perform fifty extra steps every single time if enabling these things is the exception? ;) Besides, private window has other consequences like no history.
First of all there aren't 'fifty' steps, just two. A mouse gesture and a click. Aside of that it happens seldom since it is rather an exception. Most of the time I'm with scripting and cookies off.
It's rather hard to forget since you have the settings on your address bar. :)
Automating the process? Which process? Sometimes you want them on, most of the time off.
So you're exactly the kind of user this should appeal to. I'm not really sure what your objections are anyway. No one's forcing you to alter your keyboard shortcuts. :P
First of all there aren't 'fifty' steps, just two. A mouse gesture and a click. Aside of that it happens seldom since it is rather an exception. Most of the time I'm with scripting and cookies off.
The charms bar is also just a gesture away. Any argument along those lines will fall on extremely deaf ears on this end. I want everything to take as few actions as possible. If I wanted to perform meaningless chores I'd use a typewriter.
PS I browse with first-party cookies and JS enabled. I've found it rather obnoxious to do otherwise these past few years. When I want to do without I typically prefer to use Elinks or Netsurf instead.
Browser security paranoid privacy panic
Well, that's what I get if trying to access DnD Sanctuary using TOR Browser:
Error 403
We're sorry, but we could not fulfill your request for / on this server.
You do not have permission to access this server. Before trying again, run anti-virus and anti-spyware software and remove any viruses and spyware from your computer.
Your technical support key is: 25dc-233d-2b02-1b1f
You can use this key to fix this problem yourself.
If you are unable to fix the problem yourself, please contact the WEBMA5TER and be sure to provide the technical support key shown above.
Strange things happens when you want to be anonymous.
Google is very pervasive/invasive. I have Seamonkey where cookies work, I think, the way I want, site-specifically. I log in to a Google Mail account there, but otherwise I keep cookies blocked. Still other Google sites, such as YT and Maps, invite me to log in with that account, even though I never open those sites up in the same tabs. Eery.
Looks like when you want to keep different sites apart, you have to actually use different browser profiles. Cookie management is not enough.
Basically, a sure way to test the privacy of a browser is to try it on different Google sites and see if you are getting recognised.
Strange things happens when you want to be anonymous.
I assume it's an attempt to limit spam.
As for anonymity, we all know that you are Belfrager from Portugal. :D
I log in to a Google Mail account there, but otherwise I keep cookies blocked. Still other Google sites, such as YT and Maps, invite me to log in with that account, even though I never open those sites up in the same tabs.
What difference does another tab make? In case you mean a private tab, try to open a private window instead and see what happens.
I can't test myself since I have no account at Google.
I was always reluctant for site-specifically cookie management. Switching cookies on, where I need to and blocking them otherwise all the time.
What difference does another tab make?
For cookies apparently no difference.
In case you mean a private tab, try to open a private window instead and see what happens.
And why it should matter when the new tab says "private"? Can cookies read? Even if they can, why would they obey?
I was always reluctant for site-specifically cookie management. Switching cookies on, where I need to and blocking them otherwise all the time.
I keep cookies that keep me logged in to sites. Therefore site-specific cookies. Otherwise I don't care about cookies. I thought that by keeping only necessary cookies and blocking the rest would be good enough, but looks like cookies have a way to talk to each other in the cookie tin. This is a very good reason for further security paranoid privacy panic.
If you're logged into a site (non private tab) and open a new private tab and then visit the site you are already logged in, the site shouldn't have any chance to recognise you. At least not through conventional cookies. There is no magic, except the browser has a flaw.
So if you are logged into gmail (no private tab), you can visit YouTube in a private tab without Google knowing exactly who you are. I say 'exactly' because of the same IP number you'll have. Even with a static IP number they can't tell for sure.
Cookies between normal and private tabs aren't shared.
You could easily find out if Google recognizes you through conventional cookies and in case it does you could figure out what you're doing wrong.
It would be more helpful than panic. ;)
I'm not really panicking. Just trying to figure out how browsers work. For example:
Cookies between normal and private tabs aren't shared.
This sounds reassuring, but I am not sure this is the standard for private tabs. Private tabs are an invention I never understood. What are they supposed to do? Why should cookies between
any tabs be shared, unless I open a link from one tab in a background tab?
You could easily find out if Google recognizes you through conventional cookies and in case it does you could figure out what you're doing wrong.
This is precisely what I figured. To test the security of a browser I can log in to Gmail and then browse other Google sites in other tabs and see if Google offers logging in with the Gmail account. However, it's precisely a test for the security of the browser, not a test of me doing something wrong. Why should the cookies and perhaps scripts etc. identify me when I open different domains in separate tabs? ('Separate' meaning that the other tab is not opened by clicking a link in the first tab.)
This sounds reassuring, but I am not sure this is the standard for private tabs.
You don't have to be sure. All you need is to test yourself. :)
Why should cookies between any tabs be shared, unless I open a link from one tab in a background tab?
By shared I mean your settings for cookies are shared!
If you set them to be enabled it doesn't make any difference how many tabs you will open. Your cookie-settings apply for all open tabs.
Gmail's cookie is a Google cookie that probably covers all Google domains.
The browser can't do anything about it. You have put that cookie in your permissions and now you wonder that Google recognizes you.
wouldn't a extension like 'Ghostery' go a long way in stopping most of this?
wouldn't a extension like 'Ghostery' go a long way in stopping most of this?
Ghostery and Adblock, as companies, make money by collecting and sharing (selling) information on what people like to block. Otter's adblock is also vulnerable to this, because its adblock files get updated automatically in the background without notice, and I have seen my customised adblock files vanish several times when updating Otter. This part of Otter should be re-built. The files are okay, but the way they get parsed and updated is not.
Anyway, here's a DNS spoofability test I found https://www.grc.com/dns/dns.htm
Enjoy the test.
wouldn't a extension like 'Ghostery' go a long way in stopping most of this?
Ghostery and Adblock, as companies, make money by collecting and sharing (selling) information on what people like to block
really? i couldn't find anything like that in these privacy statments, do you have a link i can read about these extensions lieing to us?
Ghostery's privacy statement:
https://www.ghostery.com/en-GB/privacy-addon (https://www.ghostery.com/en-GB/privacy-addon)
in AdBlock's FAQ:
Your browser may require AdBlock to ask for permission to access your browsing data so it works on all tabs in your browser. AdBlock won't save or retrieve your personal browsing habits or information for any reason beyond what is required to make it work. AdBlock is entirely supported by voluntary donations from users like you, and collects no information for advertising or promotional purposes.
in AdBlock Plus's FAQ:
Adblock Plus stores some data in the Firefox profile on your computer. Adblock Plus never transmits this data to any servers, but other extensions and services, such as Firefox Sync, may do so. Most of the data (your preferences, filter subscriptions and custom filters) is unobjectionable privacy-wise. However, filter hit statistics and recent issue reports could be used to reconstruct your browsing history. Adblock Plus treats this information identically to how history data is treated by the browser: this data isn't stored if you are using Private Browsing mode and is removed if you choose to clear your browsing history.
Ghostery Makes Privacy Marketable (http://www.informationweek.com/software/social/ghostery-makes-privacy-marketable/d/d-id/1317687)
The anonymized data Ghostery receives if users choose to opt in to its GhostRank service turns out to be valuable to businesses....
Ghostery then sells the data to clients such as Proctor & Gamble so they can better understand how their online marketing efforts are working or failing. If lots of Ghostery users are blocking a particular service, that might be a sign to work with a different provider or to take a different approach.
Now, that the monetizable data is obtained exclusively via GhostRank and not via other aspects of Ghostery is a plain claim, subject to falsification. If I had the time, maybe I would look closer at the code in Ghostery to dis/prove it, but it's so much easier to simply live without Ghostery. This claim is directly inviting a verification.
And Adblock's autoupdating is also the classical "calling home" issue. I have not cared to monitor my data traffic with minute precision, but there are many reasons why I don't like autoupdates.
i suppose its a catch 22 situation really, you install ghostery to stop ad companies tracking your browseing habits and maybe it sells your data to a company to help them not be tracked so it gets through ghostery and on to your page.
i might of installed the android ghostery browser on my tablet, but only as its a great light-weight program, i'm more concerned having a good adblocker realy, so whoever has my data has no way of using it on me for personalised ads .
have you tried out electronic frontier foundation's 'https everywhere' addon? and is it worth a try?
have you tried out electronic frontier foundation's 'https everywhere' addon? and is it worth a try?
I remember I have thought about it on PS, but not on Android. I have not tried it though. I was reading about Tor and HTTPS Everywhere at the same time. I gave a try to Tor.
I still think that urlfilter.ini type of thing is best. Adblock works most closely this way.
have you tried out electronic frontier foundation's 'https everywhere' addon? and is it worth a try?
I remember I have thought about it on PS, but not on Android. I have not tried it though. I was reading about Tor and HTTPS Everywhere at the same time. I gave a try to Tor.
I still think that urlfilter.ini type of thing is best. Adblock works most closely this way.
The Tor browser is great, downloaded it a little while back for windows, I don't have windows anymore though but I'm sure it featured https everywhere in the addons
var addthis_config = {"data_track_addressbar":true};Question #1: What is this code (found in a website) meant to do?
Question #2: Should it do it?
Adress bar sharing analytics (http://support.addthis.com/customer/portal/articles/381254-address-bar-sharing-analytics)
Mkay. Reading some on that thing called History API.
MANIPULATING HISTORY FOR FUN & PROFIT (http://diveintohtml5.info/history.html)
Why would you manually manipulate the browser location? After all, a simple link can navigate to a new URL; that’s the way the web has worked for 20 years. And it will continue to work that way. This API doesn’t try to subvert the web. Just the opposite.
What follows is unintelligible nonsense.
So, to answer my question #2, whatever that thing does, it should not do it.
Anyway, here's a demo to see if History API is available in your browser http://html5demos.com/history
In all browsers I used to load the URL with JS turned on, I got the text "HTML5 History API available", even in Opera 11.6*. Looks like one more reason to keep JS turned off.
What follows is unintelligible nonsense.
Actually the history API is quite nice because it allows JS to use pushState to stick in a
regular URL while still using JS. When done right there should be very little difference between with JS and without JS, except that with JS should be slightly faster. Of course, it's seldom done right… :P
What the History API has to do with #whatever of ?something=whatever is their secret. I can only imagine it makes some particular use case the tiniest bit simpler to write. In this case they're suggesting not using links like this (https://dndsanctuary.eu/index.php?topic=696.msg36472#msg36472) because they'd prefer to stick tracking data in there. Meh, bunch of weirdos.
Thanks for trying to take time to explain and analyse History API, but I honestly see no valid use case. Based on the website I found, there can only be evil-minded use cases, and I won't waste time trying to deconstruct them. Just avoid them.
We use Trello (https://trello.com/), which seems to be using that API. It's very nice to open tickets without reloading the whole page, while getting a valid URL that links to that ticket, which can be bookmarked or shared with other members of the team.
Yup, exactly. :up:
Wasn't "without reloading the whole page" option supposed to be handled by the way browsers manage cache? E.g. in Opera you can timeset how often the same pages/images get rechecked.
I still don't see the point with History API. And in particular I don't see why JS of webpages should read the address field. Isn't the referrer header enough?
Edit: As of today, I have begun to take a closer look what's going on in tcpdump. Pretty interesting.
When the whole page is a huge panel with lots of information about many tickets, and I just want to see details about a handful of them, with very little changes to the contents of the main panel, and with the option to go back in history and revisit some tickets I've seen last, then the History API is quite handy. Cache control (exclusively) wouldn't work so good.
Wasn't "without reloading the whole page" option supposed to be handled by the way browsers manage cache? E.g. in Opera you can timeset how often the same pages/images get rechecked.
The use case is the same as for frames. Except frames actually had the exact same issues with bookmarking that XMLHttpRequest originally did. And of course you might reload only a minuscule part of the page because you have a kind of fine-grained control that frames never did. Actually this forum does that as well if you edit your message in place or when you use preview, except that in our case the URL you're on never changes. It should be more efficient for every step of the chain: the server has less work generating things, the transport has to transmit less data, and your browser in turn has to redraw less. That last part only really works out when you don't load over 1 Megabyte in scripts like, say, Twitter. :P
I still don't see the point with History API. And in particular I don't see why JS of webpages should read the address field. Isn't the referrer header enough?
Web pages have been able to read and write the URL through window.location/document.location since forever. The History API enables adding a URL to the history without ever causing a reload. The thing is, the particular use case on the earlier article wouldn't cause a reload either because it uses #blabla. That's a simple matter of window.location = window.location + '#trackerstuff' and it wouldn't ever reload. That's why websites like Gmail still use annoying URLs like
mail.google.com/mail/u/0/#inbox/14ba2476f4b7b0bd, although these days it would work just as well without the pound sign. As far as I can tell the History API tracker shtick is a bunch of hooey and all of this has been possible since IE4-ish.
Now window.location = window.location + '/someplace-else' — that would cause a reload. Whereas with the History API you can simply switch out a part of the page and tell the browser you're now on '/someplace-else'.
At least we seem to agree that the tracker thing is pointless and probably evil. As to the rest of the functionality, reloading but only the necessary part as if in frames (if I got it right) and putting things into the browser history you may want to have there, sounds like you are talking about some Web2.0 sort of pages. They are inaccessible without JS, right? in which case they hardly justify their own existence.
As for tampering with the browser's history, this has always been a privacy concern. Seems like it's not the browser who is recording the history of visited pages, but websites reading from and writing into browser history. This would be okay only in a very limited sense - allow the current content of the address field be written into browser history. Nothing more. Evidently, websites have always been able to sniff out more.
And I think I see now what browser vendors meant when they were advertising the novel truncated URLs. This way the security junk like #-and-gibberish and other such stuff administered by webpages remains invisible to the users and everybody will be happy because the world is oh so safe.
They are inaccessible without JS, right?
I think Web 2.0 is just a stupid marketing term. However, that depends on what it is. A site like Twitter now actually works fine with and without JS, but in the pre-History API days you couldn't have URLs that worked both ways. Now I wouldn't call Twitter a good example overall — it seems to be extremely heavy for what little it does — but it definitely became a better site because of the History API.
but websites reading from and writing into browser history.
If websites can obtain information about history it's a security bug (like the visited link color issue in the past). The History API only allows a website to silently change its URL without adding a new history entry (I struggle to think of a use case for that…) and to silently change its URL while adding a new history entry.
I think Web 2.0 is just a stupid marketing term.
Yes, it's a marketing term, but not merely stupid. It poses dangers.
If websites can obtain information about history it's a security bug (like the visited link color issue in the past).
Precisely on topic.
The History API only allows a website to silently change its URL without adding a new history entry (I struggle to think of a use case for that…)
There is none. You can stop struggling now.
...and to silently change its URL while adding a new history entry.
And when there's no History API, websites cannot add a new history entry?
Let's try to flesh out an example that I can understand. Trello.com was mentioned. I am more familiar with the way Github looks (even though not familiar how its code interacts with browsers).
Let's say I'm staring at the list of Otter's issues and someone publishes a new issue at that very moment. Github pushes (by means of JS) the new issue into the browser display, kindly taking care that only the newly published issue emerges while none of the rest of the page gets refreshed.
Questions: How is this dependent on History API implementation in the browser? Doesn't it purely depend on JS as such? What does this have to do with the ability to write into browser history? How is this different from ordinary refresh? At ordinary refresh the URL does not change, obviously. With or without refreshing (JS on or off), my staring at a single page should not change the URL in the address field, should it?
Another case. Let's say I am staring at the comments thread of a specific issue in Github. The right-hand column and the top bar of the webpage are common no matter which issue I look at. Let's say I open up a different issue. The comments thread now has different content, while the right-hand column and the top bar are the same. If I understood rightly, the awesome History API kindly prevents the browser from re-downloading the right-hand column and the top bar while I switch to comments under a different issue.
Questions: Is there anything in this use case that is not meant to undermine the purpose of browsers' handling of cache? Browsers are supposed to handle cache this way (correct me if I'm wrong):
- Update (re-download) only the stuff that is not found in cache or that is expired.
- Don't update the stuff that is found in cache and that is not expired.
- The stuff is identified by URL's, e.g. when a specific image (with a specific URL) is displayed on multiple webpages, the image is drawn from cache, while the rest of the page is drawn over the web.
- Expiration is determined as per browser and website settings, where browser settings should have priority.
This is how it should work in ideal, right? (I know it doesn't in reality, but let's keep to the standards for now.) How is it supposedly better when something called History API should do this work in interaction with the website's JS? What are the improvements over browser cache? And again, what does this have to do with the ability to write into browser's history?
"Stuff" is identified by URLs. But there's another way to understand them: information is identified by URLs. If I've got some information from the web, then there can be a URL that identifies it. If it can be cached, the better. The next time I visit that URL, if it is in cache and valid, then there's no need to download it, otherwise it will be downloaded - at least the first time. In either case, it's possible to check in History that I've already seen that information (i. e. URL) before (no matter if those files are in cache, which is an internal browser issue).
"Stuff" is identified by URLs. But there's another way to understand them: information is identified by URLs. If I've got some information from the web, then there can be a URL that identifies it. If it can be cached, the better. The next time I visit that URL, if it is in cache and valid, then there's no need to download it, otherwise it will be downloaded - at least the first time. In either case, it's possible to check in History that I've already seen that information (i. e. URL) before (no matter if those files are in cache, which is an internal browser issue).
And is it the website that should check your history and cache to determine what content to push on you, or is it the browser that should check its own history and cache against the website and determine what to download?
Github pushes (by means of JS) the new issue into the browser display, kindly taking care that only the newly published issue emerges while none of the rest of the page gets refreshed.
That shouldn't have anything to do with the History API. At no point in time do you leave the page https://github.com/OtterBrowser/otter-browser/issues. But when you navigate away from that page to https://github.com/OtterBrowser/otter-browser/issues/731 — that's when the History API comes into play. In both cases the site uses XMLHttpRequest to update part of the page, but it only makes sense to behave as if you loaded another page in the latter case in order to preserve linking, bookmarking & back/forward functionality.
Questions: Is there anything in this use case that is not meant to undermine the purpose of browsers' handling of cache? Browsers are supposed to handle cache this way (correct me if I'm wrong):
- Update (re-download) only the stuff that is not found in cache or that is expired.
- Don't update the stuff that is found in cache and that is not expired.
- The stuff is identified by URL's, e.g. when a specific image (with a specific URL) is displayed on multiple webpages, the image is drawn from cache, while the rest of the page is drawn over the web.
- Expiration is determined as per browser and website settings, where browser settings should have priority.
Dynamic pages (like this forum) are always changing, so their content will seldom be cached. Only static resources like CSS, JS, and images are effectively cached. On this website it doesn't matter much one way or the other, but on high-volume websites like Twitter or Github a slight reduction in CPU time and a more tangible reduction in transfer size can add up really quickly. Every time you load a page on this forum, you're loading at least 16 kB of header and footer stuff that might just as well have remained static. Simply put, the user will probably profit and the server will definitely profit. (Forgetting for a moment that the user will also benefit from a lesser server load.)
You're right to note that a dynamically generated https://github.com/OtterBrowser/otter-browser/issues/731 won't be cached unless it's on the first load. On the flipside, if you're browsing around Github the results of the XMLHttpRequests
can be cached (I don't know if they are; it depends on what the HTTP headers say). So it's perfectly conceivable that the page https://github.com/OtterBrowser/otter-browser/issues/731 would be cached in two different ways: once as a full page and once as a partial page request.
And is it the website that should check your history and cache to determine what content to push on you, or is it the browser that should check its own history and cache against the website and determine what to download?
The browser. The website doesn't push anything, AFAIK.
For pushing there is a special protocol, thanks to Google. It's called SPDY.
Courtesy of Google we will soon have HTTP3 to upgrade/replace the HTTP protocol and Quic to upgrade/replace the TLS protocol. Here's a thorough overview:
https://www.youtube.com/watch?v=cdb7M37o9sU
The discussion of the security aspects begins at 26:18. The main point is that firewalls will become obsolete. The new protocols have an all-at-once approach where there's no picking and choosing any secure or insecure elements. Rather, it seems that the entire protocol needs to be trusted wholesale for the connection to work.
For consolation, the protocol implements its own security features currently carried out by firewalls. The protocol was invented at Google so you can rest assured :)