Jump to content

paleolith

+Premium Members
  • Posts

    952
  • Joined

  • Last visited

Everything posted by paleolith

  1. Thanks for the reply, and sorry it took me so long to return. I've submitted a help request. No telling what it will take to get it past the front line ...
  2. Multiple consecutive dollar signs in a cache title are treated as formatting characters rather than literals, and may not be displayed. It looks like $$ is markup to start/stop italics, and when present in a title, is not properly escaped at some point in processing. For example, see https://www.geocaching.com/geocache/GC6933_mulholland-cash
  3. Account is now locked at 3,079 finds. I noticed at about 1200 finds because it logged caches I follow in Florida and California. Don't know if the account tripped something automatic or if a real person is on duty. I suspect it's the latter, as an auto-trigger would probably trip well under 3,000. Edward
  4. I recently bought an eTrex 30x to replace my old HCx, which had failed. I'm still trying to get behavior I liked on the HCx to appear on the 30x. I realize I'm asking several questions at once, but I think it's better than starting several threads, and the questions do all relate to migration. It doesn't help that since my HCx totally failed, I can't examine it to figure out how I did stuff. I use the GPSr mostly for bicycling at the moment -- also for geocaching but my issues relate to bicycling. Aging eyes and the placement of the device about 3' from my eyes (recumbent cycle) make it hard to see. #1) On the HCx, I had a screen set up with three large-number fields: distance, speed, and time of day. The first two are fine on the 30x. On the HCx, I had time of day set up as HH:MM and it displayed as large as the other numbers. On the 30x, I have not been able to find a HH:MM option, only hh:mm:ss, and it displays small even on the large-numbers format. Is there a way to get a large time of day display? #2) The HC had a way to automatically save tracks to the microSD card. I've put that microSD into the 30x but it doesn't seem to use it. After just a few hours of riding, it says my track storage is already half full. Very odd for a modern device to be so limited, and if I go out for a week with no ability to download, it'll apparently fill up. Is there any solution? #3) I get an enormous amount of what I'll call "scatter" in tracks. (I would call it jitter except that Garmin uses that term for something else.) When I'm stopped, the track "moves" about every 25-45 seconds (roughly). Sometimes 15', sometimes 1', sometimes even 0'. I end up spending a lot of time in Basecamp to delete these clusters of scatter, and it's enough that I can build up significant mileage if I'm stopped for an hour. I thought I remembered a sensitivity setting for this on HCx, but I don't remember where and can't find any such thing on the 30x. The HCx did this a little, but at least an order of magnitude less. How can I deal with this? Thanks for any and all help, Edward
  5. Where is the summary of the changes? I'm offended at being asked to accept the new versions, many pages long, implying that I'm supposed to analyze the new vs old and figure out what the changes are, when Groundspeak already knows. Yes, I realize this is SOP on the web. That doesn't make it right, and I expect better from Groundspeak. Edward
  6. I just noticed that one of my bookmark list descriptions is not displaying correctly. This is no mystery; I had three links in old BBcode format. I tried changing them to MarkDown format, but that also just displays the unformatted text. The edit box for the bookmark list description shows no tools. Is there a modern way to have links in the description, or am I limited to just giving them as plain text (if at all)? Thanks, Edward
  7. The standard answer is "sign log, get smilie". Edward
  8. The purpose of putting the log in a plastic bag is to help finders identify the log when a variety of other items are in the cache. 99% of the time, plastic bags do nothing to keep the log dry, and often do far more to prevent it from drying out. There are bags which can keep a log dry, but you can't buy them at the supermarket. The purpose of supermarket food storage bags is to prevent MOST of the moisture from migrating (in or out) for relatively short periods of time under controlled conditions. But long term (as in a cache), the tiniest hole will allow water through. The plastic itself isn't totally resistant to water passing through -- anything less than 4 mil PE is almost a sieve, and you really need thicker than 4 mil. And it only takes water vapor migrating to leave something wet. A difference in vapor pressure results in a strong force to equalize that pressure. Once water vapor infiltrates, it eventually condenses as conditions change. The upshot is that there are four common reasons a log is wet: 1) Someone found the cache in the rain and did not adequately protect it. 2) Over the course of multiple finds, water vapor entered when the cache was opened, and later condensed inside. 3) A bit of vegetation (eg blade of grass) got caught in the seal when the cache was being closed, and acted as a wick. 4) The cache container is insufficiently waterproof for the placement and weather conditions. None of these issues can be addressed by adding a plastic bag. When you have time and weather conditions allow, you can address the first three cases by allowing the log and all other items in the cache to dry thoroughly before reclosing it (and removing the "wick" in the third case). In the last case, NM is in order -- you can't fix it for the CO. Unfortunately, at least 90% of cache containers are insufficiently waterproof. The percentage is higher in wet climates -- a decon works fine in SoCal but is a disaster in Florida. Even waterproof match cases usually leak when left outdoors for a long time in wet weather. Even some of the containers sold by Groundspeak do poorly over the long run. The only containers I've observed consistently keeping water out are ammo cans (in excellent condition), Lock-n-Locks (brand only), and preforms. And even those are subject to the first two problems. Edward
  9. This at least has an easy answer. Several coordinating answers actually. Programmers don't see things the way users do, yet programmers design and write software with interfaces based on what they themselves understand and like. They do so without testing on Real Users. They do so without involving User Experience (UX) professionals, or even the more narrowly defined User Interface (UI) specialists. Even experienced designers need to test on Real Users rather than trusting their own beliefs about what will work. For a good collection of articles, see https://www.nngroup.com/articles/ GC does not have a record of doing sufficient user testing. I won't claim they don't do any, simply because I have no knowledge of their internal processes. But we've seen many cases where the both the initial design and the final product show many signs of inadequate Real User testing. On the other hand, what we on the forums think is equally suspect. We are the 1%, or more likely the 0.01%. We do not represent the bulk of Real Users either. Even allowing for the expected high rate of lurkers, far more than 99% of GC users never visit these forums. Edward
  10. There's a cache which I 1) adopted, 2) found, 3) passed on to someone else. It is an old, well loved cache. I located the inactive owner and persuaded him to give it to me. I did assume responsibility for maintaining it, though I later passed on that responsibility to someone more geographically able. Had I not done this, I would be discussing that cache in past tense rather than present tense. Of course I could have logged a find before adopting it, figuring I'd delete the find if I were unable to adopt it and never found it. Or I could have waited and logged the find after passing it on. I could even have made the text and dates accurate, since those are editable. (Or is the system going to stop me from altering the date on a Found log to a date within a time period when I owned the cache?) The announcement fails to answer lots of questions about ownership changes. As usual, it does not even recognize ownership changes, referring to OWNER as though that necessarily meant HIDER. Even when it doesn't make sense for the HIDER to log a find on a cache they hid (and I've said there are cases where it does make sense, though not many), this is different from a adoptive OWNER logging a find on a cache they did not HIDE. If the problem trying to be solved is accidental multiple find logging (either from communications or website issues, or just from cluelessness), then focus on that problem rather than trying to make a bunch of "generally ought to" guidelines into absolute rules. Edward
  11. As for the trig caches ... create a new category. Similar to benchmarks, but better implemented, and integrated with geocaching. They don't fit the geocaching model, but they are clearly popular GPS games. Why fix the inconsistency by kicking them out rather than by providing an appropriate framework for them within geocaching? Edward
  12. Well, of course they posted it to the User Insights forum so we could give our feedback before the decision was made. Oh ... oops, nothing has been posted to User Insights in over a year. Guess we know where we stand. The problem this change is supposed to solve is ... what? Perhaps accidental double logging, I've seen a bit of that. Armchair logging has been a big problem at times. This change will of course ... do nothing about armchair logging. The restrictions on owner logs are just silly. Do those logs always make sense? For a difficult challenge, it makes sense for the owner to be allowed to log Found It. (I did so for the two challenges I've published, and no one has complained. I was not even close to FTF on either.) Are those logs often fun? Yes! Owner DNFs are some of the most humorous I've read. Owner NM and owner DNF logs can be owners poking fun at themselves. This change seems to be a victory of rules over fun. Edward
  13. Also, don't be afraid to change the D/T later. Some will say you shouldn't because of the many matrix ("fizzy") challenges. Your description of your cache should be kept accurate and up to date. If that messes up someone's record for a challenge, that's their problem -- they need to keep track of what the rating was when they found it. (Personally I think challenges should never depend on changeable attributes of caches, including the name, D/T, last two digits of coordinates, etc. But that's another 150 threads ...) Edward
  14. Thanks. Same problem with this one and this one. (Owner-action logs on caches I no longer own.) That's three out of the first sixteen logs I've checked, of 143 found with BBcode. I guess I should start a list and submit the rest all at once. Edward
  15. I have a log with BBcode. It's an Enable Listing log. I want to fix the BBcode and also eliminate the "edited by" line. Whether I edit it by hand or use the automatic conversion, when I submit the changed log, I get the message "There was an action associated with this log. The log type cannot be changed" even though I was not attempting to change the log type. This may be because I no longer own the cache. But that should not stop me from editing the old log. Edward
  16. It's really weird that it's not just random logs popping up out of the grave. It's only logs from early November, and perhaps late October, of 2002. And though the log PnavE81 cited may have been on an archived cache, the one I cited was on a still-active cache. (Which is why I watch that cache.) Edward
  17. I just received a notification for this 11/4/2002 log. I was not watching the cache at the time, and in fact did not even join GC until a few years later. The logging member (an elderly couple) have not logged on to the web site in three years and have not logged a find in five years, and no one knows if they are even still alive. I'll be happy to supply the message source if that will help. EDIT: I already had that log in GSAK, so I know it didn't change, at least not visibly. Edward
  18. Cool indeed. I just did a refresh on a list of 59 active caches, and 43 TBs went from present to not present. I wish they had logged the change, as it took me a few minutes to track down this thread and figure out why this happened all of a sudden. But the sweep removed a lot of TBs which have been, well, bugging me for years because the CO and the TBO either are inactive or refuse to mark them missing -- mostly the former, as these caches were all placed in 2003 or before. Edward
  19. Overall it looks good. We'll see. To me, the glaring omission is that there's still nothing to discouraging misrating the D/T to create caches for a fizzy challenge. And nothing to discourage COs from keeping inaccurate ratings due to complaints from finders that changing the rating would mess up their grid. Edward
  20. Presents a good question. The announcement quoted 3.5% of logs using BBcode. But if the numbers were weighted by length of log, what would the % be? Certainly far higher than 3.5%, since the longer the log, the more likely that it uses BBcode. For example, 3/4 of my logs use BBcode, and IIRC, my average log length is over 900 characters. I don't have time to try to analyze a broader sample at the moment, but to make the gc.com analysis honest, they should give us this number. Edward
  21. I'll respond to several comments without quoting. Security of BBcode: I found a discussion of XSS issues in BBcode at http://1nfosec4all.blogspot.com/2012/07/bulletin-board-code-bbcode-xss-exploit.html. I tested all the examples given. I found that gc.com is not vulnerable to any of them. Of course there may be others, and reading the article gives one a good idea of how hackers can slip through unseen cracks, but the implication is that the GC code already interprets BBcode narrowly (safely) rather than broadly (accepting anything stuck in). How can code get that bad? Without going into details, I'll just say that I've seen lots of bad code that was written with good intent. Sometimes systems start small and grow without ever being designed. Other times it's just bad programming, but in this case I'm willing to assume the first interpretation. I remain unconvinced that it's impossible to do a reasonably safe conversion. (And if there's concern about loss of data, remember that garbaging the display of old logs is effectively losing data.) My approach would be narrow: pick out patterns which can be converted safely and convert those. In no case delete any text -- that should not be necessary in any case. I don't see any need to make any transformation which would delete text. I may yet try doing this in a GSAK macro, but the lack of capability to modify an existing log via the API would make this a less than satisfactory solution. Plus, I don't just want MY logs kept legible ... I want all the logs that I READ kept legible. Note that I'm harping on the theme "failure to act will constitute loss of data". As for "a RegEx and a simple one-to-one text replacement is all that's necessary", I'm not convinced it's that simple. I'd say it's simple as long as the tags are properly nested. But what happens, for example, if a [b] is nested inside a [url]? There are real issues to be analyzed. For example [url=http://[b]example.com[/b]]EXAMPLE[/url] might get converted to [EXAMPLE](http://**example.com**) No danger there (the link is broken, but the BBcode link probably didn't work either), but it's a sample of what strange things can happen. I'm not devious enough to think up truly dangerous examples. I am however a believer in a modified version of the Law of Large Numbers: when you have enough records in a database, you'll find all kinds of things you never expected. That was true forty years ago when I was working with a database of ten million driver licenses -- absolutely huge for its time. It's certainly true for a billion log records, even if 95% of them are just a couple of words. So "strip everything known to be malicious" is not sufficient. The design has to be "only allow what's known to be safe". The function of the Publish Logs macro is now built in to GSAK, and Clyde is busy updating the function for Markdown. I have not yet heard any clarification on the statement in the announcement that "Smileys will continue to be supported as they are today". Does this mean that the existing syntax for smileys will be supported, and thus that smileys in old logs will still be OK? Or that smileys will be supported with a different syntax? Edward
  22. True, phishing is the most likely security risk in BBcode. But the same risk exists in Markdown, so apparently that's not the security risk being addressed. (The only way to address this is to refuse to hide the URL. IMDb message boards do this, probably for this reason.) As for XSS, the risk is still due to what a user input. Once you stop accepting HTML as input, then old non-risky HTML can't be exploited. I'd be interested in whether scripting is already blocked in HTML logs. Not taking the time to test it now ... Edward
  23. As database technology goes, my list is a nearly trivial design. The amount of code needed is tiny compared with even what they are adding to implement Markdown. I agree that the announcement is unclear as to what they will do with old logs. The fact remains that adding a flag, and testing it, is trivial. Well, OK, nothing is totally trivial with a database that has over half a billion entries, but it's just a matter of making sure the process of adding the field doesn't disrupt operations, documenting the changes, testing, etc. All of this has to happen for the Markdown implementation anyway. I'm no Markdown expert, but from both memory and from scanning the linked docs, I see no evidence that Markdown has smilies. So GS is going to have to add smilies to the Markdown code. But of course I'm not sure what they mean, since they didn't give enough detail. The security risk is on input, not on display. Furthermore, it's on input of HTML -- I'm not aware of any security risks of BBcode. (In fact that's one of the points of BBcode -- it simply doesn't have the power to do damage.) No one is asking them to continue allowing input of HTML or even BBcode. So again, I'm aware of no security risk in continuing to display existing HTML and BBcode. If you have an example, please present it rather than just saying there's a security risk. I don't think any of us here know the reason for making this so sudden. Getting rid of HTML input could be belated recognition of the security issues, and preferring to eliminate it rather than sanitize it as they do for cache descriptions (and I have no argument with this). I think the more likely trigger is more users with plain-text devices complaining about the formatting of BBcode logs. By definition, most of us in the forums are web users, and probably read logs in web browsers, so we aren't aware of how a lot of users with mobile devices see the logs. But this is only speculation -- again, no one here knows the reasons. Will Markdown appeal to the masses? Well, it appeals to me. I've said so earlier in this thread, and I certainly plan to use it once it's implemented. The conflict is only over display of existing logs. Edward
  24. I'm curious, why do you think it would be so difficult? My analysis (based on 40+ years in IT) is that maintaining support for displaying the old formats would be by far the easier part of the task. Note that I only say "displaying", not continuing to accept the old formats for new logs, which neither I nor (AFAIK) anyone else is arguing for. The basic outline is: 1) identify post-cutover logs with a flag. 2) Keep the current display code (which is entirely server-side). 3) Add the Markdown code. This is server-side for HTML destinations. 4) When displaying a log, based on the destination, either run the old code or the new code. The announcement wasn't clear from a technical point of view, but I believe that they are going to have to do #1 anyway. This is because of the possibility of royally screwing up logs with text that has a formatting interpretation in Markdown, as already discussed here. Also, this is pretty close to trivial, so there's hardly any reason not to do it. As for #2, they aren't going to remove the old code entirely anyway, since they say they will still support smilies. (The announcement is unclear here also, saying "smileys will continue to be supported as they are today". Do they mean that smileys in old logs will still display as images? Do they mean that smileys will be supported in Markdown logs? Or both?) As for #4, they will have to adjust based on the destination anyway. Presumably when displaying to an HTML-capable device (which is more than just web browsers, since HTML rendering is built into most systems at a basic level these days), they will convert the Markdown to HTML, so that ** will actually be bold instead of just displaying the **, so that links will actually be links instead of just displaying the text followed by the URL, etc. I'm always open to other analyses. So where do you see the great difficulty in supporting the old formats when displaying old logs? Well, no, I don't see any reason for them to do this unless they genuinely thought it was best for the community. There's simply no advantage for them to change this just because they can. While Gill & Tony's comment was a bit aggressively negative and imputes intents to the Groundspeak developers which are poorly founded at best, the statement is basically true. Groundspeak does have a monopoly on geocaching. I've pointed out in the past that geocaching is a natural monopoly: it's to each geocacher's advantage to be where all the other geocachers are. Going off and forming a splinter group confers few advantages and many disadvantages to the individual member, and the failure of such attempts supports this position. Our only alternative to following their new rules is to protest, and we've seen the lack of response from GS to this thread. And this time (unlike some other times) GS did not even solicit input from the tiny percentage of geocachers who read the forums. I don't think GS is getting rich at our expense. They've clearly put a great deal of the growth in membership fees into development, which includes things we don't see. (Securing a large, popular web site today requires solid expertise. I can't recall a time when GS went down due to an attack, and that's a good record.) The game is still fun for most of us, despite floods of new users who often play in different ways. But it's still a monopoly. Edward
×
×
  • Create New...