Jump to content

Log Change from HTML to Markdown


NinjaCacher!

Recommended Posts

I understand the decision to disallow html. But why not just keep UBB code? Is it less safe than Markdown in any possible way?

 

I also kind of understand the technical decision against converting 560 million logs, but i don't think it is a good idea to leave it with "Therefore we have decided to recommend that users convert their own logs".

 

Going through all the logs will already be a HUGE "pain in the .." for a cacher with 100 finds, but with thousands of finds this will never be possible. Meaning we'll have up to 20 million (3.5% of 560 million) broken logs showing broken HTML.

 

Wouldn't it be possible to "grandfather" the existing logs and keep the formatting as it is for all logs written prior to Feb 2, 2016?

 

Regards

NinjaCacher! a.k.a. Luzian

Link to comment

I agree with NinjaCacher!. I have more than 11 000 finds, and use UBB on many of them. Going through all of them will be a huge job.

 

But why should I do the job of your developers? If you want to change something in our backend, aren't you the ones responsible for migrating the existing data?

If we did this with any of our systems where I work, we wouldn't have any customers left.

 

I can understand that you want to improve, and I appreciate that you do! But please be respectful to existing data, and your existing users.

 

When you calculated the percentage of logs affected, did you also count Publish-logs and other logs with no content?

Link to comment

Of course it would be easy to grandfather existing logs and keep everyone reasonable happy but that never seems to be a priority. Please, please change this decision.

 

Also "modern" doesn't seem to be the whole story Wiki says it was invented in 2004 and also helpfully says "There is no clearly defined Markdown standard". To me this seems to be a backward step and yet another language to learn, time will tell how successful this is, should have gone for April 1st as the implementation date [:)].

Link to comment

I like Markdown, but I find Groundspeak's analysis of the impact of their plan to be sorely lacking.

 

It's nice to quote the 3.5% figure, but that's only a global average. As thomfre points out, individuals vary -- a lot. It would be more realistic to report, say, how many users have more than ten logs using UBB (figuring fixing more than ten is an unreasonable burden), and to provide a tool to search for logs needing to be fixed. I have far fewer finds (657) than thomfre, but I've used UBB [url= links in 3/4 of these (465 to be exact).

 

AFAICT, it's not possible to modify existing logs from GSAK. That won't be GSAK's fault; it means gc.com has not provided an API for that purpose. The way to automate the fix, then, will be:

 

  1. Start with a My Finds PQ loaded into a GSAK database.
  2. Run a macro to modify the text and prepare new logs for publishing.
  3. Publish the replacement logs.
  4. Delete the original logs.

 

Oh ... but not only will this create a huge surge of notifications as the replacement logs are posted, there's no way to delete the old logs via GSAK. So even with the problems it would create, the replaced logs would all have to be deleted manually. (Or by screen-scraping, but that violates the gc.com T&C.)

 

So, I see the analysis presented in the announcement to be sorely lacking in rigor and completeness. (And I have some 45 years of experience in systems analysis.)

 

Edward

Link to comment

I understand the decision to disallow html. But why not just keep UBB code? Is it less safe than Markdown in any possible way?

An interesting question, but, of course, they can't answer it without telling you what they're worried about you doing.

 

Going through all the logs will already be a HUGE "pain in the .." for a cacher with 100 finds, but with thousands of finds this will never be possible.

Don't be silly. No one is going to go back and edit their logs. Even discounting what a pain it would be just to check every log, converting the log would mean all those logs would have the dreaded "edited on" tag. I'm planning on leaving mine as is, and I'm betting I'm not alone.

 

Meaning we'll have up to 20 million (3.5% of 560 million) broken logs showing broken HTML.

Oh, yeah, I guess you're right that's how those numbers should be read. I thought they were saying the half a billion *was* the 3.5%.

 

Wouldn't it be possible to "grandfather" the existing logs and keep the formatting as it is for all logs written prior to Feb 2, 2016?

I doubt it would be possible to grandfather anything. These are rendered into HTML when they're sent to the person reading the log, so you either render BBcode or you don't for all logs.

Link to comment

I doubt it would be possible to grandfather anything. These are rendered into HTML when they're sent to the person reading the log, so you either render BBcode or you don't for all logs.

That is very easy to solve. They can just add a flag in the database that lets the system know that this log is using HTML. Just like the flag you have to say that your cache description is using HTML.

