topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Friday March 29, 2024, 10:15 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - db90h [ switch to compact view ]

Pages: prev1 2 3 [4] 5 6 7 8 9 ... 20next
76
Yes, but IE users make up too much of a market share. That's why I indicated to block older versions of IE makes some sense, but newer versions -- that's killing too much of your user base.

Anyway, I speculated about other causes because the OP suggested this was not their true reason.

EDIT: I had concluded that their SSL cert was signed by an untrusted root authority for IE, but am re-evaluating that for older versions. I posted too hastily. Turns out I was wrong, had my adrenaline pumping ;p. The root CA is a branch of Comodo, who is certainly trusted, but I don't know whether that branch is.

77
I can reason not supporting older versions of IE because they had such a problem with rogue extensions (Browser Helper Objects and Toolbars) *and* render content differently than other browsers, including newer versions of IE. Blocking newer versions of IE that render content the same as any other browser and that have essentially 'fixed' a lot of the extension problem by making users aware of what extensions are present is nonsensical though.

Also note that NOT ALL SSL ROOT CERTIFICATE AUTHORITIES ARE PRESENT IN ALL BROWSERS. The newer CA efforts for cheap or sometimes free SSL certs, for instance, certainly are not. The root CA not being present in IE may be the issue here. Without it, every SSL protected page would cause a huge warning. UPDATE: Not the case, at least not with latest IE.

78
Developer's Corner / Re: Random Question (About Hash Keys)
« on: May 08, 2012, 04:27 PM »
Updated last post to mention that I was being redundant, and also explain my 'rogue' redefinition of digests. I really do prefer this, and think it is valid. I don't know that anyone teaches my view that secure hashes should be reserved the term 'digests', but I like it because it makes it clear in conversation the difference between a secure hash and an insecure one, as well as its likely intent. That way, if you say 'digest', you know it must be a secure hash. Saying 'hash' could mean it is as little as one bit (arbitrary size, as mouser said), and therefore come with a huge collision rate... or, from a different perspective, mean its some random algorithm that need not be mathematically secure.

79
Developer's Corner / Re: Random Question (About Hash Keys)
« on: May 08, 2012, 04:04 PM »
And note that when two files or sets of data 'match' as mouser eloquently explained it (much better than I), that is what is called a 'collision', as I tried to explain above. Thus, the collision rate is paramount when determining what algorithm you want to use.

If it need be secure, then you want an essentially zero collision rate, but that comes with high computational complexity and a large bitspace. Thus, in *my* rogue thinking, I prefer to call such 'secure hashes', digests. A digest is a hash, but a hash isn't always a digest. Of course, being irreversible is another important characteristic that applies to both forms. Anyway, it just makes it easier to differentiate.

Update: I see mouser did put (collision) is parenthesis. In retrospect, my explanation assumes the reader knows too much already.

80
Why not just do it like they did in the movie? ;p. Google does similar things. I'm sure they actually do discover some decent programmers, though the questions I'm sure aren't that difficult for a programmer. At the interview they surely give a second, slightly harder, test to make sure you didn't cheat on the first. Then, yea, they tell you they will give you a job and pay you X. The thing is --- if you have these skills, you can get a job at A LOT of places, so do you *want* to work for Facebook, or someone else? This particular segment of the job market is not one that is weak. It has an excess of unfilled capacity.

81
Developer's Corner / Re: Random Question (About Hash Keys)
« on: May 07, 2012, 05:32 AM »
Rewrote for clarity (as always). This sort of information is stuff I should post on my own Forum, as it makes me sound smart, lol. Seldom do customers ask about message digests though, lol.

82
Developer's Corner / Re: Random Question (About Hash Keys)
« on: May 07, 2012, 05:20 AM »
I'll try to be clear (not great at that ;p). There are TWO distinct types of operations here, though they are similar in nature, it is just that one has a larger bitspace to reduce collisions to a near zero possibility.

The terms ARE *often* interchangable in the real world, so either is valid, but I prefer this way of thinking. You can use whichever term you want - just make sure you pick the right algorithm.

