Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Messages via JSON

refl.me

Post reply on HN
Print view View original

71–80 of 129 posts

Re: Messages via JSON

#71

Post by ActorNightly »

enedil wrote: post #36
beefhash wrote: post #7

> Request signature format(crc): [time_stamp]_[md5(time_stamp+secret_key)] This should probably be an HMAC construction at the very least, and MD5 in general just should be discarded entirely in favor of BLAKE2b, SHA-2 or SHA-3. And ideally, it'd actually validate the rest of the contents as well.

There's another problem, if the author tells us that this is crc, while it's a MAC (not particularly strong tbh), it shows that we, as developers and users, cannot trust that cryptographic decisions of the author are of any consideration. For reference, crc is not a signature, its full name is "cyclic redundancy check", which is a really simple mathematical operation, that computes a specific remainder that comes fro…

Your are correct in the "trust but verify" methodology, but the developer is Russian so it could be a translation error

Re: Messages via JSON

#72

Post by Andrew_nenakhov »

nicolas314 wrote: post #69
somebodythere wrote: post #52

Earlier quoted context omitted.

> No way around it, mobile devices don't have guaranteed connectivity as servers do. Not sure what "guaranteed connectivity" has to do with it, your phone is connected to network ~90% of the time, and when it is, it has a socket connection with the Google Cloud Messaging API (or iPhone equivalient) which pushes down data as it comes into the queue. If messages come in while you're disconnected, you get them all the n…

Ah but sockets are only an illusion that fall apart under the next tunnel. Mobiles are not constantly connected, they use a wireless packet-based network. The only way your mobile is registered as part of a network is because it is the one polling stations at regular intervals. Can't go the other way around, really. How could the network know you are now out of that tunnel? You may want to have a look at how APN are…

No. See my answer above. Mobile devices on both iOS and Android have a built-in XMPP client that reconnects to APNS/FCM servers every time it regains connectivity.

Re: Messages via JSON

#73

Post by CharlesW »

semiotagonal wrote: post #63
Semiapies wrote: post #57

Earlier quoted context omitted.

As far as I can tell, that's it. It's a reinvention of RSS without any notable advantages and no compatibility with existing systems. So, a reinvented wheel that doesn't work on roads.

It's like re-inventing the wheel after everyone stopped using the wheel . It might meet with some success. To people who don't know about RSS, it's a new thing.

> It's like re-inventing the wheel after everyone stopped using the wheel.

32% of Americans use RSS every month just for podcasts alone.

Re: Messages via JSON

#74

Post by core-questions »

CharlesW wrote: post #73
semiotagonal wrote: post #63

Earlier quoted context omitted.

It's like re-inventing the wheel after everyone stopped using the wheel . It might meet with some success. To people who don't know about RSS, it's a new thing.

> It's like re-inventing the wheel after everyone stopped using the wheel. 32% of Americans use RSS every month just for podcasts alone.

We can all thank Adam Curry for that!

Re: Messages via JSON

#75

Post by chatmasta »

nicolas314 wrote: post #69
somebodythere wrote: post #52

Earlier quoted context omitted.

> No way around it, mobile devices don't have guaranteed connectivity as servers do. Not sure what "guaranteed connectivity" has to do with it, your phone is connected to network ~90% of the time, and when it is, it has a socket connection with the Google Cloud Messaging API (or iPhone equivalient) which pushes down data as it comes into the queue. If messages come in while you're disconnected, you get them all the n…

Ah but sockets are only an illusion that fall apart under the next tunnel. Mobiles are not constantly connected, they use a wireless packet-based network. The only way your mobile is registered as part of a network is because it is the one polling stations at regular intervals. Can't go the other way around, really. How could the network know you are now out of that tunnel? You may want to have a look at how APN are…

If they’re using XMPP like others in the thread mentioned, they’re likely using STUN/TURN for signaling. IIRC according to google, something like 10% of hole punched traffic needs to be routed through the TURN server due to symmetric NAT. For all other types, a nearly persistent connection from server to client is possible with STUN/TURN, since a client can resignal when its connection changes.

Re: Messages via JSON

#76

Post by Andrew_nenakhov »

nicolas314 wrote: post #56
codegladiator wrote: post #22

What exactly is new in this ? Isn't this what Android and iOS notification services do ? And all messaging services ? What did I miss

True enough, this is in concept the very same as Apple Push Notification (APN) service. Difference is that you are in charge of the server side and handle all the security and uptime yourself. Very cool idea, simple enough to generate a lot of really cool projects.

No. APNS works differently and iOS devices do not poll Apple's server at frequent intervals. I explained it here [1]

[1] https://news.ycombinator.com/item?id=21338838

Re: Messages via JSON

#79

Post by joshstrange »

purple_ducks wrote: post #49

> The "refl.me" key must always be true, otherwise an error will be called. Why?

My guess would me as a sort of "signoff" from the person hosting the JSON that refl.me is approved to use their endpoint. It sidesteps a slew of abuse issues by either knowing it's a feed you own OR a feed you are re-hostings/proxying and so the liability rests with you.

In my mind it's in the same category as google throwing garbage or while(1){} loops at the start of their JSON responses to prevent XSS JSON reflection attacks. I know it's not the same thing at all but idk, thats what comes to mind for me.

EDIT: Of course I think of a better comparison as soon as I hit submit: Sort of like LetsEncrypt looking for a .well-known/acme-challenge to validate your domain.

Re: Messages via JSON

#80

Post by cryptonector »

ozzmotik wrote: post #54
enedil wrote: post #36

Earlier quoted context omitted.

There's another problem, if the author tells us that this is crc, while it's a MAC (not particularly strong tbh), it shows that we, as developers and users, cannot trust that cryptographic decisions of the author are of any consideration. For reference, crc is not a signature, its full name is "cyclic redundancy check", which is a really simple mathematical operation, that computes a specific remainder that comes fro…

>we can find another string that differs in one byte only, that has the target crc reading that has me curious; if one can do that for any arbitrary string, and then iterate that process, doesn't that stand to reason that with enough work, one could make any two given strings calculate out to the same crc? I guess maybe not because that one byte constraint isn't specified as far as where it occurs and whether it's an…

At Sun we had a server with a flaky NIC with very high error rates, but worse, occasionally would introduce two one-bit errors in packets such that all the CRCs involved were defeated. This actually caused some version control history corruption. I forget the details though. Maybe some other ex-Sun'er can chime in with the details.
Post reply on HN