Link to comment
Our tech team discussed the possibility of cleaning up old logs. Unfortunately, the risks associated with altering/scrubbing 560 million logs (not counting trackables) is too high to run any kind of cleanup without some bad consequences: i.e., loss of data, corruption, etc. Therefore we have decided to recommend that users convert their own logs.

I consider showing the raw HTML and UBB corruption as wel, so converting can only improve it.

 

You could even use a kind of filter on logs pre-dating the switch date to convert them on the fly. This way loss of data is also no longer an issue, as the data in the database doesn't change.

There are good tools available for converting. Example: https://github.com/baynezy/Html2Markdown

 

And if you do decide not to convert logs, will there be a way to suppress all those "Editted by" messages at the end of my logs when I go back and edit all of them to fix them?

Link to comment
I doubt it would be possible to grandfather anything. These are rendered into HTML when they're sent to the person reading the log, so you either render BBcode or you don't for all logs.

On the contrary, I can think of two rather trivial implementations:

 

First, it's likely that log records have a timestamp already -- the date and time the record was stored -- though this is not visible to users. (It's almost essential for database recovery purposes.) In this case, just check the timestamp against the cutoff, and render HTML and UBB for logs prior to that date, and Markdown for logs after.

 

Second, if there's no timestamp, add a toggle (flag) field to indicate a grandfathered log containing UBB or HTML. On the cutoff date, set this field for all 20 million such records, and never set it again. Then when displaying the log, render the UBB and HTML if the toggle is set.

 

Actually this brings up another issue not mentioned in the announcement. What happens when old logs contain character sequences that are meaningful to Markdown? Will this lead to garbaging old logs? It seems to me that they are going to have to add a flag anyway so that they do NOT apply Markdown to old logs.

 

Edward

 

(explanation crossed with thomfre's post, but I'm leaving my version ...)

Link to comment

jholly wrote in the general forum:

So let me get this straight. This change is driven by security concerns, but yet only a small number of logs use HTML/UBB. How about cache listing pages? Seems to me that the number of cache listing pages using HTML is greater than the logs. So if your concerned about security why didn't you start with cache listing pages?

They've done a good bit of work in the past to restrict HTML use to a "safe" subset. I don't know if the same restrictions are in place for logs. If not, that might have been a lot of work -- not to mention that keeping old HTML logs would have required scanning them for violations. Though they weren't concerned about modifying existing cache descriptions ...

 

If the restrictions were in place for logs, then I don't see any security reason for not continuing to send the HTML in renderable form. For that matter, if there are security problems with UBB (and unlike with HTML, I have no idea what security issues UBB raises), then why not scan for those, and modify just the logs with apparent problems?

 

What it looks like to me is catering to mobile devices and new users far more than to "the base" ... those of us who have been around for years and still compute at our desks.

 

Edward

Link to comment

What happens when old logs contain character sequences that are meaningful to Markdown? Will this lead to garbaging old logs?

That's an excellent question. Whoever at Groundspeak did the search to identify HTML and UBB in current logs needs to modify their search to look for Markdown tags so they can let the public know how many logs will be broken in this way.

 

The announcement has a major error. The number of logs that would need to be modified isn't 560 million. That's the number of ALL logs (including archived ones). 3.5% of the current total (a little under 568 million) is about 20 million. Surely you would identify problem-logs ahead of time to avoid having your scripts or processes run through ALL logs, right? It seems like this has already been done anyway to come up with the 3.5% number.

 

If you're worried about data loss, corruption, or even performance, then do the conversion in batches in off-peak times. I'm sure we could live with the odd broken log for a few days until the conversion is complete.

 

The vast majority of conversions will involve trivial changes (ie. bold, italic, underline, hyperlinks). Some regular expressions should be able to very easily identify these tag pairs, and text replacement isn't exactly rocket science. If there are some logs that use more complex HTML that can't easily be automatically converted (can we use tables in logs?), they could be left as-is and flagged for each user to fix themselves. I expect the number of these complex logs would be very small, so the impact to the userbase would probably be minimal. Even if there's the odd edge-case or something is mis-converted, the number of resulting broken logs will still be vastly smaller than the number that would be broken by not doing the conversion at all.

 

There's really no excuse for not converting logs. The users have been using the website as intended (in general, at least; I'm sure there are cases of unwanted HTML in some logs), so it isn't the users' fault if the logs are broken after this change. You're the ones who have decided to make the change, so you need to deal with the consequences of that decision. If you're not prepared to fix at least the majority of the broken logs (see my suggestion above), then you should delay it until a point in time where you're comfortable/capable of doing so, or rethink the plan entirely and consider other options.

