homakov

Does it rely on a service to log you in with same email that you provide? Because normally services don’t do that. They suggest you to attach new apple account to old account with that email, but allowing outright logging in would be very bad practice.

Whenever I click "it's spam & unsubscribe" i often keep getting more emails.

Then I started clicking "block this address" from another drop-down - never got any new mail. Much recommended approach.

one design problem https://medium.com/@homakov/catch-22-of-lightning-network-in...

A truly valid problem. Myself i don’t like online communications with friends. It only makes me feel worse. it feels so incomplete and awkward. In person our convo is flowing much better

Why there is no sort by rating like on Reddit? I’d prefer reading top comments, not random of 1600

Basically better node by creator of node?

Have a look at data: URI technique we developed to avoid Apple/App Store altogether for critical apps:

https://coins.github.io/secure-bookmark/

None of the bugs is critical, not even medium severity.

Surprise, you don't need hacker one to get reports. sendbugshere@company.com solves the same issue without introducing a new trusted party.

Google Flights as my go-to option. Unparalleled speed, can iterate over 10 days with click of a button.

How about <img> on the page of the victim that triggers some CsRF with GET

Ok I can agree with that. This must definitely be discussed in rails/rails and fixed by design. I probably overplayed my concern with browsers.

> The only reason this bug existed is because Rails treated HEAD as GET in some cases but not others

It is the main reason, yes, but not the only reason. If it wasn't possible to craft cross-site HEAD (which devs use in real life like.. never?) the bug would stop right there.

With an extra method if-else logic turned faulty. I would argue 90% web devs don't even remember of HEAD and what it means. Reasonably so, because it's rather never used.

IMO order of blame: 1) rails 2) browsers 3) github code relying on .get?

> HEAD isn't turned into GET, it's routed the same as a GET request

Pardon my poor wording indeed, I intended to mean this too.

For a client side code running on 3rd party page, there is no use case to let it send HEAD to you. Only GET and POST should be allowed by default, other methods only through CORS preflight. That was the premise of CORS. They broke it.

> I wonder if Rails will fix the default implementation of handling HEAD requests

It absolutely should. Nobody expected Rails to covertly turn HEAD into GET. It must be explicit "get_or_head" method in routes.rb

There was no proxy view-source:https://not-an-aardvark.github.io/oauth-bypass-poc-fbdf56605...

  const authUrl = `https://github.com/login/oauth/authorize? 
  client_id=${CLIENT_ID}&scope=read:user&authorize=1`;
    fetch(
      authUrl,
      {
        method: 'HEAD',
        credentials: 'include',
        mode: 'no-cors'
      }
    )

I worked a lot with client side bugs earlier, and clearly this trick has crossed this line. Browsers cannot say in one scenario that "content-type:application/json" are unsafe and in another allow completely unnecessary HEAD method that nobody ever used to be sent with 3rd party JS page.

Seriously who needs HEAD in their client side development? It's purely a technical method w/o clear use pattern. It's not even valid in <form method=""> so why would it be valid in fetch()? Oh and PATCH/PUT are still invalid in fetch().

We're lucky that this code pattern is only common in Rails. Otherwise it could open a whole class of bugs.

Only step 1 is important, that's where the bug is. The rest is routine to get a code for your already authorized app.

"should". Real apps are much more complicated than what they are in theory. In theory all CSRF protections must be based on an auth token, in practice they routinely rely on the method or referrer.

For this reason browser upgrades must be extremely careful to not break older protections.

That's why you cannot set your own referer (which is supposed to mean nothing), you cannot supply Content-type: application/json unless instructed by CORS preflight, etc etc.

Here, the backwards compatibility was clearly broken. It was never possible to send HEAD few years ago with regular XHR or <img>s. Web standards owe $25k back to github. Yes, github's routing was flawed but it wasn't exploitable until browsers allowed HEAD in fetch() no-cors mode.

You can't achieve a HEAD request with <img> elements, can you?

In a rails env the only way to upgrade to non-standard methods (PATCH, PUT etc) were always to supply _method and pass CSRF protection first.

This trick is clearly a bypass because it instructs browser to make a HEAD request, something it never did before. If you try to make other non-standard request you will get this error:

Uncaught (in promise) TypeError: Failed to execute 'fetch' on 'Window': 'PATCH' is unsupported in no-cors mode.

Wow, why would the browser allow HEAD request in the first place w/o explicit confirmation from github server with CORS headers. This is very strange.

It also reminded me of why "match" was removed in the first place - http://homakov.blogspot.com/2012/04/whitelist-your-routes-ma... - you could route any POST request via GET therefore bypassing CSRF checks still getting inside the controller.

A long boring read lacking arguments.

Speaking of "long analyze" have a look at my script - https://news.ycombinator.com/item?id=21420140

Airbnb reviews are practically useless. Numerous of times I've been to 10-20 good-reviewed apartments that ended up too dirty or noisy so I had to go to a hotel.

Also, for no reason Airbnb prohibits from sorting by reviews or price, so I've developed this script - it's super userful: http://sakurity.com/airbnb.js

It is a true black swan. I doubt it happens regularly enough to become a reinforcement mechanism.

What kind of amount in tax are you talking about? Is it net profit anyway compared to paying back tens of thousands?

Five is the minimum. Plus many strings attached. Few people want to wait 5 years to solve a residence problem.

What does porn have to do with sex though?

$250k. But why go this way? You're limited to live in those southern european countries. You can't live e.g. in Netherlands with golden visa of Portugal or Greece.