1. Hash - short bitspace, collisions can occur
2. Digest - larger bitspace, collisions have near zero probability, designed to be mathematically irreversible by people smarter than me (cryptographically secure)

In practice, this means no two data sets are likely to result in the same DIGEST, so it can be used reliably to uniquely identify a data set. HASHes are used often for quick data integrity checks in the old days, or quick lookups in arrays and databases. Collisions are expected and accounted for.

DIGESTS are usually much larger in length than HASH. Instead of 32-bits, you may be speaking of 128-bits, for example. These are mathematically formed in such a way that no two data sets should produce the same DIGEST.

That is why a password is stored as a DIGEST, and thus when you type in the plaintext password, the DIGEST is computed and compared to the stored DIGEST. In this way, even if an attacker compromised the site or software and retrieved the password's DIGEST, they'd NOT know the actual password. However, that is what 'Rainbow Tables' are for (pre-computed digests of common passwords). These are getting larger all the time. Still, unless you used a word in the dictionary, or some short password, you're likely ok.

Why is it called a 'digest'? Well, think about it -- the data set is 'digested' through an algorithm and out comes a 128bit (or however long) 'digest'.

Example HASH algorithms: CRC32, Checksum

Example DIGEST algorithms: MD5, SHA1

Again, the *terms* HASH and DIGEST are often interchanged in the real world, but that's MY definition. In the real world, you can say either one and be fine.

To web site owners *and* even software authors --- NEVER, EVER store a password plaintext. ALWAYS store its digested form (usually SHA1 or MD5). Sometimes people also 'salt' the outputed digest with a quick XOR or some other operation, just to throw off rainbow tables.

This is the 'one way encryption' I believe you speak of. Does that sum it up? This would be in a CS101 class I believe, it's pretty introductory stuff, some of the first things you learn in college other than OS fundamentals and classical algorithms that still are used to this very day (e.g. search and sort algorithms, or the basics of compression algorithms later).

e.g.:

Last month I created this 'online tool', one of thousands I'm sure, to do a quick MD5 or SHA1 computation of given plaintext:

Calculate MD5 or SHA1 Digest

MD5 of 'mypassword' is '34819d7beeabb9260a5c854bc85b3e44'

All that need be stored is '34819d7beeabb9260a5c854bc85b3e44'. Then when the user types in 'mypassword' the MD5 is recomputed and compared to '34819d7beeabb9260a5c854bc85b3e44'. If match, then all is good. If no match, then it's the wrong password. In that way, the actual password need never be stored. Note that MD5 has been compromised in that it has been shown to produce collisions, as shown here: http://en.wikipedia.org/wiki/MD5 .. Thus, SHA1 is the preference usually .. but it hardly matters unless you're into banking or some really hard core stuff.

83
Developer's Corner / Re: Plugins
« on: May 06, 2012, 05:43 AM »
So some applications don't have a plugin interface at all?

Right. They have no plug-in interface. Most don't, in fact. I mean, that's something a programmer adds if there is a need, not by default.

However, the poster was expressing the possibility that with *MUCH WORK* an external programmer could come in and create such an interface. Without the source code, this requires massive amounts of work, reverse engineering, and even then it may have limitations or be imperfect. The mechanism would involve injection into the process, then modification of the applicable code, on the instruction set level -- making the whole thing also very prone to errors and other risks.

In the case of signed executables, other platforms, or certain protection schemes, creation of such a 'third-party API interface into a program that has no plug-in interface' could be infeasible.

84
Just use multiple software packages/tools at the same time, and have/give them some data to crunch on, that'll put those CPU-Cores to work :tellme: :up:

LOL.. that is actually what it comes down to. There is nothing I *hate* as marketing .. umm.. distortions. I don't want to call them lies, as a distortion can be phrased so that the person interprets it wrong, then its not technically a lie (wonderfully world we live in).

