I am writing a website that will be publishing content that has high IP and we would like people to pay for it. To prevent screen capture consistently, I know that there are limitations in using Javascript + flash + html.
I have discovered artistscope which seems to make it impossible to do anything of that nature. I am happy to inconvenience the user as they view my webpage but lock it down.
Does anyone have any experience with this framework?? I understand all users will have to install a plugin that some antivirus software has flagged and i'll just need to add some mark-up to the article page.
Does anyone know anything about artistscope solution and what is involved in implementing it or how well it works??
If its only a few users, I'm guessing you'll require registration? if so you could use legal copyright to protect intellectual property. Use Creative common's, TradeMark your sitename, use registered post to send content to yourself before you post it online that way you can prove in a court that its plagiarized and you were the first to copyright it. This sort of reminds me of this article: http://thedailywtf.com/Articles/Lock-and-Key-.aspx and maybe your site should be in stone, a safe or as a MagicEye. As Greg mentioned there is no bullet proof solution, guys like us will come along and write auto-OCR readers to scan your site and get foreigners to run the app. If you had a legal notice, I'd at least think twice.
Edit: maybe you could even get creative with Captcha's too to deter people (when you detect copyright infringement), here's an idea to two: Is there an efficient algorithm for segmentation of handwritten text?
I also have used Artist Scope solutions, but when it comes to screenshot, it is not enough.
I've just written this post about protection against screenshot and other content grabbing methods like snipping tool. I'll update it soon for other protection methods that I followed in my blog.
Here's a general description of my approach:
It only works for restricted content; content that needs registration to view it.
It requires continuous monitoring by the administrator because...
It detects screen print key and sends an email to you with the username and other details of the person that has already captured your content (If you are aware of any method that bans the user automatically, I'd be glad to hear it).
It covers your content with an overlay if the user tries to capture it while outside the browser window.
Related
I'm reviewing and recommending changes/fixes to a small web application which was recently enhanced to be more accessible.
The problem I keep running into is that there doesn't seem to be anything which details how screen readers should (or even do) work.
For instance, if you look at the Accessible Rich Internet Applications (WAI-ARIA) 1.0 specification for a TabPanel and the Authoring Practices guide state a basic definition and how it works, but doesn't really answer a question like "should the screenreader speak the contents of the TabPanel when it becomes visible?"
That example is problematic in that I need to convince the business requirements it shouldn't be spoken, yet nothing actually says one way or the other. (The best I can do is point out that the examples from the Authoring Practices guide are not spoken.)
For that, and a half dozen other issues it would be really nice to have a guide that says "This is what a screen reader does (or should do) when it encounters this element/role."
Does that exist?
There are some very simple principles:
Screen readers will default to start reading the page in DOM order from the beginning to the end. This will be preceded by some basic stats of the page such as the title and the number of links, headings etc. However users will generally not simply allow the screen reader to completely read an entire page and will interrupt the reading to start navigating
If a user knows the page, they will choose a way to navigate to the things they know on the page. Common navigation mechanisms are by headings, forms, landmarks, links, tables etc. If the user does not know the page, they may navigate and explore using different strategies similar to the way that a sighted user would scan a page with her eyes.
When the user navigates, they move their virtual cursor. Normally the focus will follow this cursor jumping from focusable element to focusable element as they are encountered (this is configurable). The screen reader will read out whatever it encounters as the user navigates this. This is akin to a sighted user scanning the page for what to read. The key here is that THE USER NEEDS TO CONTROL WHAT IS READ OUT by navigating around. The one caveat for this is that if the user activates a control that causes some other part of the page to be updated and a sighted user would expect to know that it has updated immediately or know its value, then the application should read this out using ARIA-LIVE.
As you will note, that last point is where this crosses from the technical accessibility into the usability realm. Here are some common mis-conceptions that novices hold.
You need to make everything tab focusable for screen readers: NO you do not, the screen reader can see everything without it being tab focusable,
You need to announce every update to the page: NO you do not. If a user is interacting with a tab, they know through experience, that selecting the tab will expose its contents and there are keyboard commands to get to that content. You do not need to even tell them that the tab has been shown, you simply need to update the selected state of the tab.
You don't need to announce anything: NO, you do need to decide which information is important enough to announce automatically. For example, if you are implementing a chat application, it would be dumb if the user had to navigate around to hear that messages have arrived from her friends. These should be announced automatically.
I strongly suggest that you bring a blind screen reader user into your organization and have them demonstrate to your execs how they do things to illustrate these points.
UAAG
You have to look at the User Agent Accessibility Guidelines (UAAG):
http://www.w3.org/TR/UAAG20-Reference/
They are not intended to define what a screenreader might do but what informations must give the user agent to assistive technologies.
For instance, for giving the focus to a tab panel, you can read the following points:
2.1.4 Separate Selection from Activation
3.3.1 Avoid Unpredictable Focus
Guideline 4.1 - Facilitate programmatic access to assistive technology
5.1.1 Comply with WCAG
WCAG
The WCAG defines what a web developper should do to make his content accessible. It wont tell you how the screen-reader will react, but how you should act to provide the needed informations.
For instance, the focus does not have to trigger a change of context
http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/G107
But as long as the user ask a change of context, that's ok.
And the position of the focus will then define the data to be read, except the case of aria live regions.
Important : Accessibility and screen-readers are two different things
You can't resume your accessibility policy to screenreaders only.
And you won't find guidelines oriented to screenreaders only. They are made the general way to not forget all kind of people with disabilities.
That being said, a screenreader will chose the way it acts in the most predictable way. The only thing you might do is testing that your application complies with a logical way of doing things. And if a screenreader does not act as normal, it might be a misconception that could be improved either in your code, either in the assistive technology.
This may sound like an opinion answer, but I believe there's no reliable documentation - mainly because each individual accessibility user has particular requirements of their screenreader. Some don't need text to be spoken aloud while others do. Some have selective preference of what is spoken out. You're even able to change the speed at which text is spoken aloud.
Since all of the major screenreaders are highly customizable down to extremely minute details, this is all dealer's choice.
However, by having the standards and requirements set out for developers to follow and produce consistent applications, it allows the screenreader to interpret information consistently so that the user has the best experience possible. How the screenreader relays this experience is purely up to the user.
One small note, I've addressed my answer directly to screen readers and not the typical WCAG/ARIA guidelines which are widely available and specific enough to achieve what you need as a developer.
Using the encoder it displays this message
<!--
Page protected by ionCube - HTML/JavaScript Encoder
Copyright (c) 2003 RWJD.Com and ionCube Ltd. All Rights Reserved.
Any analysis of this source code, embedded data or file by any means and by
any entity whether human or otherwise to including but without limitation to
discover details of internal operation, to reverse engineer, to de-compile
object code, or to modify for the purposes of modifying behavior or scope of
their usage is forbidden.
-->
Is it possible to change that message to include a policy? Like edit that comment? Its really annoying because it needs to be changed to my written one that my lawyer wrote..
This might be better asked in the ionCube Helpdesk, but that said, I can advise as I am associated with ionCube. Modification of the paragraph below the copyright message would be permitted in this case, however as the obfuscation is generated dynamically at runtime and as the script does not have a feature for providing a replacement legal notice, this isn't entirely trivial. You could try installing an output handler after the obfuscator is included so as to catch the output produced by the obfuscator. Your handler could then do a search and and replace on the output.
Please be aware of the hopefully obvious limitations to client side protection and trying to hide HTML and Javascript in this way. The obfuscator, which was donated by an early ionCube customer, is quite clever and a free example of an encoded file, and a decade ago also very effective. As browsers evolved, plugins and then native features for DOM browsing became standard making it easy to regenerate HTML from the DOM, i.e. after any deobfuscation has run.
While most users to a site would not be aware of how to recreate HTML in this way, it's equally the case that they're not going to care about doing so; most visitors just want a site to work, be responsive, and not have navigation and other features broken by tricks such as right click disabling. Those who would want to steal HTML would know how to via DOM inspection, and they would also know how to access data from browser caches, would take screenshots if necessary to steal images rather than need right-click "save image", and so on. There are techniques to defeat some of those approaches, but at a cost to every visitor that's not probably worth it. Also note that obfuscation in this way should ensure exclusion of pages from Google, just in case that matters.
That said and noting IANAL, protecting the HTML with the obfuscator may have benefits from a legal perspective as the HTML cannot in general be discovered unwittingly or by mistake, and if someone did steal content, they would have had to have tried, albeit perhaps not that hard.
Hope this helps!
I wrote a trivia game in Flex (flash). The site is written entirely in Flex. Almost all of the text is pulled from a database. It also has a fair number of images. The image file paths are pulled from the db.
My site's not getting any hits. If I check on google site:mysite it the url appears only. I know that inbound links are important and I'll try to get some. At the moment, I don't have any inbound links. In google webmaster tools, if I look under the site's keywords, there are 0. My sites been up for about a month.
Any suggestions on how to improve this situation?
(I've seen a few people ask for help with Flash SEO and the comments tended to be of the "don't use Flash" variety-- which aren't too helpful if you've written something in Flex/Flash).
Thank you.
-Laxmidi
Check out this article: Read Here
SEO FLASH PROGRAMMING
My recommended Flash SEO method uses a
DIV with search-engine-accessible,
primary content, and an open source
Javascript function called swfobject()
to detect when browsers are capable of
viewing Flash. When an appropriate
version of Flash player is present,
the Javascript manipulates the page's
document object model (DOM) to replace
the primary content with the Flash
movie. Most search engine spiders
can't handle Flash, so they will elect
to view the primary content. The
primary content may contain links,
headings, styled text, images—anything
we can add to an ordinary HTML page.
With SEO copyediting and coding skills
applied to the primary content, Flash
becomes a non-issue.
Flash accessibility programming isn't
spamming, as long as the primary
content and the visible movie are
essentially the same. The World Wide
Web Consortium (W3C) Web Accessibility
Initiative (WAI) specifically states
that multimedia content should have an
alternative representation available.
Accessibility programming creates the
benefit of presenting visual
information without losing the
visitors and search engines who depend
upon textual content.
As of July 2007, I discussed this
method with Dan Crow of Google. He
warned that this programming method
could draw attention because of the
possibility for abuse. If you use this
method, make sure the alternative
content is a faithful representation
of the Flash content, and avoid
combining this with other coding
methods that could be abused. While
this SEO method is not abusive, it is
aggressive because there is a small
risk that the search engines could
mistakenly decide that the primary
content is a form of cloaking.
I would also create a sitemap and link to multiple keyword rich landing pages about your game with a link back to the game. The more content google has to bite into the better changes someone will find you.
You also need to market your site...just because you build it doesn't mean they will come. Use twitter, facebook and any other form of social media to get the word out. You may also try buying a few bucks worth of ad words to start the ball rolling.
The solution to only the url appearing in Google is probably as simple as adding a meta description tag.
http://www.google.com/support/webmasters/bin/answer.py?answer=79812
http://googlewebmastercentral.blogspot.com/2007/09/improve-snippets-with-meta-description.html
It would also probably be beneficial to provide a description or instructions for the trivia game in HTML alongside the Flex part of the website, if this is possible.
I have started developing a webpage and recently hired someone to write code to display a customized feed (powered by API) in the middle panel on http://farmball.com/. Note that this is not the RSS feed tied to the site blog. The feed ties to my account on another site. There is no RSS link for an average user to subscribe to the feed. I've taken the site out of maintenance mode to ask anyone here with scraping/hacking experience how someone would most easily go about 'taking' the feed and displaying it on their own site. More importantly, what can I do to prevent it?
^Updated for re-wording
You can't.
If you are going to expose an RSS feed which you don't want others to be able to display on their site then you are completely missing the point of RSS. The entire reason for Really Simple Syndication (RSS) is to make your content externally consumable- whether that's in an RSS Reader or through someone simply printing its content on their own website.
Why are you including an RSS feed if you do not want someone to be able to consume it?
what can I do to prevent...'taking' the feed and displaying it on their own site?
Nothing. Preventing reuse goes against the basic concept of RSS, which is to make it as easy as possible for anyone to do anything they want with it. It was designed from the ground up to be Really Simple to Syndicate, not Really Hard to Retransmit Without Permission.
You could restrict access to the feed itself to trusted users only by making them provide some credentials or pass in a key to the feed (e.g. yoursite.rss?mykey=abc123). But you cannot control use. Only access.
Be explicit about your license. It isn't a technology solution, as others have mentioned, the technology is an open technology-- this isn't DRM! But if you ask in each post that people who use this feed to not repost/fail to give credit/etc then some people will respond to the request.
Otherwise, you're better off putting your content behind a password and using a paid subscription model for distributing your content.
This is a DRM problem essentially. If you had some technique that you could put content on the web without having it redistributable, the music industry would love you.
It is possible to try to prevent redistribution. One technique you could try is embedding a signature of some sort into the feed for each user who you require to sign up. If the content is found on the web, you can identify and ban the user who redistributed your content.
This is avoidable too, by getting multiple accounts and normalizing the content to remove fingerprints. For the would-be pirate, this requires more effort than they may be willing to put in. Your signature could be a unique whitespace pattern, tiny variances in the timestamps on posts, misplaced pixels in videos, or any other thing you can vary slightly without end users noticing.
use .htpassword
better yet, don't put something private in a public place where it's likely to get picked up by software automatically. Like others have said, it's a pretty odd question, if you're trying to figure something else out, you're better off being explicit with what you want to know.
There are probably thousands of applications out there like 'Google Web Accelerator' and all kinds of popup blockers. Then theres header blocking personal firewalls, full site blockers, and paranoid cookie monsters.
Fortunately Web Accelerator is now defunct (I suggest you read the above article - its actually quite funny what issues it caused) but there are so many other plugins and third party apps out there that its impossible to test them all with your app until its out in the wild.
What I'm looking for is advice on the most important things to remember when writing a web-app (whatever technology) with respect to ensuring the user's environment isnt going to break it. Kind of like a checklist.
Whats the craziest thing you've experienced?
PS. I may have linked to net-nanny above, but I'm not trying to make a porn site
The best advice I can give is to program defensively. For example, don't assume that all of your scripts may be loaded. I've seen cases where AdBlocker Plus will block 1/10 scripts that are included in a page just because it has the word "ad" in the name or path. While you can work around this by renaming the file, it's still good to check that a particular object exists before using it.
The weirdest thing I've seen wasn't so much a browser plugin but a firewall/proxy configuration at a user's workplace. They were using a squid proxy that was trying to remove ads by replacing any image HTTP request that it thought was an ad with a single pixel GIF image. Unfortunately it did this for non-GIF images too so when our iPhone application was expecting a PNG image and got a GIF, it would crash.
Internet Explorer 6. :)
No, but seriously. Firefox plugins like noscript and greasemonkey for one, though those are likely to be a very small minority.
Sometimes the user's environment means a screen reader (or even a braille interface like this). If your layout is in any way critical to the content being delivered as intended, you've got a problem right there.
Web pages break, fact of life; the closer you have been coding and designing up against standards, the less your fault it is.
Something I have checked in the past is loading some of the more popular toolbars that people tend to install (Google, Yahoo, MSN, etc) and seeing how that affects the users experience.
To a certain extent it is difficult to preempt which of the products you mentioned will be used by your users since there are so many. I would say your best bet is to test for the most frequent products that your user base may employ and roll with the punches for the rest. If you have the time to test other possible scenarios, by all means do.
Also, making it easy for your users to report possible issues also helps lessen the time it takes to get a fix in place should it be something you can work around.