terriko: (Default)
[personal profile] terriko
As 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. ;)
From:
Anonymous (will be screened)
OpenID (will be screened if not on Access List)
Identity URL: 
User (will be screened if not on Access List)
Account name:
Password:
If you don't have an account you can create one now.
Subject:
HTML doesn't work in the subject.

Message:

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org


 
Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.

Profile

terriko: (Default)
terriko

August 2014

S M T W T F S
     12
3456789
1011121314 1516
17 181920 212223
24 2526 27282930
31      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 1st, 2014 07:29 am
Powered by Dreamwidth Studios