"We added the X-Content-Type-Options: nosniff header to our raw URL responses way back in 2011 as a first step in combating hotlinking. This has the effect of forcing the browser to treat content in accordance with the Content-Type header. That means that when we set Content-Type: text/plain for raw views of files, the browser will refuse to treat that file as JavaScript or CSS."
I think the author should warn people "If you're a big enough asshole, I will make your website look amusingly awful and submit it to Reddit and Hacker News." Making someone look like a complete idiot in public can be a powerful disincentive.
Actually, it was an alert() box plus evil.js, which overwrites lots of native JS functionality to intentionally cause weird bugs.
The idea is to make it impossible to ignore so abusers will stop their hotlinking. I'm not really interested in shaming anyone, though. I think it's usually just a simple mistake where someone was lazy and didn't bother reading all the caveats.
I'm sure there's a legitimate reason, but I've always wondered why you can't just set master as your GitHub Pages branch if it made sense (rather than gh_pages).
I launched rawgithub.com before GitHub announced their official policy discouraging projects from using "github" in their name. I really, really liked the simplicity of just deleting the dot in "raw.github.com" to get a rawgithub.com URL.
I've tried to make it very clear that rawgithub.com is in no way endorsed by or associated with GitHub in the hopes that there won't be any confusion, but naturally I'd change the name if GitHub asked me to. I definitely don't want to tromp on their trademark.
Since Mr. Grove (and by extension, his website) is based on USA, it is eligible to be sued (in fact they have to protect their copyright or risk rendering it de-facto invalid).
Yes, but protecting their trademark in this case is allowed to be, "Hello, we need you to license our trademark if you are going to use it. We won't charge you. Please e-sign this short and not overly lawyered document."
That is a "naked license" and would likely result in github losing their trademark, as they would be abandoning it by not controlling the nature and quality of services provided by the licensee. (SFW: http://www.ivanhoffman.com/naked.html)
This is great, I have some JSfiddle examples that I share occasionally that reference some raw files an Github, this fixes them in Chrome. Seems like the perfect use case for this.
The site's FAQ admits that it'll engage in what is basically a man-in-the-middle attack against content that receives heavy traffic, for instance. See the "rawgithub.com will start serving evil.js and evil.css instead of requested JS and CSS files" part of one of the answers.
If the content being served will be modified in some cases, is there really anything preventing it from being modified in a different (perhaps more malicious) way in some other cases?
Like anything else, a service like this is itself susceptible to breach, of course. There's always the potential that it gets compromised, and starts acting in a malicious manner, initially undetected by its creators/operators/users.
Some may argue that this is acceptable risk for content served up for demonstration purposes. I'm not certain that's necessarily true. A demo being unexpectedly modified in a harmful way (racial slurs inserted into a web site's text, malicious JavaScript being injected, and so on) could seriously affect the demo giver's reputation, for example.
It's not difficult, nor expensive, to set up your own publically-facing web server. If already using GitHub, git makes it quite simple to fetch and update any content being served up. While there is still risk associated with such a setup, you are cutting out at least one other party by doing things yourself, avoiding the harm they could potentially cause. So services of this type seem quite unnecessary, and perhaps more of a risk than they're worth.
I first thought he meant it was a horrible idea for the owner of RawGithub.com: serving arbitrary JavaScript. But that shouldn't be a problem as long as long you use a completely separate domain and never care about cookies.
As for the users of the service: it's not any less secure than running JavaScript from any other web server. You can of course never trust that it's serving the correct data, but I don't see how that's horrible security wise. If you're going to demo it yourself you can easily clone the repo yourself (or setup gh-pages). This is for users who want to quickly check out someone else's repo without cloning it.
A lot of this complaint also applies to raw.github.com. Much of it applies anyone who provides an online service of any sort.
> If the content being served will be modified in some cases, is there really anything preventing it from being modified in a different (perhaps more malicious) way in some other cases?
Malicious modifications would be unethical and possibly illegal. Malicious modifications would also likely make customers who noticed them abandon the service and tell the world about the situation. Of course, these facts would only stop the service providers if they care about ethics, legality, retention or reputation. I'm assuming that this particular service provider does, because the Github repo where the code is hosted mentions the author's real name [1].
[1] Whether someone reveals their real name isn't a perfect test of malicious intent [2]. A malicious provider might make up a fake name to build trust, and many people -- myself included -- lack malicious intent, but prefer to remain anonymous.
[2] A perfect test to tell whether an RFC-compliant web service is malicious is to test the evil bit, as specified in RFC 3514. To quote from it, "Benign packets have [the evil] bit set to 0; those that are used for an attack will have the bit set to 1... An application/evil MIME type is defined for Web- or email-carried mischief."
This service is all about work-in-progress and demo projects. Just to show it off for a quick demo or whatever. You're completely right, but also missed the point of this tool completely.
I've done a similar project GitHub HTML Preview, which allows you to run any HTML & JS & CSS without using GitHub Pages or downloading a repo: http://htmlpreview.github.io
It's a well-known issue in Chrome for Windows. The latest version of Chrome's rendering library (Skia) now supports DirectWrite and they intend to include it in their Blink engine.
It renders horribly for me as well. On that note, how does one properly implement custom fonts into a webpage? Is there a standard, recognized, fool proof way? I've rarely seen it done correctly.
On that note again, where do I learn about fonts in the browser in general?
There's sort of a standard way. But really no. It's one of those situations where if you're going to use custom webfonts and aren't using a service you'll need to go through some trial and error, do some research, and basically decide which platform/browser combo is most important to you. The second most popular post on my website discusses this. Not trying to self-promote and there are problems with my implementation too but maybe this can get you started http://billpatrianakos.me/blog/2012/12/26/fix-webfont-render...
https://github.com/blog/1482-heads-up-nosniff-header-support...