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

91–100 of 129 posts

Re: Messages via JSON

#91

Post by xg15 »

miki123211 wrote: post #85

If you need something like that, go for a Telegram bot. It's really simple to make, the API is very nice and developer friendly. It's not oAuth, just a simple secret. It even accepts parameters via GET, so writing a bash script that check something and sends a message via Curl is pretty easy. There are few APIs simpler than this one. This is also more efficient, as your app only sends data out when it needs to, inste…

I think the linked app is more supposed for one-off use-cases - e.g., you're a dev/admin and want to keep an eye on some web service. You could write a simple endpoint in python and have the app poll it over LAN.

I think not needing to bother with any kind of third-party is hard to beat in terms of simplicity.

> I don't think this app will ever work on iOS, due to Apple's policies.

I've not much experience on iOS, so apologies if the answer is obvious, but is there no scheduled task API you could use?

At least, you're not supposed to keep the app working in the background in Android either - however, the app's use-case should still be doable with the background scheduling API.

Re: Messages via JSON

#92

Post by NickBusey »

miki123211 wrote: post #85

If you need something like that, go for a Telegram bot. It's really simple to make, the API is very nice and developer friendly. It's not oAuth, just a simple secret. It even accepts parameters via GET, so writing a bash script that check something and sends a message via Curl is pretty easy. There are few APIs simpler than this one. This is also more efficient, as your app only sends data out when it needs to, inste…

I created a Telegram bot for one of my apps, but had to remove Telegram from my phone/computer after their terrible handling of Facebook linking. I made the mistake of linking my Telegram account to my Facebook account, which gave me the wonderful 'feature' of getting a notification any time one of my (due to the linked account being promotional) thousands of friends joined Telegram. These notifications play at any time of the day or night, and there is no way to disable them. Removing the app was my only recourse as a chat app without notifications is pretty useless.

Re: Messages via JSON

#93

Post by dfox »

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…

The amount of bits you need to modify is not “one byte” but the same as the degree of used polynomial.

And producing two strings with same CRC is trivial to the extent that it is how you are originally supposed to use the algorithm. Notice that CRC-32 of every valid ISO9660 filesystem is 0xffffffff ;)

Re: Messages via JSON

#96

Post by enedil »

dfox wrote: post #93
ozzmotik wrote: post #54

Earlier quoted context omitted.

>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…

The amount of bits you need to modify is not “one byte” but the same as the degree of used polynomial. And producing two strings with same CRC is trivial to the extent that it is how you are originally supposed to use the algorithm. Notice that CRC-32 of every valid ISO9660 filesystem is 0xffffffff ;)

Yes, sorry for the lack of scrupulosity. Of course, it might happen it suffices to change one byte, especially that this byte can be at any position.

Re: Messages via JSON

#98

Post by colanderman »

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…

Not one byte, but a number of bytes equal to the length of the CRC (typically 4).

But yes, people saying "CRC" when they really mean "checksum" or "signature" is a pet peeve of mine, and I treat it as a code smell. CRC has a precise defined technical meaning.

For the curious: CRC is linear with respect to XOR. This means that if you XOR two equal-length strings, the CRC will be the individual CRCs XORed together. It's also a bijection for messages of length equal to the polynomial (typically 32 bits): every input maps to a distinct output and vice-versa. Together, these mean it's trivially invertible for a message of length equal to the CRC: the CRC function can be represented as a square matrix over GF-2 (i.e., bits + XOR), which can be inverted with standard Gaussian elimination to produce the inverse function: generate a (short) string from any CRC.

More fun CRC tidbits: it's not a given that two arbitrary CRC functions, or a CRC and another linear(ish) checksum (e.g. ones' complement), are linearly independent. This can bite you when you try to use two different CRCs to get "more" error protection, or when you use "independent" CRCs to route work at two different points in a system. Again this is easy to verify using linear algebra (just check that the GF-2 matrix formed by the concatenation of your two functions is of full rank).

Re: Messages via JSON

#100

Post by ValueNull »

joshstrange wrote: post #81
ValueNull wrote: post #78

Earlier quoted context omitted.

Wish this wasn’t the case, would love to integrate services I don’t control into this.

I won't pretend it's "so easy" or anything like that but could you just proxy those requests and add the key yourself? AWS Lambda comes to mind as a cheap/free way to accomplish this with the benefit of letting you modify the data if needed on the fly (or even check against a DynamoDB for history/other rules).

Wouldn’t this defeat one of the benefits of this software, the need to not host your own server (or any backend infrastructure)?
Post reply on HN