thebruce0

900?? ok, it's getting tighter... I'm currently at ~60 and I haven't broken 500 yet... the trick is just GETTING to the caches, as I have no car, and must rely on friends, or vacations =) I'm fighting for it! So very fighting for it! I'm just glad I've already knocked off the 5/5

completely agree. Though on the other hand, by that definition one could still consider Rocky View a 2.5/4.5 legitimately because that's what it was rated when you did it, and really shouldn't be guilted into feeling like one is 'cheating' by doing so Honestly it doesn't matter that much to me, but I think this point applies more to what Keith Watson was concerned about the 'rules' for the challenge. Technically there are none, it's just a fun challenge, so it shouldn't be necessary to follow to Tequilas own rules even as the CO, based on the updated rules at GC. So... whatever I could understand either reason, legitimately, to use Rocky View as 1.5/4.5 (because that's what it was originally) or 2.5/4.5 (because that's what it was when I started looking for it and when I did it). I haven't decided which to use it for at this point because I don't have either combo, hehe, so it doesn't matter much to me... ah well. too much controversy...

@ Tequila - understood, just wanted to clarify the wording of your previous comment Perhaps for people in the future, if there are issues with changed ratings, list the exception in the cache description, just so that people who don't visit this thread won't think they've finished the matrix when in fact one or more of the caches don't count, unbeknownst to them. It would clarify a situation like this too, much quicker. And obviously that would only happen when the issue arises (you can't know the original rating of every single cache, of course) tnx again (just got to remember now that it's 1.5/4.5 only for T81, but not for the fizzy or other challenges)

So people who found it as 1.5/4.5 treat it as 1.5/4.5 - if we find it now as 2.5/4.5 should we record it as 2.5 or 1.5?

This is not a Microsoft problem. This is HTML standard. HTML provides the password field, and the form submission simply sends form data plaintext in a post request back to the server. It is entirely up to the web dev team to determine what level of security is optimal and feasible on the browser and/or server given the site's implementation, costs and content. This. Honestly, in my opinion it is over-paranoia, the likes of refusing to fly for fear of a crash, to expect and demand that every website offering a user/pass login form implement full security, hashing and encryption, on any and all remotely sensitive data transmission to/from the browser. In GC's case, if https is up and running, that should be sufficient for anyone worried about their login and pass getting sniffed in transit from the browser to the server. Just update your bookmarks to https:// instead of http:// As I said above, if the database gets hacked, logins are the least of my worries. It's simple common sense these days NOT to use the same passwords across sites, or at least use unique passwords on sites that contain sensitive information you personally want to ensure is protected on your part.

d'oh, I can't remember which thread - but did I report here the problem with Firefox and HTML comments including a username with "--" breaking the description page? sample cache for username "indiana--gibbs" the "--" should be escaped in the page source's HTML comment tags... (also, I'm viewing with FF3.5.7, and it works with IE7/8 and Chrome) If you view the source, you can see (if you're using the colour coded source viewer) where it's recognizing the extended comment due to the "--" and where it's ending the comment.

uh, no, every single cache page has ability to provide custom descriptions - whether selected as HTML or not. On the server end, every page is generated with custom user-designed content. Even if you ignore caches that are not toggled a 'html description', I'm positive it's FAR more than a "very low percentage" The problem here isn't simply correcting bad html, but recognition that any number of users may have supplied bad html, through whatever tools they used to create it, and the site (even HTMLTidy) has been effectively ok with it for years. And so there is a well-grounded and accustomed significant user base with potentially bad html. Thus, any roll out of a major design change MUST recognize that the custom-created cache descriptions for a potentially significant user-base will become botched. If GS rolled it out knowing that, then fine - I still think that was a dumb business decision. But if they didn't think of that, or beta testers said "all's good with me" instead of thinking about the customer base a whole - I would have a major problem with the process, at least as the beta test is limited and focused, and not a general public beta. And by knowing the details of the update, I mean specifically realizing that a global CSS change will affect custom HTML - especially bad html - for any number of user-generated content pages. There's still no getting past the fact that there was no public, global notice of the change (acknowledging all of the above - user-gen content and the potential effects of the design updates on it) before it happened (and I don't mean a relatively hidden thread somewhere in the forums that a tiny fraction of users frequent let alone use). All that said, I realize what's done is done, and the crew is working hard to rectify the situation as quick as possible. I'm not whining, I'm simply pointing out where a process could have been carried out better in order to satisfy and prepare the paying customer userbase, and assuage any possible anger against Groundspeak.

