BSB 4 PlugIn

[brak]

Originally Posted by idpnd

Either it will be free software or proprietary dave stuff - eihter way, it won't go with your proprietary software afraid to report

Well, it likely won't matter since it sounds like a windows-only solution - which won't be much good to us. Windows-only BSBv4 SDK is available already, no need to develop anything new.

But purely theoretically speaking, while it is easy to make sure open source software does not become closed source and can't be used with proprietary software, the opposite seems unlikely. I'd be interested to see a license that does that.

[idpnd]

Originally Posted by brak

Well, it likely won't matter since it sounds like a windows-only solution - which won't be much good to us. Windows-only BSBv4 SDK is available already, no need to develop anything new.

Can't see him programming it from scratch, plus there's the dongle issues and all that..

[brak]

Originally Posted by idpnd

Can't see him programming it from scratch, plus there's the dongle issues and all that..

There is no "dongle" involved with BSBv4, as far as I know.

Because it is not programmed "from scratch" (sounds like it may be a wrapper around the original Windows SDK) , the module would have to be usable by essentially anyone under same conditions.

That is to say - it would be analogous to proprietary drivers used in Linux. These drivers are closed source, and they have a permissive license that allows their use with open source, potentially after a payment of a fee.

That permits their use with Linux. It also makes possible their use with essentially anything else, as long as that "something else" wraps the driver around in an open-source library shim, since there is not really a legal way to separate an open-source project as an entity and limit proprietary product use to just that entity (otherwise you'd prohibit it's use with any derivative works which in turn makes that less than useful).

I've been developing open source software for a while now (when I started, "beer license" was pretty popular and GPL didn't exist yet), and came across this issue on both sides - i.e. from the open source end, and from closed source end. It's a tricky issue no doubt, but that's as much as I know.

[idpnd]

I was just watching your polarview youtube video, Ive got to say the interface is very pretty! I like that alarm config window

Is there a dongle for S-63 charts? Are they expensive?

[brak]

Originally Posted by idpnd

I was just watching your polarview youtube video, Ive got to say the interface is very pretty! I like that alarm config window

Is there a dongle for S-63 charts? Are they expensive?

no dongles anywhere (except where they belong ) How did you like the penguin?

S63 is a format and charts really vary in price a lot. For example my set of British Virgin Islands charts (which is only 3 cells) cost something like $36.

A single official chart may cost anywhere from $5 to $20, and area could be anything.

There are Navionics ENCs - these are the same charts Navionics sells directly, but instead of their own proprietary format they are in S63 format. These cover pretty much the same areas as the usual Navionics charts and, as far as I understand, cost about the same. They are always sold as packages. I know a package of Navionics S63 charts for Bahamas is $150, Australia + New Zealand is like $250, I think. Other areas vary from about the same to quite a bit more.

Then Chartworld started building their own packages, in particular for European waters. I think they sell these for about $80-$150 per area.

Personally, I used to dislike Navionics ENCs - they have some additional data structures and formatting issues. No navigation product I know of supported them properly (including ours). However, I just finished working through these issues (literally like 15 minutes ago), so the next update of PolarView handles them a lot better. Now they actually look pretty good.

Here is a small sample of what they look like, NZ coast somewhere.

[idpnd]

Thanks for the extensive info. Being a friend of all things pirate (as in the classical Caribbean sort) yes I did enjoy the penguin

[brak]

Originally Posted by idpnd

Thanks for the extensive info. Being a friend of all things pirate (as in the classical Caribbean sort) yes I did enjoy the penguin

It's a bit of an "easter egg" for anyone that's brave enough to watch the whole thing. Most viewers seem to drop out after 2 minutes

[brak]

Originally Posted by idpnd

Can't see him programming it from scratch, plus there's the dongle issues and all that..

Something that occurred to me today - I think that OpenCPN supporting BSBv4 would pretty much have to be a complete binary distribution, or at a very least, it would have to be a completely separate binary to display charts in its own window, may be transparent or overlay or whatever - but not within OpenCPN itself.

If there was any point at which BSBv4 data is integrated into the actual OpenCPN, no matter how close to the "viewport" that point is, it would act as an "analog gap" (digital gap in this case). It would be possible with a bit of code, to fully recover and save BSBv4 raster data in unencrypted form. Would be good for chart users, but I think chart issuers would be less thrilled.

Still wondering. Yes, I've got too much spare time - my boat's outboard is in a shop, so I can't go out/sailing even though the weather is absolutely beautiful.

[idpnd]

Originally Posted by brak

If there was any point at which BSBv4 data is integrated into the actual OpenCPN, no matter how close to the "viewport" that point is, it would act as an "analog gap" (digital gap in this case). It would be possible with a bit of code, to fully recover and save BSBv4 raster data in unencrypted form. Would be good for chart users, but I think chart issuers would be less thrilled.

Sounds like a clever way to make a BSB4 -> BSB3 conversion tool to me The BSB4 master encryption key can't be exposed obviously

I've read people saying they use their chart software print button to print encrypted charts to a file, or a large number of screenshots to convert encrypted to non-encrypted charts. At the end of the day, if you have pixels on screen you can read them out..

[cagney]

Originally Posted by brak

....

If there was any point at which BSBv4 data is integrated into the actual OpenCPN, no matter how close to the "viewport" that point is, it would act as an "analog gap" (digital gap in this case). It would be possible with a bit of code, to fully recover and save BSBv4 raster data in unencrypted form. Would be good for chart users, but I think chart issuers would be less thrilled.

......

Thinking about this piece above.... I think hat there is a "digital gap" in Polar Navy, and other chart plotters, that use standard hardware, as well. After all the encrypted charts hit he screen unencrypted, so a knowledgeable person that is a bit handy with code and hardware could probably exploit this weakness. I think that the "chart issuers" know about this and are less than thrilled, but accept the risk.

