I have created an app with Expo and react-native-firebase. I integrated react-native-google-mobile-ads and have successfully displayed ads. Though I wonder if there's anyway to add an event on impressions by, let's say, banner ads. E.i. something gets triggered by a paid event. I was thinking of something that would encourage the impressions and discourage the use of adblocker, this might not be
the optimal implementation, but I am curious if there's anyway to make this work.
I know rewarded ads have similar events, but how would banner ads work in such a manner?
The closest I have found is this: https://support.google.com/admob/answer/11322405?hl=en. Though I am not sure if it would work with the current set-up, or if there's an easy integration with the packages named above.
I do really appreciate any help.
Related
Situation:
I have a sensitive website about domestic violence with an EXIT button that directly links to Google. So that anyone visiting that website can quickly jump to Google if the visitor feels unsafe or uncomfortable.
I would love to be able to clear any references to this website from bot the history list and the back button functionality. Basically, remove any proof of visiting that website. Keep in mind that not all people know how to browse anonymous and some people just cannot even get out of the house to browse the internet. Yes, this scenario is for seriously bad situations.
I've tried using location.replace instead of regular links to keep them from being saved into the history, but they just keep being saved in the history.
I've also tried to use browser.history.deleteUrl({url:"https://thewebsite"}), but this gives error on browser being undefined.
Is this even possible from a website? Or are there other options?
Thanks for thinking with me!
As you state in the question, you can use window.location.replace() to prevent your site from appearing in the window’s history (back button). Of course, this only works if your site had only one entry in the window’s history to begin with.
As you also state, there is a bigger problem: this does not prevent the site from appearing in the browser’s history. I believe you cannot solve this problem with scripts on your website: you need some external solution, like a browser extension.
(This does not really answer your question, but you could try using URLs and titles that disguise the nature of your site. I have heard of that being done with this sort of resource.)
In response to my idea of disguises, someone asked for examples and asked about discoverability. I was referring to the Aspire News App, featured on Dr Phil’s TV show. On that show, they made a big deal out of not showing what the app looked like, to avoid tipping off abusers. They also said the app is disguised as an ordinary app.
When I was researching this answer, I learned that disguises are indeed a terrible idea. I had no trouble finding information about the app online, and one review said the app is “pointless” because “with all of the media cpverage this app has gotten sbusers know exactly what it is and what to look for”.
I also learned that the app still had a fundamental security flaw 7 years after it was released. This shows that even supposedly reputable apps, dealing with sensitive matters, cannot be trusted. And perhaps it means that supposedly reputable websites looking to hide themselves from the browser’s history cannot be trusted either.
A newbie friend of mine thought of attempting to "secure" the website and protect the assets through something like this. I explained why it's not going to work but it got me thinking if there are actual legitimate reasons to disable right clicking in the browsers.
Off the top of my head:
Security is obviously not one as any determined "attacker" can simply disable/override the javascript, inject their own javascript/use Chrome's Developer Tools as they control the client. At best, it'll stop non-technical users.
Attempts at protecting assets such as images obviously won't work either as they could simply save it using their browser complete with the images, use View Source and grab the assets from there, simply do a screenshot, among many other things. It'll only really stop the really non-technical and lazy users.
Preventing accidents such as say, running a transaction again by right click -> back would simply point to a deeper issue with the site code so would be a band-aid solution at best. I suppose one could make an argument that this is one use until the underlying site code is improved.
For some more desktop-app-like pages, I've sometimes used right click for actions specific to the application. For example, a custom context menu or modified drag/drop action. This provides what mouse users expect in a convenient way. (Touch users still need an alternative, however!)
I'm not really that experienced in this area but I have the following problem:
I'm creating a Filemaker solution which is linked to Google Calendar. It works really well so far. Now what I'd like to do is to actually have a visible calendar within my solution. I can already link filemaker scripts to my Google Cals entries, so all I need now is a way to view the actual calendar and insert entries. There are many ways to accomplish this. The most elegant solution I've come across is Seedcode.
Since none of these solutions though are cheap (they cost 1000 bucks at least) and aren't even on par with the actual Google Calendar or Sunrise calendar - a portal to Google Cal. I thought that it would be much better to just include https://calendar.sunrise.am/ in a webview in filemaker. Thus my solution would have the same functionality as Seedcode, with a much more sophisticated UI.
My dilemma now is that I have to login to Sunrise within Filemaker's webview. When I attempt to login, a popup of the system's standard browser (Internet explorer) comes up. After logging in through the popup, the webview still remains on the same login page (loading for ever)...
Now to my question. Is it possible to inject the login submit through javascript or something similar? Or is there any other way to accomplish this? I don't think that it supports cookies; although I'm not really sure how FM's webview works.
I'm really experienced with C++/Python. But as you may have noticed, I'm quite a noob in regards to html etc.
There is a really simple and free Filemaker calendar example here:
http://forums.filemaker.com/posts/1bc6721dbc
It's easy to integrate into your current solution if in this order you:
1) Copy/paste the tables to your database,
2) Copy/paste the scripts
3) Copy/paste the calendar layout
4) Re-point the date relationship to your 'events' so that your events show on the calendar.
It's not the type of game that really need a server to operate. I'm using javascript and html5 right now, and I cant think of a way to prevent the game from being rip off.
Using obsfucator is useless, the game would still work offline.
Implementing a validation scheme is not invincible either. Someone smart can just crack the script and remove the validation part.
Make it attractive for users to play on your site.
For example:
Provide online Highscores.
Introduce a multiplayer option
Create friends list
Provide a server based achievement system
Develop other games and provide them on the same page so users want to come back
Create "level packs" and similar add on content and release them on your page
Overall, there are other possibilities to get users to play on your site besides technical restrictions, which - as you already found out - are difficult to deploy in an open source, browser driven environment. But, on the web, this has always been a feature, not a bug.
You're right in that a clientside-only can't be prevented from running offline. How about moving part of the game logic to the server?
You could continue to use html5 and javascript, but move your javascript to the server side using node.js For example http://www.yuiblog.com/blog/2010/09/29/video-glass-node/
If you combine obfuscation and validation, you'll go a long way. Can someone crack and use it offline? Possibly. Is it really going to be worth the effort? I mean, even an installed game can be cracked. This is especially true if you make the validation extra obfuscated by hand by spreading it out over several methods.
I would avoid moving more logic to the server than you have to, because it would obviously slow the app way down, but you might be able to get away with moving tiny crucial pieces that only happen rarely like between levels (chapters?).
At my company most inventory tracking is done via an ASP.NET web application. The application is poorly conceived, poorly designed, poorly implemented, and somewhat of a hassle for a user to work with. These are things that are my opinion though and management has its own thoughts on the matter.
Such luxuries as the browser's back button and bookmarking pages are already not an option because of heaps and heaps of ancient Ajax code and now one of my bosses has the idea that he would prefer for the URL bar and browser buttons not to appear at all.
At first I told him that it was impossible but after thinking about it I suppose it could work if you used Javascript to create a fullscreen pop-up and run the application in that.
I personally am against this idea though since I'm the one who would do the work my own subconscious motivations are suspect so I'd like to gather some opinions on running an application in such a manner.
In addition, has anyone had any experience with transferring a regular webapp to such a setup? I'd like to know how much work could be in store for me.
Next time, for the good of the world, keep these kinds of ideas to yourself. It sounds like your boss is not qualified to make such a call, so make the call for him.
If your boss believes the url bar and browser buttons are not suppose to be there, then convert it to a stand alone app. Don't try to cram it into a web platform if its not suppose to be one.
You know the issues, so fight for what you think is right. Don't implement anything you are not going to be proud of.
You may find Prism intresting
Full Screen, no bars, just WebApp
I'd be tempted to simply add a button that allows you to pop out the app, without removing the normal mode.
If necessary, sell it with some waffle about users getting confused or not being able to reopen it or something. Or even pretend its not possible to do it without it.
That goes some way towards user friendliness. Salve your conscience anyway