Nathan Manousos

Hacker News was full of posts about a security issue relating to Github and Ruby on Rails today. The story is confusing and I’m seeing some incorrect information about it. Here is a summary of my understanding of the events. I’m not casting judgement, just trying to make an understandable summary.

1. Github user homakov believes that a Rails default setting makes it more likely for Rails developers to overlook a certain security issue. He posts an issue report on the Rails repository github page explaining his concern.

2. His concern is dismissed.

3. He posts a comment on the issue which references a github issue seemingly created in the future. This is to demonstrate that the issue he raised has lead to a security hole in Github itself (which is built using Rails), which he used to post an issue with a future timestamp.

Note that this isn’t really a security bug with Rails. Rather it is a default setting that could lead a developer to create a security hole in their app. Homokov wants to alter Rails such that it is harder to make that mistake.

4. This stunt is largely ignored.

5. He tries another stunt - making a commit to the master branch of the official Rails repository. Demonstrating that he could potentially control any repository on Github. Unauthorized users should not be allowed to commit to this repository. It is a very high-profile repository, so many eyebrows are raised as a result.

This is like going to a mall that is built of Acme brand wood, which happens to have an Acme store inside. Then telling the Acme employees that their wood has a weakness if used improperly. The employees say “well, we designed that way, it’s not our fault if someone uses it improperly”. The he does a karate chop on their wall, smashing a hole in it and says, “See? even this mall where your store is located has used the wood improperly”.

A+++++

I’m just about finished building a coupon system for my e-commerce site. Customers visit a special URL that includes the coupon code. Then the coupon is applied to the order they create.

Here are some of the things I had to consider when building the feature. This is why seemingly simple features can take longer than expected.

• What is the most reasonable database structure for coupons that can take on different forms?
• Is there anyway for an attacker to abuse coupons?
• What if I issue a 50% off coupon, then a year from now I allow users to sell their own products and set their own prices, and a user sets a $10,000 markup on their own product and buys it 100 times using the coupon?
• What if a coupon results in a negative price for an order?
• What if a coupon becomes invalid after it has been applied to an order?
• What if a coupon becomes invalid right as an order is being placed?
• What if a customer adds a coupon to their order, then logs in and their account has an order in progress with a different coupon applied?
• What if showing the original price and the discounted price side by side takes up too much space and it can’t all fit?
• What if a customer tries to redeem an expired coupon? Voided? Nonexistant? Used up?
• How will a customer see that their coupon has been applied?
• How will a discount be reflected if the user updates the quantity of their order using AJAX where the total order price is calculated client-side?
• What if a customer wants to remove a coupon from their order?
• How will a discount amount be stored after the order is placed to ensure the actual discount amount is available for record keeping purposes?
• How does the checkout page change if the total price of an order is zero?
• Does the customer pay tax on an order’s discounted price or full price?
• Should the coupon code ‘freestuff’ be recognized if the user types in ‘FREESTUFF’?
• What if a customer redeems a coupon while a coupon is already applied to their order?
• How should the checkout page change if the coupon gives free shipping?
• What if a wholesale customer with a constant discount tries to use a coupon?

My friend Amit has Leukimia. The disease, and bone marrow donation have been on my mind.

According to this article from the Washington Post, it’s now legal to pay donors (provided they are using the newer, less invasive donation method).

I have long believed that there should be a market for organ donation. So this article was doubly interesting to me. Particularly this part:

“Advocates for paying donors said compensation will spur even more donations. Detractors argue that donor compensation will exploit the poor to undergo risky medical procedures to benefit the wealthy.”

To me this translates to “Detractors think poor people are too stupid to make their own decisions”.

A plantiff in the case that brought this decision, who’s daughter died of leukemia said:

“In the end, creating more and better bone marrow donor matches through a system of modest compensation will save the lives of patients, improve the lives of donors, drive down the costs of treatment and improve the quality of life of cancer patients as they battle to survive.”

He’s right, but why should the compensation be modest? This is clearly a word thrown in there to make the concept more palatable. I’d like to see the people who donate and save lives be rewarded handsomely.

I love sharing screenshots, I do it multiple times every day. I even remapped my keyboard shortcuts to make it easier.

There are several utilities for doing this. My favorite has traditionally been Gyazo. However, Gyazo places too much junk around my images (ads and such) and account management is weird. Gyazo’s pro account doesn’t use a traditional login/password approach. I don’t know how to access my account, I used to be able to.

I searched for a new tool. I looked at Grabbox, Cloud App and others. They all look really cool, but bother me for various reasons.

1. I don’t need the app to run all the time, just when I’m taking a screenshot. If you use an app launcher like Spotlight, Quicksilver, Launchbar or Alfred (as you should) then the cost of launching an app is near zero. I’d rather not have the app running all the time, taking up resources, and displaying an icon somewhere.
2. I don’t want the app to hijack my screenshot command. I’m not trying to upload every screenshot I ever take. I regularly take screenshots that I don’t want to share. I want screenshots to continue working like they always do, and I don’t want to accidentally share screenshots with private information in them. Some apps even rely on using the standard screenshot shortcuts, which I have customized.
3. I want to use the native screenshot UI. Apple’s screenshot UI is really good. It supports things like space + move, option and shift modifiers, and you can use space to take screenshots of individual windows. Apps like Skitch have their own UI for this which I’m not crazy about.
4. I want the URL of the image copied to the clipboard immediately after the upload is complete.

Gyazo is the only app I’ve found that meets my criteria. But it displays ads and other annoying stuff around images.

I talked a lot with my friend @naan about this, and realized it would be nice if I could use the Gyazo app to send images to Amazon S3 instead of to Gyazo.com.

Then I found this blog post by @cowboy describing how to modify a Ruby script within Gyazo in order to send images to your own server. The fact that this can be done with a Ruby script means I might stand a chance of figuring it out! I wrote my own script to send images to S3 instead of a normal Web server.

This is the best solution I’ve found, the best of all worlds!

If you’d like to use this technique yourself, grab my Ruby script and fill in your own S3 credentials at the top. Find Gyazo.app in your Applications folder, right click on it, and choose “Show Package Contents”, then navigate to Contents/Resources. Replace the file called, “script” with the one I provided. It’s a good idea to make a copy of the default script file first in case something goes wrong.

And let me know if you find a better way.