Rawgithub.com(rawgithub.com)
rawgithub.com
Rawgithub.com
https://rawgithub.com/
38 comments
"What will happen if im an asshole" -- that's the first time I've seen a URL anchor like that!
https://rawgithub.com/#what-will-happen-if-im-an-asshole
https://rawgithub.com/#what-will-happen-if-im-an-asshole
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.
It has happened, but the result was a more polite alert() box in a hompeage and it wasn't posted anywere.
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.
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.
Very awesome.
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'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've tried that here [1], gh-pages has replaced master as the only branch. It seems to work well [2] for the static site.
[1] https://github.com/shurcooL/latest-tweets
[2] http://shurcool.github.io/latest-tweets/
[1] https://github.com/shurcooL/latest-tweets
[2] http://shurcool.github.io/latest-tweets/
master is the GitHub pages branch for User and Organization pages.
You could also set the default branch in the project settings to gh_pages for other repos.
You could also set the default branch in the project settings to gh_pages for other repos.
I like the service, but is it OK to use the github name like this?
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.
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.
Looks like no, it's trademarked: http://tess2.uspto.gov/bin/showfield?f=doc&state=4802:zp...
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).
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.
I love it - I've been wanting this for ages. Super convenient.
Same idea with source
https://github.com/sergeykish/gisted
Read the FAQ, rawgithub's source is here: https://github.com/rgrove/rawgithub
Sounds like a horrible idea security wise.
Care to explain why?
Is it really not obvious?
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.
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.
> Is it really not obvious?
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.
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."
> 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.
This is exactly right.
Anyone who's using rawgithub.com in a situation where harm could be done by running arbitrary third-party JS is probably misusing rawgithub.com.
Anyone who's using rawgithub.com in a situation where harm could be done by running arbitrary third-party JS is probably misusing rawgithub.com.
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
Related: http://www.5minfork.com/
evil.js is just beautiful...
Couldn't come up with any other name? The site is just begging to be taken down by Github.
I needed yesterday :) Well done.
Does this font render horribly for anyone else? On windows with chrome here.
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.
https://code.google.com/p/chromium/issues/detail?id=137692
https://code.google.com/p/chromium/issues/detail?id=137692
Sorry about that. I haven't even looked at the site on Windows. Soon as I have time I'll see if I can find a font that Chrome won't mangle on Windows.
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?
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...
Why doesn't github just fix it to send the correct content-type back?
If someone can host arbitrary html and js on the *.github.com domain, they can set cookies for github.com. See http://homakov.blogspot.com/2013/03/hacking-github-with-webk...
https://github.com/blog/1482-heads-up-nosniff-header-support...