While reading the 'Elaborate Description of Stacking Contexts' section of the CSS2.1 spec, I had an inkling of understanding of why blocks, floats, and inlines were grouped on separate z-layers. Clearly, I was doing something wrong.
Floats are positioned to touch other floats, or the containing block, so putting them together sort of makes sense in terms of implementation-driven semantics. However, they can't go 'higher' than preceding elements, and cleared elements will further break them up. I'd expect some sort of lock-step algorithm from top-to-bottom picking out a float and then filling text until the next float -- stacking based on this would make more sense, visually and wrt implementation. Worse, normalization (inserting pseudo-elements until all children are either block or inline..) probably further breaks up relationships between floats. Why isn't it simply the relationship implicit from document structure + explicit z-indexing??
I don't know whether to criticize such a spec or donate money to people who understand why it should be so and then actually go and implement it. And I thought continuations were loopy..
a grad student's tale of survival in the face of absurd web programming models, systems insecure almost by design, disconnected language theories, and the berkeley meat grinder
Thursday, September 11, 2008
Sunday, September 7, 2008
Secure Voting
The thing about security is that it's an end-to-end property. Pick your concerns, pick your model, and pick your budget -- then get at it. The security community loves to analyze e-voting, but seems to forget one of its main mantras. In this case, a secure machine is irrelevant if it's part of an unsecure (social) network.
Disclaimer: I am aware of various attempts to do this -- the comment is primarily directed at the security research community as a whole. In addition, both political parties have a history in voter manipulation; it's an unsurprising and unsolved part of the process. Finally, we're at an interesting point in public record keeping: aggregate information on an individual is dangerous, yet also would be a big boost in our ability to automatically detect abnormalities.
"They want you to think that there’s one problem, which is electronic voting and paper ballots. By the way, that’s also racial. You talk to white voter activists, they talk about computers. You talk to black voter activists, and they talk about suppressing the vote. I want to repeat: There were virtually no computer voting machines in Ohio, and that’s where they stole it. There were virtually no computer voting machines in New Mexico. That’s where they stole it. There were virtually no computer voting machines in Florida in 2000. That’s where they stole it." - PalastStatistical analysis (and automated whistles) on systemic voter registration & redistricting manipulations would hopefully be as interesting as any sort of analysis of the machines themselves, especially given the threat model. This is done by third-parties on economic policies to facilitate day-to-day financial predictions -- given an increasingly (?) global practice of voting, doing so for democratic processes seems like a compelling task. We can detect auction fraud patterns, fake click-through rings, and puppet websites -- why not rampant voter manipulation? It's all public.
Disclaimer: I am aware of various attempts to do this -- the comment is primarily directed at the security research community as a whole. In addition, both political parties have a history in voter manipulation; it's an unsurprising and unsolved part of the process. Finally, we're at an interesting point in public record keeping: aggregate information on an individual is dangerous, yet also would be a big boost in our ability to automatically detect abnormalities.
Friday, September 5, 2008
Subscribe to:
Posts (Atom)