Re: [Full-disclosure] Bug 718066 - [meta] Add feature to submit anonymous product metrics to Mozilla

[Martijn Broos]

Hi,

I can imagine that developers want to have a clue what they need to repair.
I only have a problem the way they do it and the way my behavior is exposed 
without possible influence.

Let's say for the sake of argument, that 20% on similar hardware have a problem 
with loading times and the developers have the metrics to prove so (waiting 
times, load times, scripts I use,  etc...)
Would the conclusion be, that Firefox is at fault?
- What if the major part of that % is living in a certain continent?
- What if the major % has the same ISP?
- How is the spread of OS usage?
- etc, etc

Without the surrounding parameters known, you have a pile of bytes instead of 
DATA (people tend to mix those definitions). Of course you could make "fuzzy" 
statistics out of it, but like most mathematicians know: statistics prove 
predetermined conclusions.

Still would a 5% speed increase weigh up to the privacy of 200 million users?
Like in the bugtrack stated. If my instance of firefox is PII bound, you can 
trace my laptop, determine behavior, etc...
And to conclude: Modzilla states they don't intent to use the data in any other 
way:
I have a couple of  questions about the intent:
- Will that intent stay the same throughout the future? The intent can easily 
be changed when money gets involved.
- What if a legal entity (like a government, The Music branch protectors(to 
prove that the piratebay is used so often), etc...) "kindly" requests the data 
with a court-order?

Also take into account the following:
Since 2012, the Netherlands has a new law which forbids behavior analysis by 
persistent cookies...All advertisement companies are now looking into device 
identification.
Why: they can make more money when they show you the right adds.
Modzilla will help them a great deal if they can offer them a PII out of 
stock... And I see the comments, they won't do that! Do you want to bet 1 
million bugs over it that they won't do it?

-Original Message-
From: full-disclosure-boun...@lists.grok.org.uk 
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of 
valdis.kletni...@vt.edu
Sent: vrijdag 10 februari 2012 15:48
To: Nick Boyce
Cc: full-disclosure
Subject: Re: [Full-disclosure] Bug 718066 - [meta] Add feature to submit 
anonymous product metrics to Mozilla

On Fri, 10 Feb 2012 03:51:53 GMT, Nick Boyce said:
> OT: They should just make FF quality high and the design impeccable -

"Quality high" is always a nice concept.  But there's always 5 quality issues 
and resources to fix only 3.  Obviously, you want to fix the 3 that matter most 
to your users - but which 3 are they?  You really can't rely on bug reports or 
surveys, because those tend to have a major self-selection bias.  Think about 
it - how many people do you know that use Firefox?  How many of them have had 
it crash or misbehave?  How many of them *reported* it?  Surveys have the same 
problem - you can't easily run a survey of users who just want to hit their 
sites and *do* stuff and find out what they want - because they'll just skip 
your survey, hit their site, and *do* stuff.  Unless of course you make the 
survey mandatory - in which case you tick them off because you got in the way 
of hitting their site and doing stuff.

Or "report the list of extensions and performance numbers" -  it's one thing to 
know that users have a range of launch times.  It's something else to know that 
20% of users have *consistently* longer launch times on comparabie hardware.
But if you have data that shows that NoScript users take a 15% launch time hit,
*that* is something you can then go do something about.

Similar problems for "impeccable design" - if you want a browser that Joe 
Sixpack will actually *use*, then you need data on how Joe actually wants to 
use that browser.  And *asking* Joe never works - anybody who's had to do 
project requirements will tell you that what the user *says* they want, what 
they *think* they want, and what they actually need, are almost always 3 
different things.

No, I'm not saying it's OK for the Mozilla crew to collect PII like that - but 
I can certainly understand why they feel the temptation to do so...



DISCLAIMER : This message is sent in confidence and is only intended for the 
named recipient. If you receive this message by mistake, you may not use, copy, 
distribute or forward this message, or any part of its contents or rely upon 
the information contained in it.
Please notify the sender immediately by e-mail and delete the relevant e-mails 
from any computer.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Fwd: Rate Stratfor's Incident Response

[Martijn Broos]

Most of the problems start already at education. There is not enough focus 
during school time what security beholds and what consequences are of bad 
design, bad programming, bad architecture and bad security principles.  I know 
schoolbooks that even don't mention security at all or is explained within 2 
chapters (let say 20 pages) of a 1000 pages book. This also includes PKI and 
encryption. Security is only taught by trial and error apparently nowadays. And 
after you have burnt your fingers a few times you hire an expensive guy who 
does less kiddies do but give you more of a good feeling.
If programmers are aware of security consequences, they would fix them in the 
first place or try to avoid them.
Using kiddies is merely showing the terrible state your programmers level is. 
When you have engineers that are security aware, lesser exploits will be found. 
You still would look for them anyway because trust is good, prove is better in 
this scientific world.  In general testers are regarded as lesser people, but 
imho you should encourage them to try to break your code. At least that is what 
I do as a software engineer. After they break down my code, my first response 
is, thanks how did you do it, so I can update my skills as well. But this is 
all before production off course.
Yes, you can use them but make sure you know where their loyalty lies.
So I vote for the use of kiddies (only in a controlled test environment). This 
could even be a public test site where this list could try to break the stuff 
as long as you tell me how you did it:) I know this takes the fun out of it for 
a few, but hey you cannot please all people in the world.

From: full-disclosure-boun...@lists.grok.org.uk 
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of E M
Sent: maandag 16 januari 2012 21:47
To: noloa...@gmail.com
Cc: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Fwd: Rate Stratfor's Incident Response

