I am working on an educational e-commercial website .. In which the user need to authenticate and then the videos on particular topics will be available.. so how can I prevent my video to be screen-recorded...
Different OS's and applications support different mechanisms to try to tackle this - for example:
Microsoft Edge on Windows 10 uses integrated 'Protected Media Path' for encrypted content which will stop simple screenshots working
Website and web app developers may use a number of CCS 'tricks' to achieve a similar affect, although these can usually be workaround with standard web developer and debug tools.
Mobile video typically uses protected memory for encrypted content which will usually give a black screen on capture.
As mentioned in comments and other answers these are all 'barriers' but they don't make it impossible to copy the content - the best example being pointing a camera at the screen a copying that way.
The idea is generally to make it hard enough compared to the value of the content so that people are not prepared to invest the time to work around your barriers.
It is not possible, for a variety of reasons:
There is no Web API for that.
Even if there was, it would be possible to reverse engineer the browser/OS to allow for screen recording.
Even if, for some reason, you couldn't access and modify the software running on the computer, you could connect the computer to a capture card instead of your monitor.
And if you also couldn't do that, you could just point a camera at the screen and start recording.
It used to be the case, as described in this answer from five years ago, that web sites could not reliably tell whether a client's browser was in Incognito Mode. However, in the past few months, I've started encountering sites which are able to throw up a banner that says, "hey, you're in Private Browsing mode, so we won't show you any content."
I have two questions, which are opposite sides of the same coin:
As a web developer in 2019, how would I construct a reliable check for a user's Private Browsing status?
As a privacy-conscious web user in 2019, who might like to keep the meta-information of his privacy-consciousness private as well, how could I reliably generate a first-time-visitor experience from a site that is desperate to track me?
In pre-Incognito days I would have accomplished #2 by using a "clean profile" to visit a site that I didn't want to follow me around. User profiles are apparently still in Firefox, though I suspect they probably don't protect against browser fingerprinting. But I'm not sure whether that is a good summary of my threat model --- my interest is mostly in opting out of the advertisement-driven data-mining ecosystem, without being treated differently for doing so.
I'll leave the main question to others who know how each browser's Private mode may differ from default. I do use Private modes extensively, but when I encounter a page that won't work, I simply use a clean non-private window, then clear all cookies and other stored state again afterwards.
You also mention fingerprinting, which is more insidious. Often it's based on collection by a client-side script, which is detectable but only somewhat defendable in practice. But server-detectable characteristics can also provide a good enough correlation for cross-site, even cross-device correlation.
Fingerprinting is very difficult to thwart. but I recommend using Tor for as much casual browsing as practical, using multiple browsers with your activity partitioned across them in a disciplined way, using a common browser with the best fingerprinting protections or at least using the most common browser config for your platform(s), keep your browsers updated and never install Java or Flash, change your IP address(es) often, change your window size often, and clear all cookies and other stored state often. Use a common platform (machine + display size + os) if possible. Making your browser more unique by loading it up with privacy extensions is quite likely to make you look more unique. There are also a few resources out there that list fingerprinting servers / domains, and you can block those in your machine, DNS, router, or wherever practical.
Keep in mind that Panopticlick and sites like it suffer from selection bias, and also combine all platforms, obscuring how unique your browser is compared to other browsers on the same platform (it's hard to change your platform, but at least you can try to make your browser look more like others used on your platform).
Okay, here's a complicated one I've been breaking my head over all week.
I'm creating a self service system, which allows people to identify themselves by barcode or by smartcard, and then perform an arbitrary action. I run a Tomcat application container locally on each machine to serve up the pages and connect to external resources that are required. It also allows me to serve webpages which I then can use to display content on the screen.
I chose HTML as a display technology because it gives a lot of freedom as to how things could look. The program also involves a lot of Javascript to interact with the customer and hardware (through a RESTful API). I picked Javascript because it's a natural complement to HTML and is supported by all modern browsers.
Currently this system is being tested at a number of sites, and everything seems to work okay. I'm running it in Chrome's kiosk mode. Which serves me well, but there are a number of downsides. Here is where the problems start. ;-)
First of all I am petrified that Chrome's auto-update will eventually break my Javascript code. Secondly, I run a small Chrome plugin to read smartcard numbers, and every time the workstation is shutdown incorrectly Chrome's user profile becomes corrupted and the extension needs to be set up again. I could easily fix the first issue by turning off auto-update but it complicates my installation procedure.
Actually, having to install any browser complicates my installation procedure.
I did consider using internet explorer because it's basically everywhere, but with the three dominant versions out there I'm not sure if it's a good approach. My Javascript is quite complex and making it work on older versions will be a pain. Not even mentioning having to write an ActiveX component for my smartcards.
This is why I set out to make a small browser wrapper that runs in full screen, and can read smartcard numbers. This also has downsides. I use Qt: Qt's QtWebkit weighs a hefty 10MB, and it adds another number of dependencies to my application.
It really feels like I have to pick from three options that all have downsides. It really is something I should have investigated before I wrote the entire program. I guess it is a lesson learnt well.
On to the questions:
Is there a pain free way out of this situation? (probably not)
Is there a browser I can depend on without adding tens of megabytes to my project?
Is there another alternative you could suggest?
If you do not see another way out, which option would you pick?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
So I am planning to make an existing website mobile friendly. The good part is that it is entirely text based with a few images which can likely be omitted from the mobile version of the site.
The bad part is that it is a VERY complex site with a ton of pages (and each page can vary based on the data and the user accessing the site) A lot of it is also legacy code (as in, old html which does NOT validate)
So I would like to know what should be the best strategy to make the mobile friendly site? Creating a parallel version is out of the question because that would be a huge task
A separate CSS is obvious. But what about the best practices/guidelines to design for mobile devices to ensure that the site is usable and looks decent?
For reference, the backend is in PHP + MySql and Front end in htmls + CSS and bits of JS (the JS is degradable)
Edit: To be more clear, I would like advice on the design aspect. What are the good practices in designing for mobile devices?
A few quick tips for designing for mobile:
Vertical scrolling only, not horizontal.
Make links large enough to easily press with a finger (If it's a touchscreen device).
Keep pages small (under 20KB is best) - including any image or css files
Accept that some devices will render some element differently
Make sure you're XHTML is valid
Choose colour schemes that work even in bright daylight
Only include what is relevant - make the most of limited screen real estate
Try and avoid complex navigation
Don't use absolute sizing in CSS
Use minimal CSS and Javascript - test thoroughly when you do use
Take advantage of features that are part of the phone (click to call, etc.)
Mobilize, don't just minimize
Avoid user input where possible (selecting from drop down is preferable to entering text - when possible)
Test, Test, Test! (emulators first, then borrow your friends and colleagues phones to enable testing on a wide variety)
Design for short periods of user interaction - make it quick and easy for the person to complete a task.
Be consistent - follow design guidelines and defacto standards
Use accesskeys for links
Hope these help.
iPhone specific answer:
For the iPhone, I'd choose not to optimize. Safari for iPhone is very capable of displaying webpages as they are. Check this answer, and the question for more about iPhone optimization.
General answer:
I'd agree with mr-euro for the technical optimization. Design wise you'd have to take into consideration a small resolution (like 320x240). I'd leave the drop down out or any fancy javascripting for that matter. Most mobile devices aren't very good at handling scripts and tend to become sluggish.
If you manage to convert the site to W3 validated XHTML 1.1 then it would render properly in a mobile phone browser.
You could try to setup another server which proxies the request from mobile browsers to the real server and feed them to a program such as tidy, which can build valid (X)HTML from pretty ugly HTML. This may let you use the existing service with absolutely no change, at some processing cost.
You can find a small ruby example here (which uses a local proxy).
I think you have to be more specific here. Mobile browsers for regular cellphones are really primitive. If you target them, you have to make sure there is nothing "hard". The page basically should be just short pieces of text with full-width images.
If you target iPhone/whatever touch, you only need to kill flash/java, hovers and other non-touchable things you most likely don't have at all. Mobile Safari is truly like his big brother, you don't really need anything specific.
For Blackberries and the stuff, I'm not sure, but check out wsj mobile site as an example.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Keep in mind that I'm not looking for a list of current browsers to support, I'm looking for logical ways to make that list, backed by some kind of hard statistics.
Since it's been a while since my last web job, I decided to do this latest site up from scratch. Now I have to decide again what to support in terms of browsers. Certainly I have a list of what I'd like to support, but the decisions that went into that list seem to be a little arbitrary to me. Where can I go to get a reliable picture of browser usage and what seems to be a good point at which to cut off an old version of a browser from support?
Browsers don't die out completely for about a decade. The first thing you must realise is that you will have some visitors that are using a browser you don't support. The question is not which browsers are not dead, but which browsers are worth supporting (the benefit) relative to the work it takes to do so (the cost).
I've never seen browser statistics I'm comfortable recommending, they all seem to be snake oil. A rule of thumb I feel is appropriate is that a browser isn't worth supporting if somebody using that browser is going to regularly run into problems on other websites as well. In other words "stick with what everybody else is supporting". To that end, Yahoo's graded browser support is useful.
Ultimately, the best choice depends on your individual circumstances and will change over time. For instance, 37signals have recently dropped support for Internet Explorer 6 and Facebook are slowly heading in the same direction. This isn't a decision that most organisations can make yet, but give it a year or two and you'll see a lot more organisations follow suit. Right now, it's a bold step that you probably can't justify, but give it time.
Don't fall into the trap of thinking that supporting as many browsers as possible is automatically the best choice - it may be that you are doing your visitors a disservice by wasting time working on compatibility with a browser used by five people when you could be improving the experience for the other million users you have.
Also, it's worth considering that you can "officially" not support a browser. For example, one thing I've done in the past is use JavaScript served only to Internet Explorer 5.5 and below (via a conditional comment), to automatically remove stylesheets, JavaScript and replace images with their alt text. Without those measures, the site would be unreadable due to Internet Explorer's many layout bugs, but with it, the site at least works, even if it's too much work to "support" it.
The easiest way to do it is sign up for Google Analytics and add their tracking code to your site (there are a number of similar services, but Google's one is the best I've found). It gives you detailed statistics as to what browsers people who visit your site use.
Once you have a couple of months data, you can start making decisions as to which browsers you will support. I work for a mainstream web company who want to make our site work for as many users as possible, so we consider any browser with above 0.5% market share to be within our testing matrix. However, other sites may choose to only support and test on major browsers such as IE and Firefox.
As a rough guide, the major browsers you'll see are IE 6 and 7, and Firefox 2 and 3. This should cover well over 90% of your audience so is a good starting point for the first couple of months. Then use your analytics data and make a business decision as to whether the potential revenue (or whatever you're trying to achieve) is worth the additional effort it will take to support other browsers.
Added 2008-09-18:
Admittedly one issue with this method is that if your support for some browser types is so bad that your site is unusable with them then it will potentially skew the statistics as those people will stop coming back, and thus those browsers will appear to have a lower percentage of users.
To determine whether this is happening, you can use Google Analytics' detailed breakdown of behaviour for each browser type and version. This gives you the bounce rate, average time on site, pages per visit, and percent of new visits. If the figures for a given browser type and version are significantly worse than others (i.e. the bounce rate is higher, time on site is lower, pages per visit is lower, or percent of new visits is higher) then it's possible that your site isn't supporting that browser sufficiently well and that you might get more users with it if you had better support.
At this point the figures will still give you a reasonable feeling for how important the browser is (i.e. if it you don't support Google Chrome and it is being shown as 2% of your traffic, then it wouldn't jump to 20% just because you added support) so you can use that browser to see how bad your site is, and make a judgment call as to whether you add support; sometimes this may involve fixing only the worst issues and leaving the site imperfect but usable until the browser gets to a higher percentage of users, or out of beta status.
You could take a look at the way Yahoo! supports browsers at Graded browser support.
The browser is dead when (a) a very small percentage of people use it and (b) you don't care about (selling to? educating? whatever your business is) such a small percentage of people.
Unfortunately, you won't find a good answer to this; even if you found some hard statistics on browser versions for visitors to your website, that almost certainly doesn't tell you what you need to know.
What you need to know isn't "what percent of my visitors use Browser X", it's "what percent of my revenue comes from visitors who use Browser X". That one guy visiting your site using an ancient copy of IE might be the managing director of a big company wanting to buy a site license; the 10k visitors you had last month using Firefox 3 might be college students wanting to plagiarize your documentation for an essay.
Really, you need to know your market - not just the raw browser statistics. If you pay the bills by selling stuff to graphic designers, then rock solid Safari support matters a lot more than if you're in the job of selling Visual Studio plugins. Not helpful, I know!
There are 2 main groups to target. (There are plenty of others though)
Group #1 is browsers that use Webkit (Safari for example), Presto (Opera for example), KHTML (Konqueror for example) or Gecko (Firefox for example). These browsers should all get the same markup, CSS and Javascript code (as they're all in the same group of standard-compliant browsers). Only work around bugs in one of these if you absolutely have to and have the resources to do so. Instead, test in the latest stable versions of each (as you're developing so they can keep each other in check as to what the expected behavior is) and (after checking in the nightlies for the bugs) file bug reports. Again, avoid workarounds for a specific browser if you can. Instead, plan a cross-browser compatible solution from the beginning.
With Group #1, you don't have to worry about older versions much, if it all.
Group #2 is browsers that use Trident (IE for example). Target IE versions you care about and still only workaround the most severe bugs.
Also, don't deny browsers you don't officially support. Let them fend for themselves instead of blocking them (either intentionally or through crappy browser detection).
Also, remember that when looking at market share percentages, try to figure out the numbers they represent so you can see how many millions of potential visitors with that browser there are. 1% or 5% might not seem like a lot, but that could still mean millions.
Most of all, listen to the visitors. If you're getting multiple complaints about a certain browser, look into it if you can. Even if it's for a browser with low market share, if it's a trivial fix, you should just do it.
Ones that are definitely not dead are: IE6 (starting to push it), IE7, IE8, latest Opera 9.x, latest FF 3.x, latest Safari 3.x and others that have about the same capabilities. FF 2.x isn't dead either and is needed for Win9X users (if they don't want to use Opera)
See also this topic
You should use a good UI framework that solves most of the compatibility issues among browsers, like YUI!, jQuery, and so on...
Personaly, I recommend YUI!
Try to answer this locally, consider your audience. For example when I was developing my own Blog Engine, my appeal was mostly to .NET developers. I hope it stands to reason what browser I primarily develop for. From that point I consider the market share and try to ensure a "reasonable" support level for all other browsers. For example even .NET developers occasionally use Firefox, maybe even Opera. Safari and Chrome are possibilities too now. So my current level of support ranks in this order:
It MUST run perfectly in Internet Explorer 7. All features I intended to build are there
It MUST run reasonably in Internet Explorer 6, Firefox 3.0, Opera 9+ and Safari for Windows, not everything has to be flawless, but it can't look downright ugly either
Everything else I don't care about. I just don't have the time and willing effort to support everything.
How do I determine whether or not I want to even consider supporting another browser or continuing supporting one of the above browsers any more? Simply I look at the market share and the statistics of who is hitting my page. If someone is dying, or I just haven't seen them in awhile, then I consider support dropped.
So in short, I would simply make a statement to yourself about the browsers that must run your code perfectly then reasonably and update periodically as the browser world changes. For the first run of your website, just think about your audience, for subsequent updates, your statistics should tell you enough.
My (very poor) solution was to get stats from w3schools and base my decisions on that. While those numbers aren't really terrible, they are skewed because viewers of that site are more likely to be upgrade-conscious. Also, it doesn't give a breakdown of any browser versions except FF.
If you purely build to standards, some browser won't render correctly since no browser supports all standards. You have to pick a few browsers and test your site in those.
Don't try to be too bleeding edge. If you must use some cutting edge CSS, then you have to expect it not to work 100% of the time.
What are you really going to do with the list? Are you planning to block browsers you don't support? What if the user hacks the User-Agent response?
Like others, I would strongly suggest going with something like Yahoo's "Graded Browsers" and, if possible, leveraging YUI or other libraries so you don't have to do it yourself.
<1% market share isn't a criteria - esp if the browser is new.
For me, < IE6 is dead, and the HTML monkeys I work with WISH it was dead. < FF2 is dead. Opera is a nice to have. < Safari 2 is dead, tho most are designing for Saf 3 now.
So it's:
IE6,7,8
FF 2,3
Saf 3,4
Chrome (which is basicly Saf4)
But depending on your app, and how many people you think you are going to get wih hold machines, you COULD drop IE6, which would make your life so much easier.
I would say IE6 and below are dead... but many are still stuck using it.
This site has a nice live listing of each browser and its actual age.
http://webbugtrack.blogspot.com/2008/08/browser-life-statuses.html
I'd go with the http://browser-update.org/ defaults, which currently say the following are dead:
IE <= 6
FF <= 2.0
Op <= 10.01
Sf <= 2.0
My opinion (has always been) build it to the standards and leave it to the browsers to render it correctly.
Start with the browser with the highest market share and work your way down from there.
If you have existing metrics on browsers that visit your site, use those instead of the general market share.
Whichever has < 1% market share.
I agree with Unkwntech.
You should try to make the website compatible to both IE and Firefox
It's simple - most users keep using the browser that came with the PC when they bought it (think of your mom). The browser is dead when the machines that it pre-installed with are not longer used for Internet access... which is probably around 5 years. As prices of new PC's drops and they become more of a consumer electronics item then this period will drop as people will easily buy a new PC