My Security Planet » Tags

Feeds

13620 items (0 unread) in 75 feeds

WebSecurity

Security

SEO

Tools

Opensourcetesting.org News

5 items tagged "design"

Related tags: entitlements [+], architecture [+], Control [+], Access [+]

funkatron.com

Spaz webOS Special Edition Plans

Posted: February 12th, 2011, 12:54pm CST by funkatron

Tags: design [edit]

This year, while doing taxes, I put together numbers on the out-of-pocket costs for maintaining Spaz. These include VPSes on Linode and Rackspace, and paid accounts on lighthouseapp.com. As I posted on Twitter:

Since folks were asking, I received $353.84 in donations in 2010 vs the ~$1700.00 expenses.

I’ve never deluded myself into thinking the Spaz Project was even a break-even proposition: I make enough money in my day job to put some into Spaz, and I never expected to get it back. It’s fulfilling for me and worth the investment to provide a transparent, open option for microblogging users.

Still, many folks in the webOS community have encouraged me to consider putting out a pay-for version of Spaz that people can purchase as a way to support the project. I wasn’t really comfortable with just putting out an identical product like that, but I think I came up with a reasonable value-add: additional themes.

Most users don’t really care about additional themes in an app, but some people LOVE them. I’m one of those people. I’ve always intended to put out Spaz with multiple themes, but work on adding features and improving performance have had higher priority, so I never got around to implementing it.

Recently I finally finished up the theme switching code, and was able to create a new theme. I informally put out a beta with this theme, called “Clean.” I also received a theme from Spaz contributor Will Honey and Bee Rad that mirrors the look of his awesome new audio app Koto Player.

So, my idea is to release a Spaz webOS “Special Edition” with at least 5 new themes (so 6 total, including the default “Dreadnaught” theme). This would be a pay-for download in the app catalog, probably for $2-3. Note that motivated individuals would be able to download and integrate themes themselves if they so desire, and all contributed themes in the Special Edition would be under a liberal license that’s compatible with Spaz’s “New BSD” license.

In addition, I will donate 50% of the revenue from the Spaz webOS Special Edition to @webosinternals. Their tireless work has made the webOS developer community the most open, transparent, and fun in mobile dev. We need to support them so they can continue to be awesome.

One issue that will come up with having multiple versions of Spaz is cross-app launching integration. Apps in the catalog must have unique IDs, so the Special Edition will have a different appid than the “regular” Spaz. I’ll probably put out a simple code snippet that checks for each one, so app devs don’t have to manually try to support all three — that would suck.

If you’re interested in making a theme, all the info is available at help.getspaz.com.

Mozilla Webdev

GetFirebug.com redesign launched!

Posted: February 8th, 2010, 10:03am CST by nlee

Tags: design [edit]
If you’ve happened across the GetFirebug.com web site recently, you’ll notice everything has a rather pleasant freshly painted smell. After a much-too-long delay, we’ve finally updated the design and layout for the official Firebug web site, and introduced a lovely new icon by our resident Iconmaster General Sean Martell.

Even with intense competition from tools integrated into other web browsers, Firebug is arguably still the leading web development tool in use, with nearly two million active daily users. Its web site needed to reflect Firebug’s capabilities more clearly. With that in mind, the primary goals with this redesign were to make the official Firebug web site easier to use, more pleasant to look at, and give Firebug more of a traditional software-style layout to highlight its many positive qualities.
GetFirebug.com: Before GetFirebug.com: After
It’s a fairly straightforward design, so there’s not a lot of interesting production notes to highlight, but here’s some specifics on what went into this redesign:
- The layout is roughly based on the 960 grid system. The original hope was to do the site in a fully fluid layout, but time constrains intervened.
- Headers and pull text are in the gorgeous (and open source!) Tittillium, thanks to @font-face. The body text was originally set in Droid, but due to a legibility issue on Windows machines with text-smoothing disabled, it was switched to the more common Trebuchet MS.
- The pages are build using the HTML5 doctype, with JQuery and the Fancybox plugin powering the modal pop-ups.
- The screencast on the homepage uses the Video for Everybody system to embed the OGG video, with MP4 and Flash fallback for other user agents.
- The homepage blog feed pulls in from the Firebug weblog RSS feed using SimplePie.
- For this iteration, we wanted to switch the site over to a simple content management system, and ended up settling on Perch. It has its shortcomings, but it was straightforward enough and easy enough for me (mostly a designer/UX guy) to implement.
- Sean passed along a few images that inspired the sparkly new icon. Originally, we tossed around the idea of doing something cartoony and heroic, like this lil’ dude, but ultimately decided to go with a more, well, buggier bug.
- Photographic inspiration: Bug 1 • Bug 2 • Bug 3 • Bugs!
It’s been a long time coming, and we hope you like GetFirebug.com’s new set of clothes. The content is currently being updated and will roll out as it is completed, but in the meantime, please kick the tires and let us know what you think.
CSS Gradients Tutorials

Posted: November 30th, 2009, 5:21pm CST by rdoherty

Tags: design [edit]
hacks.mozilla.org has two great tutorials up about CSS gradients available in Firefox 3.6:
- css gradients in Firefox 3.6
- building beautiful buttons with css gradients
- Really awesome stuff, looking forward to seeing more and more designs that are normally done with lots of images to be created with CSS!
CSS Spriting Tips

Posted: March 27th, 2009, 5:36pm CDT by rdoherty