I think everyone gets the point though. I don't want to be disparaging of this company's software at all. It may be that their software offers compelling features. In fact, it offers many of the same features as Process Lasso, though I don't make such marketing claims. They aren't identical though - You'll find lots of features in Process Lasso not in other software, and vice-versa. Instead of marketing them to do miraculous things, these features are for *advanced* users who have specific needs, and under no (or only the rarest of rare) circumstances could a system be tweaked to out-perform its default state with regards to utilization of cores. Exceptions do apply for particular architectures if they are too new for the Windows scheduler. However, the software mentioned here lacks the capacity to improve Windows core management, as XP *is* aware of Hyper-Threaded cores, and that is the *only* deficiency possible for an i7 platform. If this were way back in Windows 2000, then maybe by replacing the scheduler they could really optimize things, but that's a hell of a chore under Windows, and certainly NOT something this software does.




85
The premise of that is simply untrue or misleading, there is no way to 'unlock those unused cores'. They are unused because most operations require another operation to be done before them (they are single threaded, or linear). This creates a condition where there is excess CPU capacity because operation X or Y must be done before Z. I've written more on this marketing myth before. Other than that, I won't go into detail. But if you think that some program can come and 'make use of those extra cores'.. well, that's not going to happen. I wrote more the other day here, under my Myths and Lies section: https://bitsum.com/f...hp/topic,1394.0.html

An alternative would be Process Lasso, it has all the same capabilities - though doesn't make such extraordinary claims about what is possible. However, from what I can tell, that program you mention uses 'foreground boosting', something Process Lasso supports, but does not enable by default because it was shown to be ineffective and potentially unsafe. Windows already does foreground boosting. More info on this here: http://bitsum.com/about_probalance.php

Do not fall for this marketing lie..

86
Living Room / Re: Kickstarter Highlight: PennyGems
« on: April 29, 2012, 06:54 PM »
/shrugs

I found a use for it, and I find it interesting to replace stones and cardboard as currency.  And knowing that there are a lot of people here that play boardgames, I thought it would be of interest.

Hmmm... 10 kickstarter project posts, and the only one that received any comments was negative.  Maybe I should discontinue, as there doesn't seem to be much interest...?

Don't let me put you down. Indeed there might be a market for it. Sorry to be negative, I was just a bit shocked that people bid this idea up to $20k.

87
Living Room / Re: Kickstarter Highlight: PennyGems
« on: April 29, 2012, 05:18 PM »
Love this discussion about KickStarter (see comments): http://tech.slashdot...arter-over-two-years

88
Living Room / Re: Kickstarter Highlight: PennyGems
« on: April 29, 2012, 04:00 PM »
I still don't even know if this is a joke.. I mean, it's clearly something would stand to profit a shitload on.. Manufacturing costs are near nothing, but the novelty of this idea is close to zero. I think ever since the advent of currency it has been drawn on, cut up, or otherwise manipulated. For instance, those 'penny stamping' machines. Its just ... Come on. Really? You want a sticker and a glob of polyurethane on your penny, and are willing to pay for it? Is this an anti-kickstarter joke project? Ok, its no joke ... its just too bad people won't spend money so easily on software, lol. Well, too bad for us software developers at least, lol.

89
Living Room / Re: Kickstarter Highlight: PennyGems
« on: April 29, 2012, 03:44 PM »
Pennies have for a long time cost more to produce than they are worth, but never fear - even if the penny dies, I'm sure nickels will work just fine. On the rest, I'm sorry, but seeing $20k go to penny gems, when they could feed.. I dunno.. starving neighbors .. well, whatever. It makes me want to scream though, and go back to my painted turtle business. I'm selling painted turtles for $100 a piece, for whoever wants one. Just bring me the turtle, the paint, and an artist... oh, and $100.. then I'll have your carefully assembled painted turtle together in no time.

90
Living Room / Re: Kickstarter Highlight: PennyGems
« on: April 29, 2012, 03:35 PM »
bleh .. I'm sorry, it's just in a world where so many don't have what they *need* to survive ... sometimes I find the absurdities of consumer behavior appalling.

91
Living Room / Re: Kickstarter Highlight: PennyGems
« on: April 29, 2012, 03:31 PM »
Sounds like something KickStarter people would go for... $20k, that's insane. But, congratulations to whomever!

92
If not explained, the reason it will print in your browser is because your browser has an independently installed embedded Acrobat Reader, while your primary Acrobat Reader application is apparently missing or misconfigured.