Link to comment

I don't use any styling, so I wouldn't want my logs to accidentally go through any transform.

 

The best option, though it would require some additional work, is to add a manual migrate tool to the site. Those small percentage of users that care about formatting, could select the migrate tool and it would identify the logs that have html/BB formatting in them, and then present the logs in their before/after, with an option to just go ahead and approve all. If it messes up logs, it only does so for those that went through the process after a confirmation.

Link to comment

I strongly support grandfathering, 'cause I and several others have used HTML links to various statistic pages to prove that we've met the requirements of the challenge caches.

 

Your links will still be there, but they will look like

<a href="http://somestatspage/.....">My Stats</a>

or

[url]http://somestatspage/...[/url]

 

Not pretty, but if the challenge cache owner wants to verify, they will have everything they need, they just can't click the link they have to copy/paste it instead.

Link to comment

Help Center → Finding a Geocache → Logging a Geocache

4.13. Geocaching Logs switching from HTML to Markdown

https://support.Groundspeak.com/index.php?pg=kb.page&id=729

 

In our continued effort to increase site security and promote cross platform compatibility, we will be removing support for HTML and UBB code in logs in favor of Markdown on February 2, 2016. These codes are used to add emphasis to text such as bold or italic type, or to add links to websites. HTML and UBB code may not always look exactly as you intended them to on some devices, while Markdown will consistently look good across all devices.

 

This change affects less than 3.5% of existing logs, which will now display any old HTML and UBB code. Note that starting to use Markdown now will ensure logs display properly following the transition.

 

Other things for you to know:

 

After the switch to Markdown, HTML or UBB code will be displayed in all logs, since we will not respect or render the HTML or UBB Code on output.

 

The biggest change is that Font Color and Font Name will not be supported by Markdown. But users will gain the ability to edit Font Size using the "Header." Opening and closing #s are required to create a header.

 

Markdown has many advantages, including a better experience for mobile app users and GPX file users (the Markdown plain text formatting is much more understandable than unsupported HTML code).

 

Links will hyperlink when using Markdown code.

 

Links will prompt (as they do on the Message Center) if they are to an external site (one not within the Geocaching/Groundspeak domains).

 

Smileys will continue to be supported as they are today.

 

We will continue to respect old logs’ line breaks so these do not need to be adjusted.

 

There will be an obvious WYSIWYG editor and preview window on the page, meaning there is no need to learn code to personalize logs.

 

Why are we making this change?

 

Markdown offers increased site security.

 

Markdown is a modern notation that works on many platforms (Web, Android, iPhone, Windows Phone, GPS-Unit, GPX-File, API).

 

HTML is web-only.

 

Unlike HTML, Markdown displays clearly on platforms even when they are not optimised to support it.

 

Geocachers will now have the ability to preview the styling of their logs via a WYSIWYG and preview window to the web logging page.

 

Only 0.45% of logs currently use HTML; 3% use UBB code.

 

How can you learn more about Markdown?

 

For a feel of what Markdown options can look like, see

http://www.toptensoftware.com/markdowndeep/dingus It shows essentially how the web view will look at the top of the page - including the WYSIWYG and preview. Not every feature listed in this example will be supported, such as inline image support (use of the gallery images is the only way to add images) or anything under "Extra Mode", and <enter> will result in a line break.

 

Why aren't we converting old logs?

 

Our tech team discussed the possibility of cleaning up old logs. Unfortunately, the risks associated with altering/scrubbing 560 million logs (not counting trackables) is too high to run any kind of cleanup without some bad consequences: i.e., loss of data, corruption, etc. Therefore, we are recommending that users convert their own logs.

 

B.

Edited by Pup Patrol
Link to comment
Not pretty

Yep. That's my objection in a nutshell. Those who only log TFTC (or object to being asked to write even that much) won't care. I try to contribute in the form of logs that people actually enjoy reading. Ugly detracts from that.

 

Edward

 

For logs people wrote last month or last year, barely anybody would ever notice the raw formatting codes. Yeah sure some get read, but the majority of logs read are very likely only the most recent.

 

Very few logs I've seen make any extensive use of formatting, so if I came across a few random bold or red or whatever format tags, it's unlikely to detract from the experience of the reader.

 

Going forward, the markdown syntax gives you pretty much everything you had before, so you can still write elaborate formatted logs if you desire. I don't disagree that a way to keep legacy logs looking the way they do would be preferred, but if that's not in the plan then not much is lost.

