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

Can You Afford It? Real-World Web Performance Budgets

infrequently.org

Post reply on HN
Print view View original

121–130 of 130 posts

Re: Can You Afford It? Real-World Web Performance Budgets

#121

Post by samsonradu »

Can_Not wrote: post #120
samsonradu wrote: post #118

Earlier quoted context omitted.

Think you're a bit confused about how it all works. There is no need to use plaintext, we'll assume we're using https by default. You are already sending the data from the client to the server, I can as well echo it back with a couple of validation errors. I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only pro…

Security operates in layers. TLS isn't the end-all, be-all for security. It's one layer that prevents a category of attack vectors. Every extra unnecessary sending or storing of sensitive data is an attack vector.

Again, we're not storing anything. And in our case TLS is the layer we're using for protecting our data in-transit. You rely on it as a client when you send the form to the server.

Can you give me an example where POST-ing a form would be secure but responding with the data adds another attack vector? They're both protected by the same "layer" of security, isn't it? How is one more vulnerable than the other?

Re: Can You Afford It? Real-World Web Performance Budgets

#122

Post by grogs »

mrighele wrote: post #75
TeMPOraL wrote: post #67

Earlier quoted context omitted.

This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation? Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)

Sounds like PJAX.

Re: Can You Afford It? Real-World Web Performance Budgets

#123

Post by ianamartin »

swyx wrote: post #33
ianamartin wrote: post #23

Earlier quoted context omitted.

I was going to say this but wanted to read the comments first to see if anyone else did. The constraints on global technology sever for this budget. But I have a personal standard of 200ms for TTI on my projects, and I push hard against any requirements or suggested libs or UI features that broach this. 5 secs? You can get away with that if you’re a global brand that people are already hooked into, I guess. The amazo…

sorry, but 200ms for TTI on the web? are you measuring the same way that he is? he includes 1600ms just for dns lookup and tls handshake

Sorry I wasn’t clear about that.

The article is using some very heavy constraints on networking and hardware based on a global, mobile audience.

My constraints do not take that into account. But they would only add a max of 200ms on top of that minimum the article is talking about.

Not anything near ~4 secs. 4 secs to do anything on a web app is malpractice.

Re: Can You Afford It? Real-World Web Performance Budgets

#124

Post by setr »

samsonradu wrote: post #121
Can_Not wrote: post #120

Earlier quoted context omitted.

Security operates in layers. TLS isn't the end-all, be-all for security. It's one layer that prevents a category of attack vectors. Every extra unnecessary sending or storing of sensitive data is an attack vector.

Again, we're not storing anything. And in our case TLS is the layer we're using for protecting our data in-transit. You rely on it as a client when you send the form to the server. Can you give me an example where POST-ing a form would be secure but responding with the data adds another attack vector? They're both protected by the same "layer" of security, isn't it? How is one more vulnerable than the other?

What he's suggesting is that you never send the password to the server, you only send the hash.

The password itself never leaves the client, and never hits the network.

Re: Can You Afford It? Real-World Web Performance Budgets

#125

Post by samsonradu »

setr wrote: post #124
samsonradu wrote: post #121

Earlier quoted context omitted.

Again, we're not storing anything. And in our case TLS is the layer we're using for protecting our data in-transit. You rely on it as a client when you send the form to the server. Can you give me an example where POST-ing a form would be secure but responding with the data adds another attack vector? They're both protected by the same "layer" of security, isn't it? How is one more vulnerable than the other?

What he's suggesting is that you never send the password to the server, you only send the hash. The password itself never leaves the client, and never hits the network.

Password itself is an exception, I agree with you since you don't need the plain value at all, you can get away with comparing hashes. But how about CC data?

Re: Can You Afford It? Real-World Web Performance Budgets

#126

Post by slightlyoff »

aphexairlines wrote: post #59
olegkikin wrote: post #54

His argument is based on an example where he puts JS in , when it's been a recommendation for ages to put JS at the very end of .

It looks like he needs the JS to load first for the browser to make sense of his custom elements: "If our example document wasn’t reliant on JavaScript to construct the custom element, the contents of the document would likely be interactive as soon as enough CSS and content was available to render meaningfully."

Howdy; author of the article here.

TTI would be pushed back regardless of where the script was included so long as it executed for more than 50ms (very likely). I used a trivial document that contains many pathologies I see in traces to illustrate the point, not to suggest what ideal apps will do.

Re: Can You Afford It? Real-World Web Performance Budgets

#127

Post by setr »

samsonradu wrote: post #125
setr wrote: post #124

Earlier quoted context omitted.

What he's suggesting is that you never send the password to the server, you only send the hash. The password itself never leaves the client, and never hits the network.

Password itself is an exception, I agree with you since you don't need the plain value at all, you can get away with comparing hashes. But how about CC data?

Couldn't you do the same? Hash-spaces are segregated by zip codes (hash(zip) is the key to buckets) and then hash the credit card and cvv; compare to verify

Store last 4 digits of cc and mastercard vs visa to provide the "is this the correct card?" form

Re: Can You Afford It? Real-World Web Performance Budgets

#128

Post by samsonradu »

setr wrote: post #127
samsonradu wrote: post #125

Earlier quoted context omitted.

Password itself is an exception, I agree with you since you don't need the plain value at all, you can get away with comparing hashes. But how about CC data?

Couldn't you do the same? Hash-spaces are segregated by zip codes (hash(zip) is the key to buckets) and then hash the credit card and cvv; compare to verify Store last 4 digits of cc and mastercard vs visa to provide the "is this the correct card?" form

I'm not sure you can. If a site asks you for CC and CVV data it should already be PCI compliant, say a payment processor. Don't they need the plain text CC and CVV to be able to bill it, if it's a first time user? How can the client send a hash, compare it to what?

I'm really curious about how you see this working, I can't understand how you can forever obfuscate your CC info. I assume at some point the server needs your plain data.

Re: Can You Afford It? Real-World Web Performance Budgets

#129

Post by setr »

samsonradu wrote: post #128
setr wrote: post #127

Earlier quoted context omitted.

Couldn't you do the same? Hash-spaces are segregated by zip codes (hash(zip) is the key to buckets) and then hash the credit card and cvv; compare to verify Store last 4 digits of cc and mastercard vs visa to provide the "is this the correct card?" form

I'm not sure you can. If a site asks you for CC and CVV data it should already be PCI compliant, say a payment processor. Don't they need the plain text CC and CVV to be able to bill it, if it's a first time user? How can the client send a hash, compare it to what? I'm really curious about how you see this working, I can't understand how you can forever obfuscate your CC info. I assume at some point the server needs…

I've personally never worked with payment processors, but I don't see why your intermediate servers would need to have it plaintext

To the payment processor, they'll always have the cc/cvv info, or rather, the hash of it, to verify with. If they don't have it, then I imagine the user doesn't have a valid cc. (How can you have a VISA cc that visa doesn't know about? If its a valid cc, eventually we have to hit someone who knows it...)

For creation of the CC, its entirely done offline atm isn't it? And since its basically just a shared secret, you could do the whole diffie helman physically.. but anyways

So then on your side, as some kind of store, it should be the same as passwords. The payment processor tells you the hash function to use, and you use it client side, and the processor verifies.

Alternatively, you send the user to the someone else (ie redirect to paypal), who does the same thing.

It doesn't seem at all necessary to me that your cc/cvv actually leaves your machine in plaintext. Of course, they may be sending plaintext for some reason, but I don't see an obvious reason why they should

Post reply on HN