||[Jan. 22nd, 2006|11:57 am]
My beef with Firefox:
Firefox doesn't have HttpOnly cookies, even though LiveJournal had avva write a patch for Mozilla over a year ago:
See my comment there for more information.
Either one of these would've prevented us from going with one-domain-per-user (our new URL scheme), and the forthcoming cookie changes where we have master cookies and per-domain cookies that are signed by the master cookie.
Fun, but a pain in the ass too.
you mean to tell me these changes were prompted because of flaws in FIREFOX?!?!
*proud IE user*
2006-01-22 09:07 pm (UTC)
Don't be too proud. Firefox, IE, (and I hear Safari) all have problems.
I don't hear about Opera problems, but that might be because nobody's cared to check.
My beef with LiveJournal: it doesn't let me say I don't want to be exposed to all of this; instead it generally forces me to accept the styles and embedded threats others are using in their journals. A "use my own style always" option would be really helpful.
Contrast with Wikipedia, where you can have your own styles but only you see them, so it's impossible to use them to attack others.
> A "use my own style always" option would be really helpful.
You can append "?style=mine" to any LJ URL and it'll appear in your style. There might be some exceptions, though.
does appending "?style=mine" to the url not provide that function?
I think this has more to do with the usage of the two sites: LiveJournal gives you a mighty sense of personal ownership, whereas Wikipedia discourages it.
I can't say I like the idea of issuing a redirect on first hit of a journal, but if that's what you've got to do, that's what you've got to do.
2006-01-22 10:05 pm (UTC)
Only if you're logged in. Regular users coming from, say, Google won't get it. In practice it's not that painful. We're also prioritizing that traffic because it doesn't block on any resources and can/should be serviced incredibly quickly.
Please don't bind cookies to IP addresses without making it an option like the current "Bind to IP." The first two octets is a huge swath of IP space, but some ISPs like BellSouth have several discontiguous blocks they assign out of. In fact, even UNC has two or three discontiguous /16~24s (I want to say /20s, but I'm not sure) users can DHCP into.
Not to mention that I go from one network to another on a laptop I consider "secure enough" for my LJ account.
generation/poetry is free-form text/poetry so you can write a haiku and go after people for subverting security to steal copyrighted material.
I don't think the DMCA would apply here, so you'd be under normal copyright law. Which makes interoperability a concern. See also: you can't copyright a file format (or a wire protocol). To get something slightly less hand-wavey, you want to put a trademarked phrase in there, complete with (TM). Then you can issue C&Ds, but it's still nothing but a sequence of numbers, which is yadda yadda yadda. If I were a vendor, I'd be highly annoyed by this. But I usually sit in the "interoperator" chair, so I can dig it.
2006-01-22 10:42 pm (UTC)
I don't think the DMCA would apply here, so you'd be under normal copyright law.
The IP-binding stuff is all talk at this point. There are enough fucked up ISPs (AOL) and people who like to go mobile (me, you), that I really doubt we'd ever turn it on by default. What may happen is an option so people can turn it on by default for themselves.
I use firefox with script blocker extension so I was safe either way (no I don't allow java to run on friends page), IE users could have used Finjan Surfing Guard etc etc. Props to LJ for expiring cookies, and making SSL log in default. I would also strongly encourage allowing encrypted postings for free users to further enhance this. I am not sure X.livejournal.com domains are going to keep everyone safe but it will complicate the exploit.
Allowing HTTP to directly specify trust levels seems to me a good idea (on first look, anyway). You could apply that to HTML santization - do it at the browser level with a special sanitization tag (you'd still need XML sanitization, but only at the well-formedness level). However, it would be one big spec because there are so many priviledges you might want to grant or withhold.
There's a big problem with getting there from here - half the point is lost when not all browsers support it. But it might still be worth aiming for.
While we could discuss forever that HttpOnly isn't a complete solution for all attack instances, that's not what matters. It's like saying, "Well, condoms don't _always_ work, so let's just not use anything!" HttpOnly does work most of the time, especially for stopping what our HTML/CSS spermicide doesn't.
You've always had a way with words, Brad.
2006-01-24 03:19 am (UTC)