Link to comment

I am ambivalent about the change. My main concern is how it will affect what I see in my GPS.

In my current dataset (northern California) I have 532161 logs.

Of these 2.26% contain two sequential characters [/ (which appears in closing bb codes) or the two sequential characters </ (which appears in closing html tags).

So the impact would be small. Further, since old logs are not affected, and I get them via gpx files, I anticipate no change on my GPSr.

 

But I do find the arguments for the change to be bogus. Consistency across devices will be lost, not gained. Geocaching apps render html, as do most modern GPSr devices. But NONE render Markdown. On the GPSrs there will be a dependence on the fact that Markdown does not use a lot of mark-up and is readable without rendering. So what will happen is that instead of the logs looking the same on my Garmin Montana, as on my smartphone, as at the website, as is the case now, these will all show differently due to a lack of rendering on devices.

 

And if the website stops rendering html and bb codes in the logs, while my devices still do, then clearly the appearances (and certainly also readability) will be different.

 

Does anyone think that Garmin will implement Markdown rendering in firmware updates on GPSrs given that Markdown has already been obsolete for 10 years and has no industry standard? That seems very unlikely to me.

Link to comment

The best part is

"There will be an obvious WYSIWYG editor and preview window on the log page, meaning there is no need to learn code to personalize logs."

But when editing cache page, ther will be stil any support, only pure html code, like 15 years ago...

Edited by ru.beus
Link to comment

For logs people wrote last month or last year, barely anybody would ever notice the raw formatting codes. Yeah sure some get read, but the majority of logs read are very likely only the most recent.

 

Among the caches I'm interested into many do not get many visits - so reading the logs over the last couple of years occurs frequently for me.

 

Very few logs I've seen make any extensive use of formatting, so if I came across a few random bold or red or whatever format tags, it's unlikely to detract from the experience of the reader.

 

I'm not using formatting, but I very often use links - some to external sites but much more frequently to other cache pages or logs. Without working links it becomes a burden to read logs for cache series. I do not believe that only 0.45% of the logs use links.

If the links in logs written before February will not work afterwards, that's one of the worst changes on gc.com ever.

Edited by cezanne
Link to comment

For logs people wrote last month or last year, barely anybody would ever notice the raw formatting codes. Yeah sure some get read, but the majority of logs read are very likely only the most recent.

 

Among the caches I'm interested into many do not get many visits - so reading the logs over the last couple of years occurs frequently for me.

 

Very few logs I've seen make any extensive use of formatting, so if I came across a few random bold or red or whatever format tags, it's unlikely to detract from the experience of the reader.

 

I'm not using formatting, but I very often use links - some to external sites but much more frequently to other cache pages or logs. Without working links it becomes a burden to read logs for cache series. I do not believe that only 0.45% of the logs use links.

If the links in logs written before February will not work afterwards, that's one of the worst changes on gc.com ever.

 

I just took a quick look at the logs on some of your multi-caches and I'm not seeing a lot of user created links. I saw quite a few emoticons (links to images) and a couple of instances of links to TB pages. The issue with links is that they're not always what they appear to be. While it may look like a link to a TB page, it could contain XSS (cross site scripting, one of the most common methods used for hacking a web page) code which does something nefarious. When users are allowed to enter HTML into a form, and the contents of the form element is just stored in a database without any sanitization, and then rendered on another page, for example: a cache listing page, anyone looking at the HTML on the cache page won't know if the HTML actually does what it appears to do. I assume you probably trust Groundspeak to create web pages which contain valid HTML which isn't doing anything nefarious. Do you trust that very user of the web site is creating html, included on GS web pages (which is what happens on every cache page) isn't doing something nefarious? Keep in mind that a web page which contains a form (such as the Log your visit page) is just a GUI for sending data to a form processor running on the server, and that it's pretty easy to automate a request to the same form processor.

Hackers will frequently just crawl web sites, look for pages containing form elements, and then inject a cross-site scripting "test" into the form elements and submit a request, then check the response to see if the page in site is vulnerable. Then they can target that page with code that *is* malicious, stealing cookies, session information, replacing images with links to images which contain executable code and so on.

Breaking links may be an issue with you, but allowing users to create links which contain malicious code is far worse.

Link to comment

I just took a quick look at the logs on some of your multi-caches and I'm not seeing a lot of user created links.

 

I referred to my logs and caches I'm visiting and not to my own caches. I need links much more often for series of traditionals than for multi caches or singular mystery caches and I do not own traditionals/cache series.

 

The majority of my links are links to Groundspeak pages and they are created by simply pasting the website adress into the log, not using explicit html code myself.

I think that it should be very easy to keep these links working and I cannot see any security difference to the situation caused by new links created by markdown or by links on profile pages or cache pages.

The internet will never be 100% safe.

 

Excepting Groundspeak to come up with a solution that at least leaves links to Groundspeak pages created in logs prior to the change in a working mode is not in collision with any sort of security concerns.

Edited by cezanne
Link to comment

Among the caches I'm interested into many do not get many visits - so reading the logs over the last couple of years occurs frequently for me.

 

Only 1 in 20 logs would have any formatting. Most of these have very little use of it. Seeing a few random formatting codes "raw" is unlikely to detract from your reading experience.

 

I'm not using formatting, but I very often use links - some to external sites but much more frequently to other cache pages or logs. Without working links it becomes a burden to read logs for cache series. I do not believe that only 0.45% of the logs use links.

If the links in logs written before February will not work afterwards, that's one of the worst changes on gc.com ever.

 

Maybe I'm in the minority, but when somebody strings together a bunch of their logs via links I'm extremely unlikely follow them. I can see if you were following a friend's adventures and they made links from one log to another it might be interesting. But this is pretty rare.

Link to comment

Only 1 in 20 logs would have any formatting. Most of these have very little use of it. Seeing a few random formatting codes "raw" is unlikely to detract from your reading experience.

 

I'm talking about links, not formatting.

 

Maybe I'm in the minority, but when somebody strings together a bunch of their logs via links I'm extremely unlikely follow them. I can see if you were following a friend's adventures and they made links from one log to another it might be interesting. But this is pretty rare.

 

Do you prefer TFTC logs for 20 caches of the same series? I try to write a log as unique as possible for each of them (including comments on the condition of the container, T/D-rating, how fast I found it etc). I'm of course aware that many cachers and even many owners of such caches do not read a single log for such caches maybe except the last cache of the series, but I regard that as bad style and I'm very annoyed to read something like "most of the caches are in good condition, some have wet log books, some we hard to find, two we could not find" and this log pasted into the log for all caches (including the two they did not find).

 

Quite often the indvidual caches of such a series are like stages of a multi cache with the only difference that every cache ends up with a find. For a multi cache one writes one log for the whole story - if there are 30 separate caches linking is in my opinion the only way of telling a contiguous story.

 

I also often link to DNF logs in find logs of the same day to make them visible for friends.

 

It's weird to see logs on gc.com as security issue as the whole site is based on logs and on the fact that logs are viewed and read.

Edited by cezanne
Link to comment

The more I think about this, the more I am puzzled/intrigued.

 

No data are changed and if I send in a log via the API, it will go in exactly as the string of characters that I submit even if that includes non-Markdown tags. There won't be processing because they don't know how to do that without breaking things (per their quote).

 

The change will be primarily at the page on the geocaching.com website where you edit logs. There we will see a Markdown WYSIWYG editor (stripped down a bit from the one they show at the link in the announcement). I really do like the idea of having a WYSIWYG editor there.

 

So what will happen is that all modern devices will be OK with HTML and BB, but the website will clearly look broken on some logs if they strip codes during the display of logs section of the web page. There will be a never ending stream of newbies asking why some logs are broken and then the website will be fixed and the display system will then support Markdown, HTML, and BB codes. You will be able to use the new editor to edit in HTML codes as you do now because it is fundamentally designed to leave all fancy formatting in the hands of the user.

 

If it is as I am guessing, then adding that WYSIWYG editor for Markdown would also be neat enhancement the cache description editing fields also. Obviously a full WYSIWYG HTML editor would be better but that has been a need since day 1 of the website, so clearly that will never happen. A WYSIWYG Markdown editor there would be better than nothing as long as we can still do what we do now.

 

If I have understood this correctly, then I would ask for one enhancement to the Markdown editor for the website. We need to be able to switch between the default font and a "fixed font" (e.g. Courier New) so that some primitive tabulation is possible (aligning columns by inserting spaces).

Link to comment

Do you prefer TFTC logs for 20 caches of the same series? I try to write a log as unique as possible for each of them (including comments on the condition of the container, T/D-rating, how fast I found it etc).

 

Sorry, I'm not following. How does the ability to add links or formatting relate to TFTC logs? None of the changes with Markdown impact your ability to write a log as unique as possible, conditions, etc ... Sure you can't add rainbow colors to your log as far as I know, but nothing else has really changed.

Link to comment

If it is as I am guessing, then adding that WYSIWYG editor for Markdown would also be neat enhancement the cache description editing fields also. Obviously a full WYSIWYG HTML editor would be better but that has been a need since day 1 of the website, so clearly that will never happen. A WYSIWYG Markdown editor there would be better than nothing as long as we can still do what we do now.

 

There have been no plans announced that I've seen to change from using HTML in cache descriptions. That will stay HTML, and I'd be very surprised to see any future plans to move that to markdown.

 

There are plenty of plugins available with firefox and chrome to give you the ability to turn text input fields into WYSIWYG editors. You can do that now without any site changes.

Link to comment

Do you prefer TFTC logs for 20 caches of the same series? I try to write a log as unique as possible for each of them (including comments on the condition of the container, T/D-rating, how fast I found it etc).

 

Sorry, I'm not following. How does the ability to add links or formatting relate to TFTC logs? None of the changes with Markdown impact your ability to write a log as unique as possible, conditions, etc ... Sure you can't add rainbow colors to your log as far as I know, but nothing else has really changed.

 

TFTC is the most canonical log in my area for all caches of a cache series except the last one which one contains something of the type I cited.

What I prefer to do is to start with a log for cache #1 and link from there to cache #2 and etc and try to come close to what I would write for a multi cache with stages at the places of the caches of the cache series. All these caches belong together - so I see a need to link the logs if one is trying to focus on the individual caches at all and is not dealing with them as a single cache which increments the find cound by +x for a series with x caches.

 

Maybe I misunderstood something, but according to my understanding all the old logs which contain links (including links to Groundspeak sites) will not work in the future (in the sense that instead something to click there will be just the text of the link). That's not an issue of what markdown is able to do in future logs as I care about what happens to the old logs. I do not have the time to go over 4200 logs.

Edited by cezanne
Link to comment

Hmm... Is it worth littering my logs with

 

This entry was edited by niraD on Saturday, 9 January 2016 at 21:01:40 UTC.

 

just to convert the UBBCode that is no longer being displayed correctly into Markdown?

 

And is it worth converting the UBBCode that is no longer being displayed correctly into Markdown that may or may not continue to be displayed correctly in the future?

 

And is it worth writing nice logs using Markdown that may or may not continue to be displayed correctly in the future?

Link to comment
Hackers will frequently just crawl web sites, look for pages containing form elements, and then inject a cross-site scripting "test" into the form elements and submit a request, then check the response to see if the page in site is vulnerable. Then they can target that page with code that *is* malicious, stealing cookies, session information, replacing images with links to images which contain executable code and so on.

True, but I don't think that scenario is current at GS. Certainly it's not true WRT cache descriptions -- GS scans the text for HTML and strips out any tags and attributes not in their whitelist. Of particular note, nothing to do with scripting is in the whitelist. AFAIK, this is extremely effective at blocking injection attempts. IIRC, the implementation is based on well-known public code.

 

I don't know for sure if the same code is applied to logs. I suspect it is, since otherwise the site would have suffered major attacks already. (The need to register to post a log is not a serious deterrent.) If it's not already applied to logs, I don't see why it would be difficult to do so. In any case, surely they are applying it to postings in this forum!

 

Only 1 in 20 logs would have any formatting. Most of these have very little use of it. Seeing a few random formatting codes "raw" is unlikely to detract from your reading experience.

The raw codes that appear in logs emailed to me already detract from my reading experience, since none of the email interfaces I've used render UBB. (I don't think I've ever seen HTML in an emailed log, but I'm sure it would be the same.) This is one reason I like the idea of switching to Markdown for new logs -- it looks much better than UBB in raw form.

 