Tags: design [edit]
One of the most effective ways of speeding up a website’s render time is to reduce the number of HTTP requests required to fetch content. An effective method to achieve this is via CSS sprites, which is combining multiple images into one large image and using CSS to only display parts of it.

Here’s an example sprite:

The purpose of this post is not to show how it makes a site faster, but cover some best practices when creating a CSS sprite.
Don’t wait until you are done slicing to begin spriting.
The problem with waiting until you’ve built the site is all your CSS and images have already been created. You will have to go back and re-write your CSS. You’ll also spend a ton of time in Photoshop attempting to fit 20-30 graphics into a sprite at once, which is extremely painful and tedious. It’s much easier to build the sprite step by step.
Arrange images opposite of how they will be displayed
This tip is a little confusing and I didn’t learn this until I was halfway through creating a large sprite. If an image is supposed to appear on the left of an element:

Put that image to the right of the sprite (see sprite image from above). This way when you move the background image via CSS, there is no possible way any other image will display next to it. A common problem when creating CSS sprites is positioning images so they don’t appear as part of a background for the wrong element.
Avoid ‘bottom’ or ‘right’ in CSS when positioning
When positioning a CSS sprite behind an element, it’s very easy to use background-position: bottom -300px; or background-position: right -200px;. This will work initially, but the problem with it is once you expand your sprite in width or height, your positioning will be wrong as the images are no longer at the bottom or right of the sprite. Using explicit positioning in pixels avoids this issue.
Give each image plenty of space
As you can see from the example sprite, many tiny images are given lots of space. Why not just cram them all together to make the sprite smaller? Because the elements they are used on will most likely have variable content and need that extra padding so other images don’t show up.

Here’s an example:

Each list item has a graphical number as a background image. If you look at the sprite shown above, you can see how the images were staggered so that if the content increased, no other images would show up.
Don’t worry about sprite pixel size
Chances are if your site is decently designed, you will have a lot of images to put in your sprite. And you’ll need a pretty large sprite to space the images out appropriately. And that’s fine. Empty space in a sprite does not take up much of a file’s size. The sprite used for addons.mozilla.org is 1,000×2,000 pixels and is only 16.7kb!

Got other tips? Leave a comment!
More Resources
- CSS Sprites Tutorial
- CSS Sprite Generator

Justice League

Externalizing Access Control Quandary

Posted: April 8th, 2008, 10:16am CDT by scott

Tags: Access Control entitlements design architecture [edit]

This entry started as an email to a co-worker: Will. I’ve edited to make it a bit more readable, but in an attempt to blog more often and less formally, I’m only applying the thinnest editing veneer. We were discussing whether (again) moving entitlement/access control decisions out of the application code really made sense. Will was concerned about not making the developer responsible for implementing access control for an interface. I’m putting words in his mouth, but how can one “build in” security if the responsibility for one of the more fundamental security controls is taken away from the developer?

The notion of externalizing the access control is spot-on from a design standpoint. There are many reasons to externalize and one can argue that many of the problems with web application security is that the auth/auth got shoved into the application and the application developers were not qualified to write such code.

I think what was making Will nervous was the question of WHO makes the decisions when configuring this externalized mechanism. It’s also the case that WHEN do these configuration questions get handled. The answer to date is that there is some sys-admin or app-admin that does this after the application is deployed.

Historically, this hasn’t been done very well and/or the RBAC systems put in place to configure and manage such auth decisions have been notoriously difficult to administer at scale. I will, however, say that one of the arguments for externalizing the mechanism is that the job of implementing auth/auth requires more than the PDPs/PEPs in the app; it’s all of the additional software for managing/updating the PIPs where the bulk of the work resides in building a robust access control mechanism. Again, the app-dev guys aren’t the best person to write all of the management software and you wind up with the problem where administrative functions is just a series of configurations handled through a command shell or your favorite editor.

This still doesn’t properly answer the question of WHO. Admins don’t have the knowledge to properly configure and the developers don’t have a proper notion of who should be using the interfaces they create.

This is really an architects job, but while the architect has the breadth of knowledge to make the decision yo (trying out this new gender-neutral pronoun) lacks the tool to understand the actual interfaces that exist. The architect will have pre-defined about 80% of the actual interfaces, but the implementers will have created others to solve implementation level problems. So, 20% of the interfaces will be entitled without much thought.

So, let me make another point of externalizing the auth/auth mechanism. That is what we need here is a tool that can turn all of the code into (UML) descriptions of all the interfaces. We need to decorate that list with the entitlement data, but we can only do so if there is a canonical way for the tool to read the entitlement information about said interface. If we can do this, now we’re cooking with gas since we could then write some kNN-like algorithms to compare each interface with other interfaces like it so we could see where there are potential, logical inconsistencies.

Technorati Tags: access control, entitlements, design, architecture

TOP RSS Gregarius 0.5.4 Tentatively valid XHTML1.0, CSS2.0 Last update: Thu May 24 12:14:11 2012

My Security Planet » Tags » design

Feeds

5 items tagged "design"

Posted: February 12th, 2011, 12:54pm CST by funkatron

Tags: design [edit]

Posted: February 8th, 2010, 10:03am CST by nlee

Tags: design [edit]

Posted: November 30th, 2009, 5:21pm CST by rdoherty

Tags: design [edit]

Posted: March 27th, 2009, 5:36pm CDT by rdoherty

Tags: design [edit]

Posted: April 8th, 2008, 10:16am CDT by scott

Tags: Access Control entitlements design architecture [edit]