![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Uniquely defining an HTML element
Jun. 28th, 2011 04:42 pmAs some of you may know, my last paper was on visual security policy (ViSP), a neat idea I had about how to add security policy to a website in a way that was more in line with how sites are designed. I based it on my own knowledge working as a web designer, as well as ideas from a variety of friends who have or do work in the web space professionally and not.
You can read my presentation the larger run-down or read the paper, but the idea behind ViSP is that it's sometimes very useful to subdivide pages so that, say, your advertisement can't read your password, or that funny video you wanted to embed doesn't get access to post blog entries, or whatever. Sadly, right now anything embedded in the page gets access to anything else unless some awfully fancy work has been done to encapsulate parts of the page. (And given how much people tend to care about security in practice, this doesn't get done as often as it should.) We currently just trust that any includes will play well, which is super awkward since malicious code can be inserted into around 70% of websites and you can't very well expect malicious code to play nicely.
Anyhow, I digress.
I'm updating this particular policy tool so that I can generate some policies to test, because I'm tired of building them manually, and my not-terribly-scientific method of clicking randomly on things to make policy has turned up a problem: what happens if you want to set policy for an element that's just one of many paragraph tags or whatever, not assigned an id?
With ViSP, we assigned an index based on how many such tags we'd seen, but I figured while I'm updating this surely I could find something more standard...
Turns out, no, that really is the best way to do it. At least according to the selectors API, which includes a nth-of-type() pseudo-class that seems to do pretty much what I want.
So now, if you're using my tool and wanted to define policy for a given tag, any given tag, we can make that work for you by building up a CSS selector to find it. Of course, it'd probably be cleaner to read if you only set policy on tags with ids or classes, but I don't have to require that as an additional hurdle to policy creation. I figure this is likely a net usability win when it comes to policy generation, and let me tell you, security policy is not a field known for usability wins. (So much so that if I google search for the words security policy and usability... I see a post by me on the front page suggesting usability studies on CSP.)
Anyhow... Thanks to having to learn querySelector earlier, I was already primed to create querySelectors for uniquely defining tags. Thanks Mozilla documentation! You're a terrific coding wingman, introducing me to all these awesome apis. ;)
You can read my presentation the larger run-down or read the paper, but the idea behind ViSP is that it's sometimes very useful to subdivide pages so that, say, your advertisement can't read your password, or that funny video you wanted to embed doesn't get access to post blog entries, or whatever. Sadly, right now anything embedded in the page gets access to anything else unless some awfully fancy work has been done to encapsulate parts of the page. (And given how much people tend to care about security in practice, this doesn't get done as often as it should.) We currently just trust that any includes will play well, which is super awkward since malicious code can be inserted into around 70% of websites and you can't very well expect malicious code to play nicely.
Anyhow, I digress.
I'm updating this particular policy tool so that I can generate some policies to test, because I'm tired of building them manually, and my not-terribly-scientific method of clicking randomly on things to make policy has turned up a problem: what happens if you want to set policy for an element that's just one of many paragraph tags or whatever, not assigned an id?
With ViSP, we assigned an index based on how many such tags we'd seen, but I figured while I'm updating this surely I could find something more standard...
Turns out, no, that really is the best way to do it. At least according to the selectors API, which includes a nth-of-type() pseudo-class that seems to do pretty much what I want.
So now, if you're using my tool and wanted to define policy for a given tag, any given tag, we can make that work for you by building up a CSS selector to find it. Of course, it'd probably be cleaner to read if you only set policy on tags with ids or classes, but I don't have to require that as an additional hurdle to policy creation. I figure this is likely a net usability win when it comes to policy generation, and let me tell you, security policy is not a field known for usability wins. (So much so that if I google search for the words security policy and usability... I see a post by me on the front page suggesting usability studies on CSP.)
Anyhow... Thanks to having to learn querySelector earlier, I was already primed to create querySelectors for uniquely defining tags. Thanks Mozilla documentation! You're a terrific coding wingman, introducing me to all these awesome apis. ;)