Yeah, there are two types of 'new line' character codes, and notepad by default handles the windows standard... so lots of plaintext (I find usually created in linux) is strung together in notepad when pasted. Wordpad understands it, so my standard practice is also just that - copy and paste mis-formatted notepad text into wordpad, then re-paste it into notepad; that should fix it 99% of the time

Update info is much appreciated, Nate. And yeah, since my joining in May, I must gives props for the quality of data management and control with GC.com. If you need another beta tester for future releases, I would be more than willing to help out as a web application developer and web designer. =)

The testing should have included more than simply 'looking' at some cache pages. If I were rolling out an enormous design update and I knew that 99% of pages on the site contained custom user-generated HTML, viewing a few of those pages would certainly not be sufficient. If I were a tester, I would want to know what the changes were and how those changes would affect custom generated HTML (or as the developer, I would provide that information to the testers). Playing 'ignorance' to the scope of the update doesn't cut it, IMO. As I like to say, the problem isn't so much that they did anything wrong, but rather stupid from a business sense (even if only for the lack of warning), upsetting a number of paying customers. I feel for people who do have oodles of caches to maintain whose content is now broken - even if they use utilize badly formed HTML. It was a dumb, ignorant (unwittingly, perhaps) business move on Groundspeak's part. That's all I'm saying...

That I can agree on - encourage users to upgrade from IE6. I also detest it. I was referring to the statement about shunning IE altogether. Heck, if I did my research and found that a significant number of my users were using IE6, YES, I would still do my best to support it in some manner. Even if it meant polling to find out how many of them are consciously choosing NOT to upgrade, and then base my minimum requirements on that number. But simply saying "no IE because we don't use it and no one should" is ludicrous (yes I realize that's not what was said, but it was implied )

Ok, see here we agree on some things. But here are the weaknesses: Encryption: if it's cracked, all is decrypted. Hash: More than one possible solution (even highly complex hashes) For most things, I wouldn't care (as posted above, most sites require logins I rarely visit, so having similar/same passwords for those - meh), but for places like banks: 1) If they use encryption which is "easily" broken, this is BAD 2) If they have servers that get hacked, and encryption that's broken, then how my password is stored is the least of my worries. 3) I would love to see encrypted, hashed passwords sent securely between browser/server behind firewalls, encrypted firewalls, encrypted ciphers, whatever. The key thing to remember is that EVERYTHING can be reverse engineered, and the minimal level of security that is 'satisfactory' for any kind of website database and/or client-server communication really is entirely based on context. GC - I'd rate it lower-mid on required minimal security. Anything more is great, but here, concern about https, secure password transmissions, encryptions (or lack thereof) vs hashing in the database - IMO not as important as just encouraging people to use unique passwords if they're worried, in this case. Like I said, if someone's already hacked into the database (presuming logins are in the same database as the rest of the site data), then logins are the least of my worries. But that's just MHO.

