Live data from Hacker News

Viewing profile — hobohacker

hobohacker

HN member
Joined
Sat, Nov 10, 2012, 9:02 PM UTC
HN karma
319
Public activity
37 items

About hobohacker

willchan@chromium.org

https://insouciant.org

https://plus.google.com/+WilliamChanPanda

https://twitter.com/hobohacker

Recent public activity

  1. comment
    Comment #12259917

    Ex-USDS here. Did 6 months at USDS, still federally employed as a USDS reserve. Just wanted to chime in on "Who in their right mind would go to work for the government, for minimum…

  2. comment
    Comment #9549172

    To answer your specific question about why not in TCP, it's not deployable. Here's why: * In order to get multiplexing and other features introduced with HTTP/2, you need to change…

  3. comment
    Comment #7424858

    Er, I thought I was agreeing with you. What do you think I'm arguing? To be clear, I view these two statements as grounded in the same logic, although perhaps one is more strongly …

  4. comment
    Comment #7424248

    I think it's a fair assessment that supporting experimental technologies requires more engineering resources. Everyone has to do the cost/benefit analysis themselves.

  5. comment
    Comment #7424124

    Speaking as a Chromium SPDY & HTTP/2 developer, we are very much focused on standardization. SPDY is an experimental protocol meant to drive the standards process, not become a de …

  6. comment
    Comment #7289366

    I don't see why you think this is a semantic requirement of HTTP. Perhaps there's some confusion over what HTTP semantics are. Let me refer you to http://tools.ietf.org/html/draft-…

  7. comment
    Comment #7288425

    Only time will tell. It's all still in progress. Of all the major browser vendors (Firefox, Chromium, IE) present at the Zurich HTTP/2 interim meeting, only Patrick McManus (Firefo…

  8. comment
    Comment #7288412

    The specification indeed is about proxying http resources, not https ones. So it's not initially as alarming as some other proposals discussing trusting proxies to intercept SSL co…

  9. comment
    Comment #7288349

    As Patrick McManus says in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/... : If someone can install a root cert onto your computer then you are already owned - ther…

  10. comment
    Comment #7288335

    Perhaps you should look at the Hacker News comments on that thread: https://news.ycombinator.com/item?id=7249193 . Notably, my comments: https://news.ycombinator.com/item?id=724956…

  11. comment
    Comment #7288326

    HTTP/2 does not change the meaning of http:// . That's the opportunistic encryption proposal: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-... . For more information…

  12. comment
    Comment #7249869

    I guess I should out myself as a Chromium HTTP stack maintainer (since 2009, so this behavior predates me). One might consider me a domain expert here. I participate in IETF HTTPbi…

  13. comment
    Comment #7249560

    I think the author of this blogpost has a few things off: - HTTP2 != httpbis. Both work is being done by the same working group "httpbis". http://datatracker.ietf.org/wg/httpbis/ch…

  14. comment
    Comment #7188784

    That's true, which is why I was careful to say in its original form :) Since the original attack was on cookies (request headers). To my knowledge, no other SPDY server defaults re…

  15. comment
    Comment #7182418

    Let's be clear that the original CRIME attack was against request header secrets. Therefore, disabling response header compression (as nginx defaults to) does not prevent that. SPD…

  16. comment
    Comment #7033889

    Head of line blocking is when something ahead in the line blocks things behind it. If browsers choose to use connection limits, then that means that things ahead in the line and ge…

  17. comment
    Comment #7026001

    To your points about pipelining, there's a reason it doesn't get compared. It's not usable - https://insouciant.org/tech/status-of-http-pipelining-in-chr... Head of line blocking i…

  18. comment
    Comment #6837129

    I'd love to hear what's stopping you from forcing SSL site-wide. Is it cost? If so, what are the specifics if you don't mind sharing? Also, I don't know if you're using different V…

  19. comment
    Comment #6126035

    https://code.google.com/p/chromium/issues/detail?id=22423 discusses some of the issues with using SRV records in browsers. SRV records could help clients discover server HTTP/2 sup…

  20. comment
    Comment #5671161

    I'm not going to argue whether or not other libraries/protocols (e.g. your example of protobufs) may provide higher value. I was simply questioning your assertion "SPDY has no bene…

  21. comment
    Comment #5663457

    http://www.chromium.org/spdy/spdy-whitepaper has data on improvements in lab tests. http://googlecode.blogspot.com/2012/01/making-web-speedier-a... has a blurb where Google announc…

  22. comment
    Comment #5663361

    Why do you assert it has no benefit for mobile APIs? Here are a few that I can think of off the top of my head: * SPDY Multiplexing is superior to HTTP pipelining. Pipelining requi…

  23. comment
    Comment #5453423

    Can you clarify this statement? Perhaps there's missing context, but as it reads, it seems like a false statement. When I look at chrome://view-http-cache/, I see a bunch of https:…

  24. comment
    Comment #5349341

    It depends on what you mean by atomic. Please refer to http://www.chromium.org/developers/design-documents/indexedd... where Chromium devs state: """ LocalStorage is inherently rac…

  25. comment
    Comment #5349198

    The primary caveat with this approach is race conditions due to lack of locking. Note the "Issues" section in http://www.w3.org/TR/webstorage/ which says: """ The use of the storag…