Or,.. am I wrong, and Polar Navy has solved this issue?

Thomas

[mrm]

Hitting PrintScrn and recovering data from clipboard is easy and even if steps were taken to prevent this, it is always possible to take a screen pic with a digital camera, so the whole point of introducing DRM is moot anyway, as - at the end - there is little of no protection offered to publishers and a lot of discomfort on users side.

I think that it all boils down to ethics anyway. Ethics and possibly pricing levels. After all, most people are reasonable and if they find a service useful (e.g. having maps with updates as opposed to maps many years old) they will realise, that not paying will ultimately lead to said service being dropped and will pay (if they can afford).

On the other hand, a point could be made about the ethical side of charging for access to data gathered with taxpayer funds in the first place, which is a norm in EU. I think, that US got this right by comparison.

Getting a bit more on topic: Linux kernel allows closed binary drivers and methods for loading of closed, binary-only firmware to hardware devices, by defining a set of interfaces to said modules. Using such interfaces does not place said drivers/firmware in a public domain, nor forces GPL on them. Maybe OpenCPN could define a similar interface (API) for binary, closed source modules?
For example offering a basic interface to create layers, access to HIDs and information on current scale/projection of a map?

[brak]

Originally Posted by cagney

Thinking about this piece above.... I think hat there is a "digital gap" in Polar Navy, and other chart plotters, that use standard hardware, as well. After all the encrypted charts hit he screen unencrypted, so a knowledgeable person that is a bit handy with code and hardware could probably exploit this weakness. I think that the "chart issuers" know about this and are less than thrilled, but accept the risk.

I know you are trying to make a point, but I also think you understand quite well what the difference is It's the level of required effort that makes a difference.

While in theory it is possible to disassemble a program and get data from within, practicality of that is quite low. I've been doing that many years ago, back when programs of a few hundred kilobytes (geez, I am old ) could be relatively easily read with a simple disassembler. It was not fun then, and it has gotten much harder since. I've last had to deal with this issue disassembling malware a few years ago and even relatively compact malware is now a bear to take apart.

It is not impossible, of course - just pretty darn difficult, especially if program takes certain specific precautions. Some programs do more than others wrt protecting data. I am not going to name names, but I was able to trivially recover S63 encryption keys from another product by using a few basic Unix command line tools. So - the answer with respect to non-open software still is "it depends".

Moreover, there is no need to go that far - there is always an image on screen, that you can simply capture and save, then rebuild There would likely be significant issues with quality of that type of chart (unless you can guarantee that at some level chart is shown on screen pixel for pixel, and perfectly georeferenced), but hell - it is possible.

That said, level of effort makes a difference. It is possible to guess a password stored in encrypted form, in theory even by brute force - but it may take many years. It is a lot easier to do if the password is stored in clear text.

But, all of that takes work, and so far I have not seen anyone willing to spend the time. Having an open source product that can handle encrypted charts changes the balance quite a bit. Somewhere in the portion of the application where chart data becomes image/bitmap what have you, you can add with relative ease a piece of code that iterates over raw bitmap data and saves it into a file. This also takes effort, but surely you will agree that a code to open a file, iterate over a chunk of binary data, save it and close the file is not difficult to implement.

The most important barrier that is taken away is the need to discover functionality based on binary code. It takes the problem from realm of few dedicated hackers into a realm of many reasonable able developers.

It's all an effort vs reward issue, really. Once it becomes easier to do and the effort pays off - it will be done.

That's just my opinion, of course, and I am sure time will tell how it will all play out.

[brak]

Originally Posted by idpnd

Sounds like a clever way to make a BSB4 -> BSB3 conversion tool to me The BSB4 master encryption key can't be exposed obviously

I've read people saying they use their chart software print button to print encrypted charts to a file, or a large number of screenshots to convert encrypted to non-encrypted charts. At the end of the day, if you have pixels on screen you can read them out..

Yep, see my answer above. It's the effort and the quality of result. If it takes a few days of copy and paste to recover a chart in less than perfect quality, paste together, re-georeference etc, chances of this being done on a wide scale are unlikely.

If it takes 10 lines of code (written by someone else) to recover a digitally correct copy of data - it will be done.

Think of it as a difference between taping by holding a VCR in front of a movie screen and DVD ripping (though both are done, since stakes are higher). Incidentally, DVD ripping was made possible without any open source software, so I would not claim that open source is the only conduit or even a necessity for that (just in case it sounded otherwise).

However, as it happens, true hackers (and I use this word in a sense of "people that like to find out how things work") for all sorts of reasons, seem to rarely intersect with people interested in marine navigation. So their aims do not align often, and there is not a whole lot of money to be made in this business anyway. Which is why, imho, *so far* encrypted charts seem to have been relatively safe, even though encryption schemes that are used are by no means more difficult to break than DVD was.

Open source would simply inject an additional dimension into this. If I had to guess, if OpenCPN gets a true BSBv4 support that goes across the actual open source version, I would expect a patch to save un-encrypted chart data to be available very quickly.

Again, time will tell - that's just my guess and I wouldn't bet more than a 6 pack of Corona on it.

[brak]

On the topic of ethics, and as an aside - one of the most common search queries for PolarView is "PolarView crack"

Some people are ethical, others aren't. I am not sure what the proportion is, but the second group is clearly at least a significant presence among us.

Given an option not to pay, that group will take the option.

[mrm]

Sadly, you probably have a valid point re (un)ethical proportions.

On a technical side. If there is a Windows-only BSBv4 SDK, it might be technically possible to wrap it in WINE layer under Linux (and maybe this could work for Macs too).