31–40 of 40 posts
Earlier quoted context omitted.
Well they already had at least one breach: https://techcrunch.com/2018/12/20/blind-anonymous-app-data-e...
You'd think that engineers from top - tier tech companies would know better, before sharing sensitive information on some random website.
I think you don't have to resort to symmetric encryption here, even keeping performance in mind. What you do is generate a new asymmetric keypair on the client for every session, then send the public key over to the server. Then the server encrypts every response with that public key, allowing only the client to decrypt it.
Doing that, one can only read a session's network traffic, both ways, if they can read values of variables on the client -- but if one can do that, you can read everything anyway. ;)
EDIT: forgot to talk about performance -- you just use a so-called "envelope", where the sending party first encrypts the data symmetrically with a randomly generated key, then encrypts that random key with the asymmetric crypto. The pair (symmetrically encrypted data and the asymmetrically encrypted key) is sent to the receiver, which can use its private key to decrypt the symmetric key, with which it decrypts the data.
This is yet another reminder that good JS minification tools exist that can absolutely change object properties into short minimal strings instead of descriptive names. It's called the Closure Compiler in advanced mode. You do have to have quite a bit of discipline in writing the JS to have that though. Some languages like ClojureScript actually do this by default, so it doesn't take much effort. Also it helps if you…
Better to use protobufs at this point.
Earlier quoted context omitted.
If you're going to do that, why not just forego human readability entirely and user an interchange format like protobuf or flatbuffers?
Because if you use the protobuf wire format, all the parsing code needs to be written in JS and won't be as performant as JSON parsing built into the browser. But yes you can in fact transform protocol buffers into JS arrays in the way I described. I'm essentially describing protobuf designed for JS. Imagine your protobuf definitions are read by a compiler which spits out JS classes with getters and setters. These ge…
from the silly comments of "infinite scrolling" being definitive proof of a solid rest api behind and that php is or is not capable of either (the writing is too ambiguous). to the roundabout amateur obfuscation (the author calls encryption) that is entirely akin to the JavaScript that disabled right click to "copyright" the page's content in the 90s.
sigh
the sad state of web developers. from the silly comments of "infinite scrolling" being definitive proof of a solid rest api behind and that php is or is not capable of either (the writing is too ambiguous). to the roundabout amateur obfuscation (the author calls encryption) that is entirely akin to the JavaScript that disabled right click to "copyright" the page's content in the 90s. sigh
Earlier quoted context omitted.
Because if you use the protobuf wire format, all the parsing code needs to be written in JS and won't be as performant as JSON parsing built into the browser. But yes you can in fact transform protocol buffers into JS arrays in the way I described. I'm essentially describing protobuf designed for JS. Imagine your protobuf definitions are read by a compiler which spits out JS classes with getters and setters. These ge…
Right, but the bottleneck is generally not "how long it takes to parse the payload". For anything other than MB of data, I doubt you'll notice much of a difference between parsing JSON and flatbuffers. The bottleneck is how large and how long it takes when sending it over the wire.
the sad state of web developers. from the silly comments of "infinite scrolling" being definitive proof of a solid rest api behind and that php is or is not capable of either (the writing is too ambiguous). to the roundabout amateur obfuscation (the author calls encryption) that is entirely akin to the JavaScript that disabled right click to "copyright" the page's content in the 90s. sigh
Earlier quoted context omitted.
Right, but the bottleneck is generally not "how long it takes to parse the payload". For anything other than MB of data, I doubt you'll notice much of a difference between parsing JSON and flatbuffers. The bottleneck is how large and how long it takes when sending it over the wire.
Right. Because protobuf parsing is not built into the browser, you have to add the time it takes to transfer protobuf code as well.
Really depends on the use case I guess. But any situation where I'm using JSON arrays instead of keyed objects for efficiency reasons is probably a situation where flatbuffers makes just as much (if not more) sense.
Earlier quoted context omitted.
Because if you use the protobuf wire format, all the parsing code needs to be written in JS and won't be as performant as JSON parsing built into the browser. But yes you can in fact transform protocol buffers into JS arrays in the way I described. I'm essentially describing protobuf designed for JS. Imagine your protobuf definitions are read by a compiler which spits out JS classes with getters and setters. These ge…
Why do you assume that native JSON parsing is faster than protobuf parsing using JS? In most cases protobuf is faster.
Protobufs weren’t built for speed.