5 ms·

The entire session cookie to validate your login. Unfortunately there is no other reliable way to do.

gruez 6y ago
That sounds dangerous. By sending the full cookie you're allowing yourself to hijack any of your user's sessions. That's a big security risk. Is there a reason why you need to "validate" someone's login? If someone wants to get notified about my comments, so what? There's nothing secret about it, they can just go to https://news.ycombinator.com/threads?id=gruez https://news.ycombinator.com/threads?id=gruez and get a live feed.
- unamashana 6y ago
  While the comments themselves are open, their state in your MagicBell inbox isn’t. If we didn’t have a way to validate identity, we won’t be able to make sure your notifications can’t be deleted/marked read by someone else.
  - usmannk 6y ago
    Why not drop a local cookie yourself for state?
    - unamashana 6y ago
      That doesn’t prevent someone from being able to impersonate you. The only alternative would be for HN to provide oauth access to your profile info.
      - jjeaff 6y ago
        Perhaps you could hash the session id, with a secret salt on server side. Then you could discard the original and store and pass along the hashed session id. That way, anyone you send it to would not be able to impersonate the hn user. You could also hash with a different salt before sending to a 3rd party so that they would not be able to impersonate someone's account in your extension.
        unamashana 6y ago
        Just to be clear, we simply validate your session by requesting the page with your cookie and seeing if we get a logged in page. We never send your info to any third party.
        linkdd 6y ago
        You can claim whatever you want to claim, we unfortunately have no way to ensure that this is true. This is a security hazard, period. While the feature is nice, and I like the design of the notification dropdown, this is a risk I (and probably many) won't take.
        pvg 6y ago
        For the purposes of authenticated interactions between HN and the user, you are the third party who now has full access to the user's account. App/extension stores generally take a dim view of/outright prohibit this because of its high abuse potential.
        jjeaff 6y ago
        I see. That makes more sense. I understood from another post that you were also passing it along to another service.
      - pvg 6y ago
        Aren't you (magicbell) gaining the persistent ability to impersonate any HN user who installs this extension? That seems like a much more serious problem than someone being able to impersonate your magicbell hn notifications. It sounds like you're saying that because HN has no fine-grained oauth delegation, it's ok to silently hijack users' HN accounts. That can't be right.
      - danShumway 6y ago
        > That doesn’t prevent someone from being able to impersonate you. But why is that a problem? If somebody wants to get notified of replies to my comments, let them. I understand why you need a unique token so that collisions don't happen, but that token doesn't need to be one-to-one unique with Hackernews usernames. It's OK to have two unique tokens that are separate from my session cookie that point to me as a user, and to have the "read" status be per-token, not per-user. More to the point, why does this read status and everything need to be stored serverside for a browser extension? Where are you putting this information where you're worried about collisions with random internet users, why have it leave the browser at all? You don't need a unique token if you're not storing everything in a centralized location off-device, the browser profile that's using the extension is itself the unique token. Why does anything need to be transmitted anywhere? Let the extension store the read statuses locally on my device, then there's zero chance of them colliding with anybody else's installation. Even if someone turns on push notifications, the push API already sends you a unique, randomized device ID/key. What's the reason why you can't push an RSS-style feed out to the device using that ID?
        EMM_386 6y ago
        I completely agree with all of this. It can be done without any of this server-side stuff. But to answer the question: > Why does anything need to be transmitted anywhere? It's because the extension is written by, and "powered by", MagicBell. They are writing it to bring attention to their product concept, where notifications like this are all handled by them.
        danShumway 6y ago
        That's totally fair, but it raises a followup question because from what I can see, MagicBell has user accounts. So that's also a unique identifier that they could use to prevent collisions. They could have a randomized ID generated locally for this "promotional" extension, and if a user creates an account on MagicBell at that point they could migrate them over to an official user ID. If this is being tied to a real backend service, I'm almost more confused why it's important to transmit my session cookies around.
dgellow 6y ago
That's a complete deal breaker. Also, your chrome web store page says "The publisher has disclosed that it will not collect or use your data". But you do collect and use users session cookie. And your linked privacy page has no content (it is literally an empty page at the current time): https://magicbell.io/privacy-policy https://magicbell.io/privacy-policy.
- unamashana 6y ago
  Sorry about the oversight in the chrome store page. We'll fix that asap. The privacy policy page has a link to the privacy policy hosted by Iubenda if you have Javascript disabled. If you have Javascript enabled, the privacy policy renders inline.
  - dgellow 6y ago
    I do not disable javascript but use an adblocker.
eyelidlessness 6y ago
Really? Because I thought of one in the time it took to read this comment. Your extension has access to the page contents, which you can use to determine the username. It’s right in the nav. You can validate that it’s authenticated by a quick look at the profile link to see that it’s editable. Cache that boolean with a hash of the cookie for subsequent validation and you’re all done, without sending anything to your own server.