But the fact that seeing raw codes already detracts implies that it will do so when I'm reading logs online.

 

It's likely that I read more logs than the average cacher. So what? Why discourage people from reading logs by uglifying them?

 

If I have understood this correctly, then I would ask for one enhancement to the Markdown editor for the website. We need to be able to switch between the default font and a "fixed font" (e.g. Courier New) so that some primitive tabulation is possible (aligning columns by inserting spaces).

The link in the announcement indicates that GS will be using MarkdownDeep. One of the pages there says "MarkdownDeep optionally supports all of the PHP Markdown Extra extensions, including: ... Simple tables". These Markdown Tables would probably suffice for most purposes -- assuming GS enables this "optional" feature.

 

Edward

Link to comment

So, since there is no Markdown standard, how do we know what flavor of Markdown Groundspeak will use? They've already said some features will not be supported; how can we know which features ARE supported?

 

Since this change amounts to learning a new computer markup language, will there be a tutorial and/or reference provided by Groundspeak? Knowledge of HTML and BBCode is very widespread; I have never encountered a site that mandated Markdown until now.

 

If we did edit logs now, would they look like the dog's breakfast until sometime after February (because Markdown is not currently one of the ways to format logs)?

 

Will there be a plain text way to format logs? It seems to me that a WYSIWYG editor that relies on Javascript would be difficult to implement across platforms. So on the one hand, text will look the way TPTB want it to, but on the other hand, the input tool for users may be restrictive. I personally prefer to write HTML and BBCode by hand. I don't trust WYSIWYG tools, partly because you can't see what's going on.

