I'm giving a class of high school students a demo of unexpected things a webpage can tell about them from their mobile - even if they're not signed in or anything. So far I have picked a couple of things most people would know about, like:
Device OS
Specific handset (unless you're on iPhone, then it's just iPhone)
Language setting
And a couple of more obscure things:
Carrier (hitting a remote service and returning JSONP since js is IP naive)
Battery level / charge status (I didn't even know you could do this until today)
Can you think of anything else cool / creepy in a similar vein that I can dig out of UA / Navigator / etc? Most of them are running Chrome under Android or iOS (which is lucky, not every browser supports the battery thing). The main event is about mobile safety and phishing so I'd like to stick to mobile phones.
Quick edit: for clarity, I'm building out a site they will go to which will actually demo these features - so unfortunately they need to be implemented, at least in Chrome, vs planned / drafts.
You should mention geographic location. A competent javascript library e.g. MaxMind or Google Analytics can be used to pinpoint to geographical location of users.
From the phishing point of view, which I consider most important, there are several dangerous things:
Phishing
Without add-ons, browsers will not usually warn you if there's one letter different in the address you're visiting. Even though URL scheme forbids zero-width characters and other Unicode nastiness, you still can oversee l (lowercase L), 1 (one), I (upper case I). There are also many unicode characters that look like normal alphabet. Maybe there's some blacklist on unicode characters like greek letters. Check this site to play around. You can try to create some domain name like stackoverflow.com with greek ο.
JavaScript can alter URL after domain name. But I haven't seen hosting that would give users folder names in years. Still, it's creepy to see URL change without reload:
window.history.pushState("object or string", "Title", "/new-url");
Not sure if this applies, but last years HackADay.com revealed a hack where you can change <a> href after mouse button was pressed on link, effectively changing the target URL. But then again, you can also redirect browser using javascript...
Personal data
For this, the first thing I'd do is to check Window and Document on MDN. This is definitely gonna reveal some cool stuff that leaves battery power info just puny attempt to be scary:
Window:
Window.ondevicemotion - does what it suggests. assume you can also Window.addEventListener("devicemotion", ...)
Window.ondevicelight - this one is very creepy but Firefox only
Window.ondeviceorientation - much more widely supported event for device movement. Wanna approximate the path your user walks and draw it on canvas? Or make an application that screams "Put the fuking phone down.*" until they put it on the table?
Also, there's like million methods to get various screen properties. Some of those were exploited to guess OS version, as different OS's have different menu bars taking different screen portion.
Document:
document.referrer - Wanna track your users?
You can detect presence of ad-blocking addons by creating elements like:
<div id="advertisment"
class="ad advertisment ads banner"
style="pointer-events: none;position: absolute; opacity: 0;">NOTHING
</div>
Then fetch .getBoundingClientRect() and assert non-zero dimensions.
You can detect when document is being inspected by firebug. (or you could in past, when firebug actually added elements in DOM to highlight nodes). These elements are invisible in Firebug but fire DOM mutation events.
If user confirms, sound and video can be recorded.
I once created a script that was able to stream all DOM mutations on server allowing me to watch other user using web-site real-time. But I didn't finish it to production state unfortunately. But this is how I found about the firebug issue.
There are other tricks to check if debug tools are running. These are usually various hacks, try to google something.
Ever wondered if your users have CORS enabled localhost HTTP server running? I mean, isn't it worth a try?
WebWorkers allow you to spawn threads on client machine. You could use this for distributed processing or just to burn their battery. As it doesn't affect GUI thread directly, they won't notice until it's too late. Also this sounds like a great way to generate hask cracks and crack certificates.
You can alter copied text, possibly adding cross-site script hacks into it. Good trick is to offset your script with a shitload of spaces, so that it's not seen in typical text editor without text-wrap.
Using Desktop notification, you can pretend you're an antivirus, windows update...
What about any of these...
You can profile their interests base off search history.
Frequency they visit and from what locations.
Build a profile of what time in the day they visit.
Time spent on site
What pages they spend most amount of time on.
Profile based of hot area's on page clicks or where mouse curer is.
You can profile typical user behaviour.
The result of all of this is
- Pushing data personalized marketing i.e what your seeing, is targeted to
you, as an individual (google does this a lot with their ad's)
Related
I want to make the Right-Click don't work in my website or give a error that says: Protected Content! The reason I want to do this is because I don't want others to see my Source Code. I know that you can make the Right-Click to not work but I am not pretty sure about F12. If there is no way to make the F12 key to not work is there any way to hide the Source Code form others? I saw a similar website today. If you right click on this website you get this:
F12 works in this website but the Source Code is hidden anyway. How can I archive similar results? Thanks for your time :)
Answering the question overly honesty:
First you must avoid publishing the site on the Internet. Make it available only on your private machine(s) you have total control of. Make sure there are no USB ports exposed to users etc. Also, no internet access of any kind. They may just download some hacker tools this way. If you do not need text input, even better, keyboard can be used to type in some hacker tools as a source code and this way steal your precious sources.
Next make a custom build of a browser. You may want to use tools like Electron instead of generic browsers this way you will end with app that runs only your website and has no developers tools nor address bar nor anything other that may be used to gain access to your precious source.
Install Linux, create new user account with minimal privileges (no write access anywhere) and let it use X without any window manager. Only your electron app with your precious website and no menus that could be used to access some hacker tools like text editor that may reveal your precious source code. Also, configure the account to have complex random password so that users do not start another session in text mode and see your source code.
Remember that hackers may use means like timing attacks, side channels or other hacky means of stealing your code. To prevent that cover walls of the room you store your computer in with a metal grid to make a Faraday cage. Check all people entering and deny them bringing any electronic devices with them. Same for analog photo cameras or paper notebooks. Better safe than sorry: they may reconstruct your site source code based on how it looks like.
Or just accept the hard truth nobody cares about your website source code. There is plenty of places you may copy paste your code from and your website is not the most interesting one. And if you do that to prevent hackers, you have to write secure code (and test/audit it), not to hide it.
Short answer: Browsers, which render your website, are a client-side technology, and there is no way you can control who is going to see or not see your source code.
Long(er) answer:
Browsers download your website, together with it's source code the website onto users computer. Which means they can manipulate it however they see fit. There are some scripts that can ban right click or other types of interactions, but if you try to stop developers from inspecting code (and if they are ispecting, it's a good bet they are developers) they will find a way even if you block f12 or right click. You can always download website, use crawler, open in notepad, etc. etc.
You may want to investigate minifying and/or uglyfying HTML code, but it's no cryptography - again, if someone wants, they will find a way to undo that.
Also, I'm curious, why would you want to do that?
You can do this using window events but still there are ways to read your code.
For example fetching js without execution or disabling js in browser for a moment.
window.addEventListener('keydown', e => {
if (e.key === 'F12') // detect f12
e.preventDefault()
})
window.addEventListener('contextmenu', e => e.preventDefault())
I have a scenario in my application which clicks the support link and opens an email draft with the support email id. I need to verify the email id using Protractor.
I guess that is one of those cases, when you're much faster and better with manual testing.
But to give first an option for Automation:
Probably the scope of the application under test ends on what gets provided as HTML or evtl. JavaScript. After that it's basically Browser and OS functionality that opens the mail software. Therefore your tests should only cover what's in scope of your application under test.
So the suggestion to automate is to just check the element, containing the mail-link (evtl. mailto:), if the attribute is set correctly there. Something like this:
expect($('div.support-mail').getAttribute('outerHTML')).toMatch('support#mail.com');
Read in this SO-Question here more about alienating users without set-up mail software as well as further infos, how a mail-address can/shall get published.
Now, why it's better to do it manually:
Just imagine the complexity and variety you'd need to cover within your automation code:
Only for Computers it already means
3 main OS (Windows, Mac, Linux), times
5 Browsers (IE, Edge, Chrome, Firefox, Safari), times
countless mail software (Outlook, Mac, GMail, Yahoo, etc.)
further to add: Browser extensions and pop up blockers, which prevent mail from opening. OS, where no default mail is configured, etc.
If you additionally add Mobile Coverage (Devices, OS, screen size, etc.) it goes nuts.
You'll be in maximum able to cover a few environments, no matter with or without automation. But with automation it will take you many hours to get a decent running version, while a manual test will take you 30 Seconds per execution. So if you manually test about 20 environment setups this will still take you less than an hour. And you'll need to test it maybe twice or three times a year.
Also this functionality will probably never change again, so once verified it's working, it keeps working. If Code standard or browser changes significantly one must maybe retest once a specific configuration.
Last but not least this isn't business critical functionality. In worst case your users need to copy-paste the address from Browser into their mail.
All in all I'd consider this case not worth the effort for automation. Manual Testing suits better here.
Is there a way to prompt users to enable physical web (and therefore BlueTooth) with JavaScript in a similar way to APIs like getUserMedia()?
EDIT: I know this is relatively early stage tech and not widely supported, so the best option will probably be to help users turn this feature on at Settings > Privacy > Physical Web=on
Actually, JS can create push notifications. The problem is that these notifications can't be prompted in the way the OP seems to want. What is possible (but likely not helpful) would be:
Open web page
Use JS to scan for beacons
IF found, prompt the user to turn on Physical Web to find beacons easier in the future
I should also add that WebBluetooth V1 only lets you connect to a single device. V2 has a proposal (not yet finalized) that lets you scan. So everything here is still a bit early. However, these changes are on roadmaps so it's not total blue sky...
No, there isn't. Javascript just can access LocalStorage on your disk, but not raise any prompt to any device on your machine.
I am thinking of making a game, but it involves staying in fullscreen mode always. You can only leave full screen mode on entering a password. Pressing Esc or toggling the fullscreen key shouldn't exit full screen mode.
I can't divulge more details, but it involves leaving a person to interact with content of the page until another person who knows the password stops the interaction.
EDIT: I know it is not user friendly, but it is for a special purpose. It is there to leave kids to interact with, and be left alone with. If they escape out of the browser they would be able to tamper with other things on the computer which i dont want them too.
Since you don't need any more answers like "this is not user friendly" i would recommend you to have a look at some add-ons for firefox or chrome. You should have a look at some "Kiosk-Mode" add-ons.
Kiosk-mode is made for use cases where you have a pc in a public place and want to provide internet access. Maybe you can use one of those add-ons and configure it to get what you want.
If not, you should think about writing your own plugin for firefox or chrome in this add-on context you should have control over such things.
This is not plausible. All operating systems allow some sort of emergency application shut-down system. You will not be able to block these abilities.
You can't force the browser to stay in full-screen mode. Nor should you, it's just going to make your users angry.
If you don't mind angry users, you can try a Full-sreen popup . But really, try not to do that.
Fullscreen in a browser is a user setting. You can not possibly control this through html/javascript. The only way to acces and change a person's personal settings is through system calls in languages like C/C++ and C#. You will basically always need a program running on the client's computer to manage that kind of settings.
I'm trying to make a site as responsive as possible for phone users, and that means removing several bandwidth-hungry features. In particular, I'd like to load an external font if the user is on wifi but not on 3g/4g.
A pretty good proxy for this is 'phone or tablet', with tablets usually being the cutoff for 'good connection'. This kinda works, but there are 3g/4g tablets, and there are phones on wifi, so it's not perfect.
I don't think it's possible to get this any better, but perhaps stackoverflow's collective wisdom has discovered a way. Is this detectable?
Rather than focusing on mobile or not, just do a bandwidth test. The only way to really be sure is measure the time to download a file to their device.
Try the accepted answer here: How to detect internet speed in Javascript?
You can try the solution suggested in this answer, that is to use navigator.connection.type. However, this is definitely non-standard and it seems to be limited to Android devices only. Also, see the MDN entry, which mentions a metered property on the same navigator.connection object - this may also be useful.
For the best coverage: var connection = navigator.connection || navigator.mozConnection || navigator.webkitConnection;
The only way to do this I know of, which has it's own problem, is to do a reverse lookup on the IP address of the request at the time of the request (on the web server) and see if it's from a Wireless Carrier. The two problems with this are; that I don't know if mobile devices use a different network than say wired networks (Version Wireless vs Version Fios), and the other problem is employees of those companies who may actually be wired will appear wireless.
You could try doing a network probe for very common local addresses (only reachable over Wifi), such as 192.168.1.100 and friends. Here's how:
Create an img element with an onError handler.
Set the src property to the address you want to "ping"
If you get an error, then you know the address does not exist
No error means the address exists
I initially read about this technique in Ajax Security (great book).
JavaScript does not provide any hooks into network-level connection types. The best you can do is time the download of a known test file and decide based on that.
If that fails, just ask the user if they prefer the high/low bandwidth setting.