Yes. I know the basic syntax for an HTML comment. I also implied the double-dashes should be escaped, if only because Firefox (not chrome or IE) recognizes the pair of lone dashes as a comment sub-delimeter, however it won't uncomment when it reaches the actual comment end bracket, but rather keep going until it reaches the next lone double dash, then the next comment end tag. eg, in this case (with a brace instead of html bracket) (!-- comment --) is typical (!-- comment1 -- -- comment2 --) is technically valid here: (!-- comment with--inside the text --) SHOULD be valid, but Firefox ignores the end brace (and, apparently, the end "-- ") until the next comment containing "--" not attached to a brace. This is the problem, spelled out: Regular HTML (!-- comment with--inside the text --) standard HTML but hidden and still considered to be comment (!-- comment with--inside the text --) back to regular HTML. Neither Chrome nor IE render the cache page in this way. Whether that means that Firefox is the only one interpreting the standards correctly, or it has a bug, I don't know. Regardless, the cache page isn't rendering correctly due to the text of a member username. It's a legitimate unexpected bug that exists due to a browser quirk, and something that can easily be fixed, by escaping any "--" within generated HTML with user-generated dynamic text. No professional web developer or web application programmer ignores a significant user base in their target market, especially for a website where the vast majority of users are NOT tech-literate. I would not trust your IT acquaintances to build a massive publicly usable website, let alone one people pay for, and ignore IE, just because your IT acquaintances "don't use IE".

Actually, with a large following of paying members, I say the site it's "their site", but rather that we paying members are like share holders... we pay for a service that we like. They change it, making their paying members upset for whatever reason (at least, a large, vocal segment), and that is NOT good. They may have made the site, but in opening it up for financial support and membership from other people, those people now become part of the 'team', if only because it's their money that funds the system. Even if you don't think it's a Bad Idea, it's still a Dumb Idea if the result is loss of membership, or a greater barrier to entry for new membership. TPTB gotta be smart when there are people investing in your service.

QFT.

Bug! Ok, so I just got home, and for some reason Firefox is not displaying cache details correctly. The right column is missing, and the contents of the left column are below the main content... other pages are fine, but this cache is just incorrect... hmm... looked at the source... this seems like a once-off bug that, well, is understandable. Not sure why I didn't catch it before. The commented text Description Written By: indiana--gibbs with two dashes in the owner name (this effect occurs on all their caches right now) is fudging up the comment. It may be a Firefox thing (I'm on v3.5.7) but it looks like if it sees "--" in the comment text, it'll continue on until the next "--", ignoring the actual comment end tag. The comment, which now contains a huge chunk of HTML content, ends after the next instance of the owner name followed by the comment end. Does that make sense? View the source in Firefox, and you should see how much of the page is 'commented out'. The only reason I can think why this didn't happen before was perhaps that the user name wasn't included in the comment tags... dunno.

Aye, I was meaning more about viewing the page in general for others' icons. But adjusting your own is a great start

Perhaps the icons should just be wrapped in a faint border to enclose them, and 'hide' the solid white backgrounds... just a minor workaround. Or the column itself could be entirely white background while the other column rows alternate... *shrug*

well put But once again, it's a tradeoff. The possible password keys that match the MD5 checksum is no longer one. So, yes, while hashing a password in a database does mean that no one can look at the password and know what it is. But it reduces the security because more than one phrase can produce the same MD5 result. Having the password stored as a hash in the database is, by itself, not sufficient security, at least for highly sensitive content (such as bank logins). For something like GC.com, sure. And actually, I would seriously raise concern if my password were stored as a hash in a banking system as well, precisely because it's no longer a single password that will work, and my login is less secure (even though the password itself is never transmitted anywhere except my own form submission to the web server). Point being: There is a time and place for both forms of password 'security'. Encryption is more overhead but remains a unique password validation. Hash/Checksum/MD5/etc is less overhead but more 'passwords' are now valid. For brute force attacks, the latter is far less secure. Anyway. Yeah. This isn't a banking system. I'm not concerned about sites that 'know' my password - if so, they'd just better have proper security on their servers so they don't get hacked. But that goes the same even for encrypted password databases, so... yeah. When it comes to transmission security, https is encrypted communication between client and server. Anything outside of that, in theory, yes could be watched and intercepted, but it's super paranoia to shun any site that has a user/pass login form without using https. Just be smart with your logins and passwords, and breath easy

