Can we discuss Read-Only PLUS block downloads & print & copy?

#1

Background: It is easy to hide controls in online TW’s using CSS to make it “Read Only”. But this doesn’t prevent someone familiar with TW easily removing that block.

For instance I am really interested in @Springer’s Writing Coach.
I easily switched off it’s Read Only and downloaded a copy to study how it works.
But I’m not sure if @Springer is okay with that?

I have another test case. I teach advanced movement routines but am holding back from using TW to publish the instructions for them because they are unique and take days to develop.
I’m happy to have them used; but not copied, printed or downloaded.

What are my questions?

  1. How can you totally block download of a TW?
  1. Switch off any ability to print a TW?
  1. Prevent text copying in TW?

Wondering
TT

1 Like
#2

Good questions. I’m not sure these are just TW questions. Once something is up on the web it can be screenshotted, copy/ pasted, printed and generally abused. :frowning:

A static version of your TW would make it just like any other website i guess.

Stick your desired level of creative Commons copyright on it and hope for the best!

2 Likes
#3

Right.
Yet the Q.'s still are relevant to TW insofar as it’s “Read Only” is generally seen as ONLY about CSS hiding.
On many sites they go further than CSS to prevent stealing your stuff.

So, I sorta think, that Read Only might be bolstered for TW to be able to block printing and downland — i.e. not just hide buttons?

Right.

No workaround on that. However, on that, it is easy to frustrate it :rofl:. With a 300 sentence lesson given, on-screen, one sentence at a time.

Tx for your comment
TT

1 Like
#4

Your goal is the exact opposite of TiddlyWiki’s purpose. TiddlyWiki itself stores all data within a single JSON data segment.

1 Like
#5

I very much doubt that. Please give an example of where it says “you can never stop your wiki-data from being misused”.

My understanding is that @jeremyruston is agnostic on the uses of TW.

TT

#6

I feel that what you are aiming for is never really going to be reached. Yes, other systems do more in the way of trying to block people from doing things like printing and saving and all of them pretty much fall flat on their face as soon as anyone with any determination and access to a half-decent search engine make any efforts to circumvent them.

In essence - when someone accesses a web page (which is what TiddlyWiki is) then the information for that page is transmitted to their computer. It wouldn’t be able to display the page otherwise. Because the information is on their computer, now, they are the ones in control of it. Anything you do to dictate how they use that information is trusting their web browser to do what you want and not what they want. That’s always going to be a losing battle on your side of things.

So - the answer to your three questions is “no”, because that is the answer for any web page out there. You can do things that will mess with the user’s browser interface, but only if it lets you. There are plenty of web browsers out there that simply won’t and there are plenty of ways to get the most common web browsers not to.

6 Likes
#7

Look at my last sentence. Currently, TiddlyWiki information is stored in JSON fragments. You can see it by opening the HTML source. Unless you modify the underlying design.

I have a solution. You enter your data into TiddlyWiki. Then you record a video showing your TiddlyWiki, without providing the TiddlyWiki file.

1 Like
#8

I second that. What a browser can do with the content you deliver over the web, a dedicated user could do with their own tools. Hiding information from them would also necessarily hide it from the browser.

I do use read-only modes for some wikis, but that’s mostly just to avoid confusing users and ensure they don’t think they can do things they cannot – like save their changes back to my server. I do assume any competent TW user could circumvent it.

1 Like
#9

Thanks @tomzheng, @Gaxx, @Scott_Sauyet & @Ste_W for clarifying that anyone can look at your page “code” if they want and have the knack of doing that.

So humbled, I do feel the O/P might be better, now, re-phrased like this …

Q: What tips do you have to make it difficult to simply steal stuff?

Bear in mind that the number of readers with “the knack” is likely v. low?

So, now, I’m interested most in just making it awkward for anyone to rip off my magnum opus on “The 7 Movements Of Highly Effective Elbows” (whose TW savvy constituency must be near zero :slight_smile: )

So, do you have any tips on …

  • blocking download beyond CSS hiding;

  • messing-up print-attempts;

  • is it possible to use CSS to mess-up “select-text & copy”;

  • anything obvious I don’t know.

TT

#10

@TiddlyTitch pay attention. You won’t “win”. Those of us that walked this tightrope back in the nineties, eventually got over ourselves.

All you have is copyright. Beyond that, a good lawyer.

End of.

2 Likes
#11

To me, this is a Streisand effect situation. If you’re exposing online some information that is interesting to me and make it hard for me to get an offline copy, there’s two scenarios:

  1. I’ll still get a copy, if I succeed by technical means

  2. I’ll ignore it and move on

The big question here is what’s your win in either scenario?

1 Like
#12

@TiddlyTitch Maybe (but I doubt it) you’ll like this:

/* Selects all elements and disables selecting of any/all content */
* {
  user-select: none;
}

Wouldn’t stop me (I’d just find it and kill it) but for your average visitor, not so easy.

1 Like
#13

I think you must be misunderstanding what people have said on this matter. I don’t think anyone in this list was making the case that anyone would need, or even attempt, to digging into the code (or HTML) of the page to do this. I certainly wouldn’t. I would right click and select download.

My web browser automatically ignores all attempts to mess with the right-click menu so no matter what was attempted at the other end, I would be downloading that content.