Link to comment
Hackers will frequently just crawl web sites, look for pages containing form elements, and then inject a cross-site scripting "test" into the form elements and submit a request, then check the response to see if the page in site is vulnerable. Then they can target that page with code that *is* malicious, stealing cookies, session information, replacing images with links to images which contain executable code and so on.

 

True, but I don't think that scenario is current at GS. Certainly it's not true WRT cache descriptions -- GS scans the text for HTML and strips out any tags and attributes not in their whitelist. Of particular note, nothing to do with scripting is in the whitelist. AFAIK, this is extremely effective at blocking injection attempts. IIRC, the implementation is based on well-known public code.

 

For web applications that I develop I wrote a service which uses a library that sanitized HTML as you describe. The service is implemented as a request handler that intercepts every request that uses form elements. The form element on any page on the sanitized before any other processing is done with it. It is based on the OWASP (Open Web Application Security Project) code.

 

While I think it's a very good idea to tighten security on the site unless it's done with any form element that is going to store user generated HTML it's only going to make the site marginally more secured.

 

If someone had their house keys on a key fob with their address on it and lost it at the mall it would be a good idea to change the locks. Just changing the locks on the front door (if the back door uses the same key) isn't going to help much.

 

In the case, hackers can create keys (malicious code) that can open doors (forms that allow HTML) into Groundspeaks "house". Changing the lock on one of the doors (the log pages) only means that a hacker will try their key on other doors into the site until they finds one that "fits".

 

 

