In a secure OS, we'd like to not tell applications anything unless they absolutely must know. Say you browse a website through an anonymity network as two different identities by running separate isolated instances of the web browser. The web browser instances can transmit your screen size, and then an adversary could see that both of your identities use the same screen size and make a more accurate guess that they are the same person. Screen size reveals identity or narrows it down.
What are some use cases of why a UI/web page (as opposed to the underlying technology) needs your screen size? Why not just use abstract dimensions for everything? Or use layout widgets that don't let you even touch dimensions. What are the limitations of these techniques?
Related
According to https://coveryourtracks.eff.org/ my Chrome and Firefox browsers disclose seemingly unnecessary information. Why those (and possibly other) browsers readily reveal any of that information?
Fingerprinting information that has nothing to do with serving:
Hardware concurrency
Device memory
Platform
Fingerprinting information that is needed only rarely (if at all) for serving:
User agent: browser and version
HTTP_ACCEPT headers: system language
List of browsers plugins
Timezone
Screen size and color depth; canvas hash
Audiocontext
WebGL vendor and renderer; WebGL hash
I think your'e mischaracterising this. Browsers don't deliberately reveal fingerprintable information; they provide information that is useful in lots of different contexts that also happens to contribute to fingerprinting.
Whether these are relevant for serving can't be determined from the client end. Historically, user agent and screen size/depth were critical in the days before the heavy dependence we now see on Javascript to achieve similar things, when differences between browsers and client platforms was much greater, and many sites are still built that way. For example my bank's web site still has obvious, visible workarounds for IE6. Prior to CSS media queries (around 2009), many things could only be achieved by telling the server about these things, and many of those browsers are still with us.
Knowing whether a browser supports a particular plug-in can also be critical - for example if I want to render a PDF in an iframe, your browser had better be able to render it, and it's useful for a server to know if it can before trying to use it.
You missed off fonts and battery level from your list. These are also very often part of a fingerprint, but at the same time useful for sites to know what to serve to a client.
Some clients deliberately add noise to these values. For example whether a battery is at 10.4% or 12.6% doesn't really make much difference – it's quite low, so adding 5% noise to this information retains its utility while reducing identifiability.
Precisely how much noise you need to add to preserve anonymity, or at least provide reasonable (and measurable) ambiguity of identity, is covered by the concept of differential privacy, which I'll leave you to read up on.
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.
Imagine a scenario in which a game X installed on your mobile device wants to access your account information from social network Y. Assume that Y exposes some API, and have features like "login with Y" etc. On desktop PC X could popup new browser window, with domain of Y clearly shown in address bar, with a padlock icon clearly indicating SSL connection, and in this popup, social network Y would ask user to provide login, password, and agreement to pass some information (like name, avatar, e-mail) to the application X. For example OAuth 2 uses this approach.
In my opinion, on mobile the situation is in rather different, as application X can take control of whole screen. In particular it can draw on the device's screen something that is indistinguishable from a real browser and hijack login and password provided by user.
How one can combat malicious applications which cover whole screen and pretend to be browsers, or even OS's settings windows etc?
There is no technological defense against this even on the desktop. It's trivial to mimic the look of a browser and draw a green SSL lock into a fake address bar. Or you can simply include a key logger with your application to get passwords entered any application on the same system.
For mobile applications including a key logger is harder. Drawing convincing fake browser window is easy. An additional defense is the review process of an app store. An official app store as the only source of trusted apps mitigates problems like this to a certain extent. While malicious apps can slip through any review process, they can be removed once they are discovered.
How about: double-click the home button so you see the app names?
You can also run task manager to see the app's name f.e. com.android.chrome. I think google won't allow in market two apps with same name.
I recently had an argument with someone regarding the ability of a website to take screenshots on the user's machine. He argued that using a GUI-program to simulate clicking a mouse really fast to win a simple flash game could theoretically be detected (if the site cared enough) by logging abnormally high scores and taking a screenshot of those players' desktops for moderator review. I argued that since all website code runs within the browser, it cannot step outside the system to take such a screenshot.
This segued into a more general discussion of the capabilities of websites, through Javascript, Flash, or whatever other method (acceptable or nefarious), to make that step outside of the system. We agreed that at minimum some things were grabbable: the OS, the size of the user's full desktop. But we definitely couldn't agree on how sandboxed in-browser code was. All in all he gave website code way more credit than I did.
So, who's right? Can websites take desktop screenshots? Can they enumerate all your open windows? What else can (or can't) they do? Clearly any such code would have to be OS-specific, but imagine an ambitious site willing to write the code to target multiple OSes and systems.
Googling this led me to many red herrings with relatively little good information, so I decided to ask here
Generally speaking, the security model of browsers is supposed to keep javascript code completely contained within its sandbox. Anything about the local machine that isn't reflected in the properties of the window object and its children is inaccessible.
Plugins, on the other hand, have free reign. They're installed by the user, and can access anything the user can access. That's why they're able to access your webcam, upload files, do virus scans, etc. They're also able to expose APIs to javascript code, which pokes a hole in the javascript sandbox and gives javascript code some external access. That's how tools like Phonegap give javascript code in web apps access to phone hardware (gps, orientation, camera, etc.)
I'm about to develop a small system to display dynamic information in public spaces across an entire building (similar to Flight Information Displays on an Airport).
The system will have two main components:
a back-office for managing the
information displayed
a front-end
which acctually displays the
information.
The back-office component is covered: it's a simple crud application with a web interface, accessed through the intranet.
I have to decide which language/technology to use for the front-end. The purpose of this component is only to access the information in stored in the back-office and display it in a big LCD monitor. No input in expected, just display the information, paging once in a while as all the information won't fit in the screen at once.
I think of a Flash movie which some-how access the back-office data through the local intranet to get the information to display.
Can you think of a better option for the front-end? Why?
Other technologies that came across my mind are:
Silverlight
Flex
JavaFX
I've had pretty good success using Silverlight and C# to access and display back-end data, running it in out-of-browser mode to avoid the display of browser chrome. WPF might also work in your situation instead of Silverlight, but Silverlight seems to be the target for most of Microsoft's recent tooling efforts (via WCF RIA Services).
The advantages for me were the fact that my company largely already has a Microsoft-based infrastructure and we already owned the tools. Up-front costs can be an issue if you go the Redmond Way. Also Silverlight and WPF have fairly healthy learning curves, though there are tons of resources and tutorials available.