Sounds too good to be true, but also brilliant. Curious what others think. What are the downsides?
I'd surmise the author is benevolent, but if this were to be turned into a business, some kind of data play seems like the trivial next step.
111–120 of 361 posts
Sounds too good to be true, but also brilliant. Curious what others think. What are the downsides?
I'd surmise the author is benevolent, but if this were to be turned into a business, some kind of data play seems like the trivial next step.
Many people browse the web from an employer who has rules about what types of pages may be accessed. For example, a person applying for a job with my team may include a link to a web page about their job-related background -- portfolio.html or whatever. HR tells us to be sure we don't follow links to any other page that may be more personal in nature, such as a page that reveals the applicant's marital status (which…
Jesus. I hope they pay you well for that. I've heard a lot of stories of ridiculous rule-by-HR culture, but that's so extreme it sounds made up.
Of course, had I known about these practices in advance, I would have declined the job offer. But I didn't. I ended up quitting a few weeks later anyway.
IT would monitor all connections from all employees and send a report to upper management with summary statistics, on a monthly basis.
I was told this was the case by a fellow worker during my second day there, so I tunneled my traffic through my home server via SSH. When IT asked me why I had zero HTTP requests, I reminded them that monitoring employees traffic was illegal under our current legislation. Doing this in a university-like non-profit research center is hard to justify.
Earlier quoted context omitted.
> What about poorly-coded websites/apps where GETS are not idempotent or have side-effects? They're already broken, exposing that is a good thing.
Breaking the web is not a good thing. Regardless of how you think things should be done.
Perhaps this something that a browser should be doing, instead of websites themselves?
Earlier quoted context omitted.
No! You should NEVER load javascript over https on a page that was served over http. It gives a false sense of security that doesn't exist. Because the source page was served over http, the source page can be modified by an attacker, making the script be loaded under ssl makes you think its protected. But its not since an attacker could just modify the script tag to remove the https bit in transit then modify the scr…
Or just stop using HTTP like a normal person. Who still has pages served over anything hit HTTPS?
I looked (quickly) through most of the comments below and couldn't answer these questions: 1) What, if anything, is the downside here? 2) Is (Google) analytics effected by the prefetch? That is, does that get counted as a page visit if the link that triggers this prefetch is not actually clicked? Tia
The downside is that your pages’s HTML are loaded twice as much, this makes for additional load on your server. Client-side analytics like GA aren’t affected.
Earlier quoted context omitted.
I think it would only prefetch GET links, which never have side effects.
You're typing this comment on a site that has a GET link to logout.
I've been testing it for the past 30 minutes or so and found that it doesn't cause the same problems that InstantClick did. (Which was javascript errors that would randomly occur.) I'll limit it to a small subset of users to see if any errors are reported but there is a good chance this could go live for all logged in users. Maybe even all website visitors if all goes well. Seems to have no impact on any javascript,…
Logout links should never be GETs in the first place - they change states and should be POSTs.