You can mess with the right-click menu of someone who has a browser that doesn’t have protection. You can go inserting a whole load of invisible characters that will show on print (using different “At-rules” to target different media), you can try all sorts of tricks around messing up copy-and-paste. Just about anything you do is foiled by the fact that the browser of the user has to be able to render the page for them to see it and if it can do it than it can also produce the same ready for both saving and printing, if it is of a mind to support the user over the web designer.

Essentially, you can put a lot of effort in to excluding some users from performing some functions. Far more effort than it would take to circumvent the measures.

I would imagine the best balance to be had in making it hard to copy and easy to produce would be to produce in a video format that never had the whole text on screen and then have that video play. It’s a bit harder for most users to download and replay video from a web source. There are still tools to do it and so someone determined will manage, but… at least it’s relatively low-effort at your end of things.

3 Likes
#14

Don’t put it on the web?

1 Like
#15

What web browser are you using? Chrome currently has 71.22% market share (see Browser Market Share Worldwide | Statcounter Global Stats). Safari comes in second at just 14.35%. All the other “major” browsers (Edge, Firefox, Opera, etc.) come in at under 5%.

For Chrome, you can disable the right-click popup “context menu” by creating a tiddler (e.g., “DisableContextMenu”), tagged with $:/tags/RawMarkup, containing:

<script>
document.addEventListener('contextmenu', function(e) { e.preventDefault(); }, false);
</script>

After save-and-reload, all right-clicks except in textareas are ignored. This single line of javascript effectively prevents the use of the context menu’s “Save as…” function to download the TiddlyWiki. It also prevents simple “highlight-and-copy” actions that could be used to manually “screen scrape” rendered content.

-e

3 Likes
#16

Vivaldi, with a few extensions. I’m not sure if it is raw browser functionality or one of the extensions.

Successfully disabling the context menu will certainly make in unavailable to do save or copy-paste actions from there but will it do anything to prevent that via the browsers main menu, or from keyboard shortcuts?

#17

I think this is the core of the problem here, and will apply to anything done within TW (perhaps with varying levels of “easily”, but I suspect anyone that knows TW well enough to undo the CSS readonly tricks, are not too far away from being able to undo anything else set within a TW)

TW is not well known to the wider internet, so I’d imagine CSS tricks to make it “read only” will make it so for the vast majority of users.

Seems to me that the audience who can get around the TW CSS tricks, but would be stymied by further tricks, must surely be vanishingly small?

Is it worth the effort? Esp when considering that putting content online makes it locally savable to anyone who is skilled and motivated enough (and there are always people skilled enough, and you can’t predict the motivations of others)

#18

In my quick firefox test, it does not prevent.

Method: added a DisableContextMenu as suggested, and it certainly works to stop the context menu. Saving the TW (noting I’m loading the original from a node server via an nginx proxy) from menu or ctrl-s keyboard shortcut, saves a copy to the local Downloads

#19

Absolutely. My educational sites are read-only because the target audience (students) would not be there to learn about TiddlyWiki’s edit features (and hence those features are extra noise that distracts from the clarity of the interface). I leave quick-demo and the bibliographic wiki in author mode (even though y’all can’t save changes to TiddlyHost) because of course I want folks to be able to to poke around at the internals. No need for that with sites that are functioning as ordinary informational web sites for which TiddlyWiki just happens to be the best authoring platform.

No website is good at preventing any of this! Even if you can prevent direct copying and printing, it’s really easy for a savvy user to bypass that with screenshots and browser extensions.

The best you can do is export a static html file that leaves out all sensitive info (behind the scenes) that you don’t want folks to see, or have a public-facing live tiddlywiki that omits some of what you use in authoring mode. (I do that with confidential grading info and such.)

I you want to create css that frustrates straightforward printing (by making tiddlers invisible, or messing up the font, etc.)… this may deter casual printing:

@media print {
.tc-tiddler-frame {display:none;}
}

Again, this is a mere inconvenience-hurdle. Savvy users can get the source code of any website, and can take screenshots of anything they see, and OCR of images is built into many os-level tools now.

6 Likes
#20

If you will allow me to weigh in for a moment.

Effective DRM and other ‘read-only’ mechanisms are generally created to prevent arbitrary retribution of the ‘source’ digital assets, and do so through a combination of mechanisms, especially ones that are “one-directional” like one-way encryption or server-side storage. This usually results in your device only having a segmented and/or transient copy of the source assets. Since computers are kind of designed to allow for arbitrary distribution of data; IP holders general strategy is usually just to increase redistribution friction as high as possible as to make it ‘not worth it’ to the end users in question.

In contrast, one of TiddlyWiki’s stated design principals is being a Quine, therefore a TiddlyWiki must necessarily “be aware” of it’s own entire source data at all times; or else it couldn’t really be a Quine. It’s not conducive to the above stated ‘one-directional’ DRM distribution model.

So in practice while TiddlyWiki is unopinionated enough to be ‘hacked’ to perform a great deal of acts including some form of DRM and data-protection, at some level these goals are strictly antithetical to TiddlyWiki’s base design principals, so users trying to do such are fighting an uphill battle.

Saying all that, I think your best best is to convert the TiddlyWiki content into some kind of user-editable PDF; while not perfect for DRM, PDFs are generally understood by end users to be intentionally immutable and opaque.

Thanks for coming to my Ted Talk.

-Xyvir

2 Likes