I would say that we need both types: the skiddies and the others.
If you give to the skiddies enough fun at work they won't do something beyond 
the scope.
But their scope should be: I have a site/system(of course, the test one, not 
the production one!) break it!
They do it without being evil, even if they break itthe job was to break it 
in the first place.
Then the other security guy should go to the management with the pwnd dummy 
database/data and show them how bad it would be if it was the real one, and how 
easily it could be done.
Maybe this way the management provides more funding to the security of the 
business.
So, yes, hire the skiddies, but keep the other too.


From: Jeffrey Walton mailto:noloa...@gmail.com>>
To: Laurelai mailto:laure...@oneechan.org>>
Cc: full-disclosure@lists.grok.org.uk
Sent: Monday, January 16, 2012 9:58 PM
Subject: Re: [Full-disclosure] Fwd: Rate Stratfor's Incident Response

On Sat, Jan 7, 2012 at 6:03 PM, Laurelai 
mailto:laure...@oneechan.org>> wrote:
>
> Perhaps these companies should try to hire the kids owning them instead of
> crying to the feds.
Perhaps Stratfor's competition should hire them. Nothing new, there:
the Eastern Telegraph Company hired Nevil Maskelyne after he hacked
Marconi in 1903 during a demonstration of wireless telegraphy. [1]
(Wireless hacking since 1903!).

[1] 
http://www.newscientist.com/article/mg21228440.700-dotdashdiss-the-gentleman-hackers-1903-lulz.html.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/




DISCLAIMER : This message is sent in confidence and is only intended for the 
named recipient. If you receive this message by mistake, you may not use, copy, 
distribute or forward this message, or any part of its contents or rely upon 
the information contained in it.
Please notify the sender immediately by e-mail and delete the relevant e-mails 
from any computer.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] distributing passwords to users

[Martijn Broos]

Ok, You have been harsh enough on the poor solution the user is going to choose.
Are you willing to give him some advise or directions where he should go to?

A textbook sentence I always learned was: You can burn a person with many 
words, it is better to help him with few in the right direction!

If he doesn't know what he is doing wrong, then how do you think he will learn 
to do it right the next time. He is clearly asking for advise.

Are there standard solutions for managing passwords which need to be used by 
many users and securing them without telling the real password to the user who 
needs one to impersonate as another user?

Kind regards,

Martijn


From: full-disclosure-boun...@lists.grok.org.uk 
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Gage Bystrom
Sent: woensdag 7 december 2011 9:38
To: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] distributing passwords to users


O.o and you act like what he wants is a good thing? Getting /any/ service 
account with that file would be better than pillaging an entire server of ssh 
keys. With ssh keys you know you only got access to a few more servers on the 
network, maybe not even root or admin unless you got lucky and score the key 
used for root/admin for every single box. No, with that you score the entire 
clientele...

Not to mention what you described is not what he is asking. He wants to 
distribute the passwords to multiple users(idc if they are hashed, encrypted or 
not, just minor details at this point). What you described is a centralized 
database. There's only one copy of the file, only one server that holds the 
goods, the rest can have tidbits and if compromised can do minimum damage. 
Coupled with the right motivations and logging then attacking the support group 
on the internal network gives you almost nothing.

Conversely attacking a single user holding the password file for the OP is end 
game. You're simply not going to be able to secure multiple copies of the same 
file with different access controls(hey I used a textbook phrase :) ).

The only alternative is to have one access control, or all users have the same 
permission. However that is also absurd, you're only multiplying your attack 
service with each added user.

Maybe now ya see where I start wondering where the cognitive dissonance ought 
to be coming in for attempting what the OP is trying to do? I was wrong for 
assuming it should be obvious from the get go, but as you can see the ISP 
wasn't in the same boat he wants to board. They would be sitting in the crows 
nest wondering why the loonie on the deserted island was trying to paddle it 
home.

Alright, I think I've been harsh enough on the poor OP, but I hope he 
understands that this is a classic case of "You're doing it wrong". He knows 
what needs to be done, but his method of doing so actively works against his 
goal.
On Dec 6, 2011 10:51 PM, "James Condron" 
mailto:ja...@zero-internet.org.uk>> wrote:
An ISP I worked at stored logins for customer servers where the customer 
required us to be able to login to provide support.

We used a webapp on our internal network with the relevant security 
accoutrements. Its pretty standard; you login, find the server you need 
credentials for and hit a button to either launch a putty session or an RDP 
session. You can also edit passwords or view for non-windows users.

The reason tools exist is because there is a demand for them- hell, its a 
password safe. Perhaps OP should look at this type of solution.

On Wed, Dec 7, 2011 at 6:28 AM, Gage Bystrom 
mailto:themadichi...@gmail.com>> wrote:
I'm disturbed in the first place that you want to distribute password
lists to multiple users.
I'm disturbed more so that there is no apparent cognitive dissonance
preventing you from functioning enough to have sent that email.

Someone please tell me that I'm not the only one disturbed here? And
if I am, point to me why please?

On Mon, Dec 5, 2011 at 7:30 PM, G V 
mailto:gvasi...@gmail.com>> wrote:
> Hi,
>
> From your experience, what's the best secure and easy way to update a
> password list and distribute it to 1000 or so unix users? The users
> would have different privilege levels and different access on network.
> Throwing ideas, I can think of: pgp (difficult to maintain a separate
> file for each user), web app (would need to be sucured over ssl,
> possible password protected), usb disks (difficult to manage changes).
> Anyone using an enterprise level app (commercial or not) to "share"
> passwords to users, manage changes and so on? Any other ideas I can
> use?
>
> Thank you,
> George Vasiliu
>
> 
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL 
> certificate.  We look at how SSL works, how it benefits your company and how 
> your customers can tell if a site is secure. You will