thebruce0

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

And this is the crux of the issue. "Adjust your monitor brightness" isn't a fix. "Upgrade your browser" isn't a fix. "Try a different browser" isn't a fix. "Clear your cache" isn't a fix (at least beyond extreme instances). If, without these 'user fixes' the site is supposed to still work, but doesn't (read: rather than outright stating user end software requirements), then the site is not optimal, and complaints about design, especially after a major update like this, are all perfectly legitimate. Quite often a website will make changes, and other user-generated scripts based on the previous design beak, because the programmers didn't notify people ahead of time. While that in itself is not a 'fault', it definitely serves to stir up a hornet's nest, and how the team deals with the response is key. Especially for a website with paying members. It's like share holders. They have to know what's going on and when, at the very least, if they don't have a say in the decision, or more than likely they'll bow out and take their ball with them. Notification, of any kind, before the update would have been awesome. A 'public beta' of the new design would have been awesome. Heck, a little notification header on the website template as a whole describing the current status would be awesome. My thanks to the developers perusing the forum who are updating us with the status of changes, and which bugs and whatnot have been looked at... perhaps someone could update us as to which are "in progress" or "being reviewed"? There's an enormous amount of repetition of concerns and bugs general fury - if we knew these concerns were heard and being address in some way (whether the answer will be no, yes, or maybe), even if they haven't been touched programmatically yet, then it may allay many the paying members' frustrations. But definitely - keep us updated on the fixes to the site as they're rolled out. And please, please, please keep in mind that geocaching.com is a paid service with loyal paying members. Tripping people up the way this update was done was, honestly, bad form. And yeah, I would say the vast majority of members don't[/] read the forum, let alone subscribe to any release notes threads or discussions. I peruse the iPhone forum occasionally, and I had to dig a bit to find this particular thread about the changes. There was no email notification, no link to an explanation, nothing shared publicly - information was entirely "pull" on the part of the user, not pushed to us from the developers. Now, on a positive note , I have noticed a speed increase on the site, which is great. it 'feels' lighter, even if I detest the changes to the visual design . As a webapp developer myself, I completely understand the need sometimes to have to go back and adjust some of the basic programming in order to improve some of the surface programming which may have a butterfly effect on other components of the application as a whole, but when that happens, there's just got to be some fallback procedure or public testing process before rolling it out officially. Now, if the GC iphone app were a complete interface to current cache data, I'd be using that right now in the interim exclusively... Geosphere is great, but it doesn't show photos (which still don't work on the log view page, btw), and otherwise uses the web page version to show up-to-date details. Anyway. It's great to see improvements consistently being rolled out. Much appreciated. This is a great pastime and it looks like it's got bright days ahead as it seems to really have been booming in the past few months, even. Keep up the good work. Just keep in mind the majority of users are not tech-savvy, and want a website that works, and love a website that is intuitive and easy to look to at, without requiring extra work on their part

I think most of what I was going to say has already been said, and most of it is quite obvious... anyhow, a few brief notes (trying to be as little redundant as possible) Display problems: CSS definition priorities. I don't think enough attention was paid to how certain css adjustments would filter down to child elements - either global definitions were added (like line-height, or cell padding?), or generic declarations were used for specific objects (such as ".classname div { properties }" which applies to ALL descendant divs, not just the immediate child, which can easily throw off custom HTML that may have previously appeared correct) First things I can think of to check for scope of effect on page elements: line-height, cell-padding, border-collapse, any background property... to name a few major ones (all described in some way in the past 9 pages I read through) I won't bother complaining about other things that really isn't productive (like update process and testing and whatnot) as that's also already been discussed... If I catch any other errors, I'll report in. Firstly, it's been mentioned earlier, but on logs with photos, the image doesn't appear. ight, sleep time.

Perhaps someone could adopt it? =) Heh, had to read back a bit for that myself... someone earlier posted about the archival of a cache named "Languages" So... add me to any contact info for excursions too... I'm sitting pretty at 404 finds, with 43 of 81 logged in the matrix (including a 5/5). Any opportunity to get out on caching trips to log some of these rarer caches - I will do my utmost to make it

I'm working towards the completion... long ways to go, but I'm under 200 finds, and over 1/4 the way through. getting the 5/5 next week, and a few other 4+ shortly as well. I will do this under 2000!