93
Living Room / Re: Selling Domain Names...Is it worth bothering?
« on: April 28, 2012, 03:28 PM »
It depends solely on the domain name and if anyone else wants that domain name. Some domains are worth millions of dollars (e.g. sex(dot)com), others are worth nothing - even though people like to think they are. I've been trimming down my domain portfolio, declaring most worthless to me, or not worth the trouble of selling.

If you do decide to sell, services like GoDaddy make it pretty easy to put it up for 'auction'.

94
There is a *huge* difference between 'encryption' and 'client-side encryption', the latter being when the CLIENT generates and controls the key. The latter is available only at Carbonite, afaik, though maybe this service supports it, and that's what you are saying.

Even Google Drive does not offer client controlled encryption. If this service offers that, then the encryption 'counts'. Otherwise, the encryption is just useful en-route, as when stored on their servers it is stored right along side the decryption key.

Of course, the issue with clients controlling their own key is obvious -- they are likely to lose it, its harder to make things 'just work', etc.. However, for me, that's a pre-requisite to storing anything I wouldn't want publicly broadcast. For standard stuff that doesn't matter much, I don't care.. but for private things, you definitely have to control the encryption key.

Yes, you can encrypt then upload to any service, but then you must download and decrypt it to access the data, making the process a lot more cumbersome than a system that lets you generate and use a local key seamlessly.

I suspect that law enforcement is actively engaged in trying to deter these cloud storage services from offering true client side encryption, as it makes their jobs a bit harder in some cases.

95
A properly configured VPN should allow entirely unbreakable communication between client(s) and server(s). With a VPN, you create a secure, encrypted, private virtual network that can span the Internet. Mail servers would be internal to the VPN, same with web servers.

The security of the clients and servers themselves them comes into question, which worstje went into a bit of depth on.

96
WhyReboot is very reminiscent of my old http://bitsum.com/other.php#movelatr]console mode MoveLatr utility, which not only enumerated pending move operations, but also allowed you to set them (including delete a file). I distributed it with full source code.. a decade ago (EDIT: 12 YEARS AGO). Been a while.

--- Summary of MoveLater (12 years old, it its teens ;p) --

LICENSE: Freeware, Open Source.

MoveLatr (aka MoveLater) is a nice console mode utility: http://bitsum.com/other.php#movelatr. Freeware, and open source at that. You can not only view pending operations by just running it, but also *set* them, including deletions.

Of course, looking at the source code now, it would look a lot different if I coded it these days ;). Though I'm not sure that HTML markup is the latest copy of the source, need to check.

97
Mouser, I think you are underestimating your own success. Sure, if you compare yourself to a company that has actual employees, you aren't generating much revenue... but you aren't a company with employees. Therefore, DonationCoder is extremely successful. That is why I was curious as to the mechanism behind this. I do suspect that there are a substantial number of repeat donators - a revenue generation user base, if you will. Yes, I know, you don't like words like 'revenue'.. but that's what it is.

So, I'd say in the eyes of any beholder it is a success, given what it is, and the resources through which it is run. EDIT: Well, that's pretty much what you said I guess ;)

98
Please do, sorry mouser.

99
Indeed! You know, for a quick formula, that was a pretty good one ;). Anyway, back to work.. I fear I've flooded this thread and Mouser, or anybody for that matter, will not appreciate it. I have *always* been very impressed by this site - what I consider to be a unique oddity in this capitalist world. I mean, freeware and donationware is nothing new, but this SITE as a whole actually WORKS at generating revenue. To me, that's intriguing.

Honestly, when DC was founded, I would have *never* guessed it could generate that kind of revenue.. but I have been proven wrong.

100
Whew, sorry to double post (with an edit, then a repost of content) .. that bible guy got me all interrupted and I lost my train I thought. Man I *hate* it when they show up at your door. They don't just 'go away' either. The nicer you are, the more they talk .. and talk .. and talk .. and talk...

EDIT: Please don't reply to that, we'll get off topic ;p

Pages: prev1 2 3 [4] 5 6 7 8 9 ... 20next