That sounds dangerous. By sending the full cookie you're allowing yourself to hijack any of your user's sessions. That's a big security risk. Is there a reason why you need to "validate" someone's login? If someone wants to get notified about my comments, so what? There's nothing secret about it, they can just go to https://news.ycombinator.com/threads?id=gruez https://news.ycombinator.com/threads?id=gruez and get a live feed.

unamashana 6y ago
While the comments themselves are open, their state in your MagicBell inbox isn’t. If we didn’t have a way to validate identity, we won’t be able to make sure your notifications can’t be deleted/marked read by someone else.
- usmannk 6y ago
  Why not drop a local cookie yourself for state?
  - unamashana 6y ago
    That doesn’t prevent someone from being able to impersonate you. The only alternative would be for HN to provide oauth access to your profile info.
    - jjeaff 6y ago
      Perhaps you could hash the session id, with a secret salt on server side. Then you could discard the original and store and pass along the hashed session id. That way, anyone you send it to would not be able to impersonate the hn user. You could also hash with a different salt before sending to a 3rd party so that they would not be able to impersonate someone's account in your extension.
      - unamashana 6y ago
        Just to be clear, we simply validate your session by requesting the page with your cookie and seeing if we get a logged in page. We never send your info to any third party.
        linkdd 6y ago
        You can claim whatever you want to claim, we unfortunately have no way to ensure that this is true. This is a security hazard, period. While the feature is nice, and I like the design of the notification dropdown, this is a risk I (and probably many) won't take.
        pvg 6y ago
        For the purposes of authenticated interactions between HN and the user, you are the third party who now has full access to the user's account. App/extension stores generally take a dim view of/outright prohibit this because of its high abuse potential.
        jjeaff 6y ago
        I see. That makes more sense. I understood from another post that you were also passing it along to another service.
    - pvg 6y ago
      Aren't you (magicbell) gaining the persistent ability to impersonate any HN user who installs this extension? That seems like a much more serious problem than someone being able to impersonate your magicbell hn notifications. It sounds like you're saying that because HN has no fine-grained oauth delegation, it's ok to silently hijack users' HN accounts. That can't be right.
    - danShumway 6y ago
      > That doesn’t prevent someone from being able to impersonate you. But why is that a problem? If somebody wants to get notified of replies to my comments, let them. I understand why you need a unique token so that collisions don't happen, but that token doesn't need to be one-to-one unique with Hackernews usernames. It's OK to have two unique tokens that are separate from my session cookie that point to me as a user, and to have the "read" status be per-token, not per-user. More to the point, why does this read status and everything need to be stored serverside for a browser extension? Where are you putting this information where you're worried about collisions with random internet users, why have it leave the browser at all? You don't need a unique token if you're not storing everything in a centralized location off-device, the browser profile that's using the extension is itself the unique token. Why does anything need to be transmitted anywhere? Let the extension store the read statuses locally on my device, then there's zero chance of them colliding with anybody else's installation. Even if someone turns on push notifications, the push API already sends you a unique, randomized device ID/key. What's the reason why you can't push an RSS-style feed out to the device using that ID?
      - EMM_386 6y ago
        I completely agree with all of this. It can be done without any of this server-side stuff. But to answer the question: > Why does anything need to be transmitted anywhere? It's because the extension is written by, and "powered by", MagicBell. They are writing it to bring attention to their product concept, where notifications like this are all handled by them.
        danShumway 6y ago
        That's totally fair, but it raises a followup question because from what I can see, MagicBell has user accounts. So that's also a unique identifier that they could use to prevent collisions. They could have a randomized ID generated locally for this "promotional" extension, and if a user creates an account on MagicBell at that point they could migrate them over to an official user ID. If this is being tied to a real backend service, I'm almost more confused why it's important to transmit my session cookies around.

dgellow 6y ago

That's a complete deal breaker. Also, your chrome web store page says "The publisher has disclosed that it will not collect or use your data". But you do collect and use users session cookie. And your linked privacy page has no content (it is literally an empty page at the current time): https://magicbell.io/privacy-policy https://magicbell.io/privacy-policy.

unamashana 6y ago
Sorry about the oversight in the chrome store page. We'll fix that asap. The privacy policy page has a link to the privacy policy hosted by Iubenda if you have Javascript disabled. If you have Javascript enabled, the privacy policy renders inline.
- dgellow 6y ago
  I do not disable javascript but use an adblocker.

eyelidlessness 6y ago

Really? Because I thought of one in the time it took to read this comment. Your extension has access to the page contents, which you can use to determine the username. It’s right in the nav. You can validate that it’s authenticated by a quick look at the profile link to see that it’s editable. Cache that boolean with a hash of the cookie for subsequent validation and you’re all done, without sending anything to your own server.