Link to comment

Does anyone think that Garmin will implement Markdown rendering in firmware updates on GPSrs given that Markdown has already been obsolete for 10 years and has no industry standard? That seems very unlikely to me.

No. But it shouldn't be an issue, as Markdown is a lightweight format designed to still be readable even if not rendered. From the announcement:

 

Unlike HTML, Markdown displays clearly on platforms even when they are not optimised to support it.

I wouldn't describe Markdown as "obsolete". There are many sites on the web that use Markdown as an input format for content these days.

Link to comment
While coding on cache descriptions is useful, I wish logs were plain text only.
There are times when it is useful to have links in logs. For example, on the first log of a day, I can explain that the group is signing logs with a single team name, and list everyone in the group. Then I can link to that log for all the later logs in the day.
Link to comment

Seeing a few random formatting codes "raw" is unlikely to detract from your reading experience.

Personally, I'm not a big fan of excessive formatting in logs. But the people that do use formatting will object to your statement: they go to the trouble of using formatting because it enhances their logs, so failing to format their commands correctly will, itself, detract from my reading experience in their opinion. As it happens, I read BBcode and HTML fluently, so I'll be able to imagine the effect, but, for most people, a bunch of apparently garbage characters in the middle of the log will, beyond doubt, detract from their reading experience. Feel free to claim that the effect will be low enough to be a reasonable price to pay -- even with me not being a fan, I don't really buy that, although, admittedly, I can't really judge the implementation costs -- but don't insult my intelligence by claiming it isn't going to detract at all.

 

If we did edit logs now, would they look like the dog's breakfast until sometime after February (because Markdown is not currently one of the ways to format logs)?

This was the part that astonished me the most. "You have a month to convert all your logs to Markdown, but during that month, Markdown won't work." Well, except they didn't actually mention that, I had to discover it by accident when I, quite reasonably, started using markdown in my logs fully expecting it to be in place already, ready for me to see the effect of my revisions while I made them during the conversion month. I thought the month warning was pretty short, but now I realize the actual change is going to be even faster: it looks like they're planning to flip the switch overnight.

 

