Y'all:
Given the short lifespan of much hardware, a hardware based key is a bad
idea. Over the years, this has been a problem for me. Even though
vendors will issue new keys, it is still a big hassle and stops one from
working.
Per-user keys, on the other hand, do make sense and seem to strike a
decent balance. Easy piracy is discouraged and users can back up keys,
switch hardware and so on. In spite of the infinite worth of God's Word,
the earthly economic value of a copy of it is rather small, and the
means to protect it should be in line with that fact. There is also the
problem that those quite weak in the faith or seeking may be unduly
discouraged from access to God's Word if put to trouble for it, thus, in
God's providence, spiritually harmed.
For what it is worth,
Tom Sullivan
i...@beforgiven.info
FAX: 815-301-2835
---------------------
Great News!
God created you, owns you and gave you commands to obey.
You have disobeyed God - as your conscience very well attests to you.
God's holiness and justice compel Him to punish you in Hell.
Jesus Christ became Man, was crucified, buried and rose from the dead
as a substitute for all who trust in Him, redeeming them from Hell.
If you repent (turn from your sin) and believe (trust) in Jesus Christ,
you will go to Heaven. Otherwise you will go to Hell.
Warning! Good works are a result, not cause, of saving trust.
More info is at www.esig.beforgiven.info
Do you believe this? Copy this signature into your email program
and use the Internet to spread the Great News every time you email.
On 12/30/18 3:32 AM, David Haslam wrote:
Wouldn’t the points about HTML apply just as equally to the existing
ShortPromo key ?
Some front-ends already jump to the URL specified in the href, and can
open a browser to do so.
David
Sent from ProtonMail Mobile
On Sun, Dec 30, 2018 at 00:39, Jaak Ristioja <j...@ristioja.ee
<mailto:j...@ristioja.ee>> wrote:
I like the idea, because it is useful information for the users. Here
are some of the thoughts I gathered for this:
<brainstorm xmlns="https://en.wikipedia.org/wiki/Brainstorming";>
Why can't the About= entry contain this information?
I'm unsure whether "UnlockInfo" is the best name.
Is it safe to assume that this entry will only be relevant for modules
with a CipherKey= entry?
Using HTML might be a can of worms:
* What version of HTML is permitted?
* How do we ensure future-compatibility?
* If the contents for the UnlockInfo field are to contain a segment of
HTML (and not a whole HTML document), what is the content model?
* For example, would it be safe to embed the contents of the
UnlockInfo field directly inside a <td> element or should it be a <p>?
* Can UnlockInfo= contain
<img>/<audio>/<video>/<object>/<embed>/<script> etc elements?
* How about attributes, e.g. <strong
style='background:url("http://track.me/I_consent";)'> or <span
onClick="doBadStuff()">?
Modules can originate from untrusted sources. I think it might be a bit
too much to assume that all frontends can properly sanitize the HTML
value, unless we only allow a very restricted subset of the HTML syntax,
e.g. only plain text, HTML entities and <a> elements only one allowed
and mandatory href attribute. Note that <b> and <i> etc are discouraged
in HTML5, <u> was completely redefined. Will <a> ("anchor") still be
valid in HTML6 or will <link> be repurposed for hyperlinks as well?
Hence I suggest to use a simple URL (or URI, RFC 3986) instead of HTML.
Simple documents (including HTML pages, PDF or any other types of files)
could be embedded using the data: URI scheme (RFC 2397). Frontends could
pass the URI to the OS/desktop/browser to be opened or attempt to
display the information inline (e.g. show a web view widget for
HTTP/HTTPS URIs or similar). Optionally, frontends can display a
warning/confirmation dialog to the user before opening the URI.
Perhaps it would be wiser to have two fields: one for the URI and
another for plain text? I currently have no suggestions for the exact
semantics of naming of such entries, but both of these could be
displayed by frontends. The plain text could be a description of the
URI, or contain full information about obtaining the key. One or both of
the entries could be optional. Frontends could opt to detect URLs in the
plain text as well and render these as hyperlinks.
Or perhaps we should use a subset of markdown or similar instead?
However, other markup languages could suffer from problems similar to
HTML.
</brainstorm>
J
On 30.12.18 00:02, Troy A. Griffitts wrote:
> Dear Frontend Developers,
>
> In an effort to gain more publishers-- even those who desire to lock and
> sell some of their modules, I would like to add a new .conf entry:
>
> UnlockInfo
>
> Up until now, we've relied on the About entry containing something that
> lets the user know how to obtain unlock codes from publishers selling
> codes to unlock their modules. This entry would isolate just those
> instructions to a specific entry and would allow a frontend to do
> something like:
>
> If (moduleToInstall.getConfEntry("UnlockInfo")) {
>
> showDialog("<p>The publisher of this modules requires for you to
> obtain an unlock code. This code can be entered below, instructions
> from the publisher are as follows:</p>" +
> moduleToInstall.getConfEntry("UnlockInfo"));
>
> }
>
> Like many of our entries, this new UnlockInfo entry will allow HTML
> links and will likely contain a direct link from the publisher to their
> store entry to purchase an unlock code.
>
> An example would be something like:
>
> UnlockInfo=An unlock code for the Larry Fitzgerald NFL HOF Edition of
> the New Testament, with memorable career moments encouraging the
> believer to press on when those around fall short, may be obtained
> directly from the NFL store here: <a target="_blank"
> href="https://nfl.com/shop/lf-nfl-hof-nt-sword-module";>Larry Fitzgerald
> NFL HOF Edition of the New Testament - SWORD Module</a>
>
> Let me know if you have any comments or ideas,
>
> Troy
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