MD5 is a checksum. Just like on a puzzle cache, it's a simplified "test" to compare a requested string with the original string. Think about it like this... If I have a checksum on the word ALPHA being the sum of the letters, the value is 1+12+16+8+1 = 38. But how many words have letters that sum to 38? If I reduce my password to a checksum, I increase the number of possible solutions. MD5 is FAR more complex than the example above, but the practice is still the same: a checksum is the reduction of information to some degree. It's the loss of the original (ie, "38" is stored, not "ALPHA") so there's no way to check that any other checked string IS the original string, only that its checksum matches the stored checksum. If my password is stored as checksum "38", then I could also enter "HALAP" and the server wouldn't know the difference because it seems Checksum(HALAP)=38, login OK. In short, checksum removes the original, but increases possible matches. Encryption retains the single match, but also means a decryption algorithm exists somewhere. And any place that does proper security relies on highly complex encryption, not checksums, let alone MD5. Which is not to say MD5 is useless - it has its place, but it's certainly not "safer" than encryption.

This is standard practice however*. If you're referring to the non-use of https, that's an understandable concern. But user/pass logins with form elements is everywhere, and other than secure 'NT' login popups, there's no other standard way to handle website session logins. That, again, should be the least of our concern as users. What you describe is a weakness across all sites that have a username/password login form not on an https page. Honestly, inconsequential, IMO. Don't worry about it... you may have more reason to worry if it were a bank that weren't using https * using a password style input box that is, not an clearly visible regular text entry box for a password which is BAD BAD BAD, even though from the http request standpoint, both a standard text field and a password text field are both submitted to the server in the same way.

On the server end, sure. But if they can read server end source code, they have access to the server, and I'd be worried about more than just the passwords. No, if the passwords are encrypted, the encryption algorithm if located in the server-side code, is as secure as any other sensitive code. If they get access to the database (presumably not where the algorithm is stored) they won't be able to decrypt passwords, though they may already have access to everything else. In theory, a hash is LESS secure than you think (as mentioned above) - because more than one source text can arrive at the same hash. Store passwords in hash, and you potentially have more than one possible 'password' making brute forcing easier. Encrypt the password though, and it's still one-to-one. In short, encryption is vastly safer than hash, so don't worry about it...

I vote for 1.1em Default line spacing really is enough... if it's for readability, a tad extra space can help, but not much should be needed. Larger font size is more appropriate in such cases than more line spacing. And even then, accessibility overrides (or greasemonkey-like post-scripting) can adjust it manually at the browser-end.

I think you're wrong on this one point here. This is why I said 'beyond extreme instances' - precisely what you described. Generally, browsers are by default set to refresh a cached page if the modified date has changed* in the http headers, otherwise it'll use the cached version. afaik, users have to manually set the browser to always use the cached page (else force a refresh). Dynamically generated pages tend to automatically provide the current date/time as the last-modified header, meaning unless default browser settings have changed, the page will in fact automatically refresh. So, the extreme cases are where the browser is set to not update the cached version even if the last-modified date has changed, or if there's a problem with the browser doing so. In which case, yep, force the refresh. Which doesn't change the point - making an update that requires a user to manually empty/refresh the cache, let alone without globally informing users they may need to do that (and how to do so, presuming everyone just knows or will try naturally) is not good form. * various browsers may have alternate/additional methods for determining if a page content has changed by using http headers, like comparing file size, hash, etc. Either way, an http call includes headers as part 1 and the body (optionally requested) as part 2. Forcing a refresh means ignoring any header comparisons, and downloading the body all the time. /endhttpclass =P

Design issues are subjective, though it seems a majority of responders in the forum don't like it. Unfortunately for many there are still blatant bugs - some in the backend programming, some as an effect of the visual changes (browser compatibilities and such). But I think this thread is mainly for the subjective opinions about the distaste of the new design, rather than actual bugs