There are times when it is useful to have links in logs. For example, on the first log of a day, I can explain that the group is signing logs with a single team name, and list everyone in the group. Then I can link to that log for all the later logs in the day.

I link to any TB I picked up or dropped. I also use links to point to bookmark lists supporting challenge cache qualifications. And a few other things. I don't think I've ever linked off-site, though.

Link to comment

One doubt about this issue.

 

Therefore, we are recommending that users convert their own logs.

 

Will finders have the chance to change the content and/or type of log (DNF to Find, ie) when editing?

 

This question is because it seems that log editions are not registered anymore with an aditional line as it used to be.

 

I edited this log, several hours after having written it and there is no line registering my post edition.

 

Link to comment

One doubt about this issue.

 

Therefore, we are recommending that users convert their own logs.

 

Will finders have the chance to change the content and/or type of log (DNF to Find, ie) when editing?

 

This question is because it seems that log editions are not registered anymore with an aditional line as it used to be.

 

I edited this log, several hours after having written it and there is no line registering my post edition.

There is an allowed window of time for editing without the edit note text. I'm thinking 24 hours, but it might be shorter.

Link to comment
I link to any TB I picked up or dropped. I also use links to point to bookmark lists supporting challenge cache qualifications. And a few other things. I don't think I've ever linked off-site, though.
I used to include offsite links, when my personal signature items were trackable at a third-party site. But I don't think I've included offsite links since that tracking site closed (under the weight of spammers). But I do occasionally include links to trackables, to bookmark lists for challenge qualifications, to other logs, and occasionally other geocaching.com pages.
Link to comment

One doubt about this issue.

 

Therefore, we are recommending that users convert their own logs.

 

Will finders have the chance to change the content and/or type of log (DNF to Find, ie) when editing?

 

This question is because it seems that log editions are not registered anymore with an aditional line as it used to be.

 

I edited this log, several hours after having written it and there is no line registering my post edition.

There is an allowed window of time for editing without the edit note text. I'm thinking 24 hours, but it might be shorter.

 

 

I just edited this log written on Dec. 16th and there is no edition notificanon line. Seems that something has changed regarding logs traceability. Can you try to edit one of your old logs and confirm?

Edited by MAntunes
Link to comment
I just edited this log written on Dec. 16th and there is no edition notificanon line. Seems that something has changed regarding logs traceability. Can you try to edit one of your old logs and confirm?
That sounds like a change. I used to get the edit notification line if I edited a log an hour or so after initially creating it.
Link to comment

Hmmmmmm just read about this change ... as one of the 3% who use UBB code to customize my logs ... I like color ... I'm sad to hear of this change

 

with over 19,000 finds I was a little concerned that I might have to edit my logs and was just a little daunted by that prospect after following the link to view a sample of Markdown and entering one of my challenge cache report logs ... the result was a mishmash of code, code words and caches selected to qualify for the challenge ... in a word, it was a mess

 

I just read the actual announcement and was happy to see that line breaks will be preserved ... since the rest is just window dressing I won't be editing my logs after all ... I'll go caching with the time saved

 

I'm very sorry that there won't be color but I'll just have to learn to live with that. :)

 

Cache on

Edited by two bison
Link to comment

Seems that something has changed regarding logs traceability. Can you try to edit one of your old logs and confirm?

 

This has been changed a couple of weeks ago (allegedly because of the text which was English only).

project-gc.com had to change their system of notification about log changes caused by this change.

Link to comment
Our tech team discussed the possibility of cleaning up old logs. Unfortunately, the risks associated with altering/scrubbing 560 million logs (not counting trackables) is too high to run any kind of cleanup without some bad consequences: i.e., loss of data, corruption, etc. Therefore we have decided to recommend that users convert their own logs.

 

Has anyone at Groundspeak thought about possible corruption of existing logs that e.g. contain lines that start with

_Blank

*Blank

+Blank

Number.Blank

 

etc

 

E.g. what would happen with a text like

 

1. & 2. Stage: Some text

3.- 7. Stage: Some text

8. Stage: Some text

9. Stage: Some text

 

Will it be changed to the following?

 

1. & 2. Stage: ....

2.-7. Stage

3. Stage

4. Stage

 

Comment: The notation x. Stage is the standard numbering in e.g. the German language for referring to Stage x - there is nothing like x-th.

Edited by cezanne
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...