> To start with, we can defer the string conversion to just before entering DevTools, basically pushing the content/renderer/loader/web_url_loader_impl.cc logic further down into Blink.

This was quite straightforward. I'll upload a CL for it tomorrow.

Incidentally, it should be pretty straightforward to make the protocol more efficient without changing the schema (so you can easily support both old and new protocols for compatibility). Here's a strawman:

1. Replace JSON with canonical CBOR (so no indefinite-length nonsense). Chromium already has encoders and decoders.

2. First message is a list of strings. This is every field name in the IDL file in some order (sorted?). First one is zero, second is one, etc. This is so you don't pay for keys. Otherwise there's pressure to use short rather than readable field names, which is silly.

3. Subsequent messages are CBOR messages, with only the subset corresponding to JSON allowed. Except that map keys may be either strings or integer. If it's an integer key, replace it with the corresponding index into the strings table.

4. Later probably add the bytes type so you're not base64-encoding things.

These are all good ideas.

- Binary protocol is on its way, but it takes time. We are currently migrating base64 bits to explicit binary markup. CBOR is a fine candidate for the serialization itself though.

- Indexing keys makes protocol a bit involved - keys are latin1, so the CPU cost of serializing those is minimal.

- We are working on (4) already. It is not JSON serialization that is expensive, transcoding text and base64-ing blobs is what shows up in profiles.

In either case, I think it is somewhat beside the point - we should opt out from doing unnecessary work first and only then think about mitigating the overhead by means of transport optimization.

I guess my claim would be that, under any sensible serialization, the SecurityDetails cost should be negligible enough that I can't imagine it mattering. If we can solve the performance issues without making what is already not a great UX even worse, that seems preferable, no? (But I also work on Networking, not Enamel. Hopefully Enamel folks can chime in on that one.)

The indexing keys suggestion was because you were concerned that adding two bytes isn't just adding two bytes because of the key name. I could go name my new field "sig" instead of "signatureAlgorithm", but this starts getting silly in the long run.

Additionally, the blocked CL has been out for a month now and is really just trying to add one field. It is frustrating to have one's small addition get caught up in broader architectural concerns between two completely different teams. I agree the original implementation (two strings with two long keys) is costly. I was following the existing design, but it sounds like the existing design was bad.

Let's try to keep progress possible by tackling the low-hanging fruit first. You mentioned it's text and base64 that shows up in profiles. Let's do (3) then, at least for the new stuff. We can easily turn the TLS bits into numbers.

If I add "sig":u16, that'll cost 12 characters. I can free up that amount easily by going back and compressing "keyExchangeGroup":string to "group":u16. That should also be more efficient in-memory as integers are, one hopes, not boxed in V8. They also avoid a UTF-8 decode. I could compress keyExchange/cipher/mac too, but keyExchange/cipher were, sadly, not marked optional, so this may not be worth it.

And then when you all make a binary protocol, those numbers will get even smaller by avoiding decimal.

(To be clear, using numbers for TLS here is neither some ad-hoc compression scheme nor serializing Chrome-internal values. TLS parameters are natively represented uint16_t on the wire, with standardized values. The string representation is the ad-hoc Chrome-specific one.)

I see the point about the Security Panel not being used very often (it's opened something like 0.34% of the time according to UMA). However, making it so that it's even harder to get security details by requiring additional user input doesn't seem great--the panel is already somewhat hidden and requires reload to see subresources.

I tend to agree that it shouldn't be difficult to add additional fields, and that it would be preferable to make optimizations in the transport to provide a better UX.

>> However, making it so that it's even harder to get security details by requiring additional user input doesn't seem great--the panel is already somewhat hidden and requires reload to see subresources.

Maybe we can use this fact and reload with the security aspects enabled when reloading from the security panel? That way we don't add overhead and preserve existing UX.

To be clear, I do not work on the security panel or anything related to UI. I am happy to do (3) from above, but I'm not the right person to do the other things here.

I do, however, continue to believe that the chattiness should not require UX changes or preclude fixing the reload problem. The amount of data that needs to be transmitted is naturally very small. The problem is the way we are transmitting it does not meet the apparent requirements.

I'm triaging the DevTools bugs and am trying to figure out what we should do with this one. It is filed by you and assigned to you, but I don't think there is a plan to do something here. So I wonder what should happen to this bug. We try to close those with no clear plan to be able to keep the product in a healthy state...

I like the suggestion by pfeldman@ in comment 7, but I think we may still need some pieces from SecurityDetails to get the Connection information for the Security overview. Would it be okay to split out the connection details from the certificate and CT details, and then only send SecurityDetails on reload from the security panel with no UX changes as suggested?

As far as triaging, I can probably work on this optimization as a separate bug. But I agree with comment 8 that it doesn't preclude work on some of the other proposals above.

Hi everyone... I'm back from leave and catching up on this bug. I suggest that as a path forwards, Livvie and I implement davidben's proposal #3 initially, while simultaneously fleshing out the UX details of #1 (perhaps with binghamj's help?). I think pfeldman's suggestion in #7 is workable but proposal #3 is probably worth doing regardless.