Today I noticed that in the Chrome web store dashboard, under my extension's settings there is a check-box labeled "Ads Behavior", and whose description is "This extension injects ads into some third-party websites.".
My questions are:
Can an ad-supported extension inject advertisements in a page visited by the user?
If so, what is an acceptable policy?
Can the extension replace existing advertisements (even though that seems to me kind of unethical/stealing) or must it only create new ones?
Is it possible to use any ads network or must it be adsense?
Thanks
Is it possible to use any ads network or must it be adsense?
Actually it can't be AdSense. It's specifically mentionned in their program policies:
Currently, we don't permit Google ads or AdSense for search boxes to be distributed through software applications, including but not limited to, toolbars, browser extensions and desktop applications.
I wonder if any ad provider allows such a thing.
Can an ad-supported extension inject advertisements in a page visited by the user?
The fact the checkbox exists suggests it's acceptable as long as you declare it, so users are aware of it.
If so, what is an acceptable policy?
I would argue anything that makes it clear to users what you're doing and follows the terms of the ad network.
Can the extension replace existing advertisements (even though that seems to me kind of unethical/stealing) or must it only create new ones?
Agree it's unethical, most content and apps out there cost money and it deprives publishers. But as with a lot of extensions, it's seen by the browser as the user's choice. That's basically how the web works - users have control over the client. The most popular extensions for browsers are ad blockers, so I doubt the Chrome team would ban an extension that swapped ads. Please do consider the website owners though. Adding ads is at least better than replacing them.
Is it possible to use any ads network or must it be adsense?
Any, I'm fairly sure. Google wants Chrome to be seen as generally independent from its services. You'll even see Google's various competitors promoted in the Chrome Web Store at times for that reason.
*However*, there's a big caveat here. It's very possible this kind of ad injection is forbidden by the ad network in question. It's certainly the case with many affiliate links, that you can't just inject your own, or swap in your own, link. The argument is the user was already going to click on it anyway. So if you're injecting ads, the biggest constraint is going to be your ad provider, not Chrome.
I too had concerns about this, specifically a Chrome app extension called Bookmark Sentry as while it does do a great job of managing your bookmarks, it also injects itself and intercepts advertisements replacing it with it's own affiliate network.
Specifically in viewing the source code it appeared to contain a 'whitelist' and 'blacklist' of sites to intercept advertising while navigating. The user is given the choice to opt-out of advertising in settings but it is poorly explained as 'marketing' with no explanation as to what it is doing.
I raised concerns to Google Chrome through flagging of abuse. Through a contact I was informed however that:
"Ad injections are not in violation of the Chrome Web Store program policies. The policy requires that ads must be presented in the context of the extension or, when present within another page, ads must be outside the page's normal flow and clearly state which extension they are bundled with. We believe that ads are a legitimate way to monetize, but that they should be a known cost to the extension user."
So in this particular case at least, Google viewed it as acceptable, curiously both Kaspersky Labs and Microsoft Security Essentials reported this immediately to me as malware and removed the Extension.
Related
My Magento 1.9 webshop is marked as unsafe (phishing which is not true) in Microsoft Edge, if switch to IE and run Smart Screen security check it says all safe.
And strangely only on one of my computers and therefore didn't bother much but also a customer complained about it today.
Anyone experienced this before and have a solution? Is there a way to check why a site is marked as unsafe by smartscreen?
Based on my searching results, Below information may helpful to you.
Q. If I am a website owner, how do I correct a warning on my legitimate site?
A. You can immediately submit a request for a correction. Windows Defender SmartScreen has a built-in, web-based feedback system in place to help customers and website owners report any potential false warnings as quickly as possible. In Windows Internet Explorer, from a red warning, click More information then Report that this site contains no threats. This will take you to a feedback page where you can indicate you are a site owner or representative. Follow the instructions and provide the information on this site to submit a site for review...
Reference:
Resolving “This website has been reported as unsafe” (Windows Defender SmartScreen)
Q.
If I am a website owner, what can I do to help minimize the chance of my website being flagged by Windows Defender SmartScreen?
A.
There are several things you can do that can help minimize the chance of your site being flagged as suspicious. Think of these as best practices or optimal website design ethics.
If you ask users for personal information, use HTTPS with a valid, unexpired server certificate issued by a trusted certification authority.
Make sure that your webpage doesn't expose any cross-site scripting (XSS) vulnerabilities. Protect your site by using anti-cross-site scripting functions such as those provided by the Microsoft Anti-Cross Site Scripting library.
Use the fully-qualified domain name rather than an IP-literal address. (This means a URL should look like "microsoft.com" and not "207.46.19.30.")
Don't encode or tunnel your URLs unnecessarily. If you don't know what this means, you probably aren't doing it.
If you post external or third-party hosted content, make sure that the content is secure and from a known and trusted source.
Reference:
Windows Defender SmartScreen Frequently Asked Questions
In MS Edge browser there's an option to "report file as safe". After clicking it - select the "I'm a website owner" option and fill the false-positive form.
Although I know a lot of email clients will pre-fetch or otherwise cache images. I am unaware of any that pre-fetch regular links like some link
Is this a practice done by some emails? If it is, is there a sort of no-follow type of rel attribute that can be added to the link to help prevent this?
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails arriving in your inbox and it sends all found URLs to Bing, to be indexed by Bing crawler.
This effectively makes all one-time use links like login/pass-reset/etc useless.
(Users of my service were complaining that one-time login links don't work for some of them and it appeared that BingPreview/1.0b is hitting the URL before the user even opens the inbox)
Drupal seems to be experiencing the same problem: https://www.drupal.org/node/2828034
Although I know a lot of email clients will pre-fetch or otherwise cache images.
That is not even a given already.
Many email clients – be they web-based, or standalone applications – have privacy controls that prevent images from being automatically loaded, to prevent tracking of who read a (specific) email.
On the other hand, there’s clients like f.e. gmail’s web interface, that tries to establish the standard of downloading all referenced external images, presumably to mitigate/invalidate such attempts at user tracking – if a large majority of gmail users have those images downloaded automatically, whether they actually opened the email or not, the data that can be gained for analytical purposes becomes watered down.
I am unaware of any that pre-fetch regular links like some link
Let’s stay on gmail for example purposes, but others will behave similarly: Since Google is always interested in “what’s out there on the web”, it is highly likely that their crawlers will follow that link to see what it contains/leads to – for their own indexing purposes.
If it is, is there a sort of no-follow type of rel attribute that can be added to the link to help prevent this?
rel=no-follow concerns ranking rather than crawling, and a no-index (either in robots.txt or via meta element/rel attribute) also won’t keep nosy bots from at least requesting the URL.
Plus, other clients involved – such as a firewall/anti-virus/anti-madware – might also request it for analytical purposes without any user actively triggering it.
If you want to be (relatively) sure that any action is triggered only by a (specific) human user, then use URLs in emails or other kind of messages over the internet only to lead them to a website where they confirm an action to be taken via a form, using method=POST; whether some kind of authentication or CSRF protection might also be needed, might go a little beyond the context of this question.
All Common email clients do not have crawlers to search or pre-build <a> tag related documents if that is what you're asking, as trying to pre-build and cache a web location could be an immense task if the page is dynamic or of large enough size.
Images are stored locally to reduce load time of the email which is a convenience factor and network load reduction, but when you open an email hyperlink it will load it in your web browser rather than email client.
I just ran a test using analytics to report any server traffic, and an email containing just
linktomysite
did not throw any resulting crawls to the site from outlook07, outlook10, thunderbird, or apple mail(yosemite). You could try using a wireshark scan to check for network traffic from the client to specific outgoing IP's if you're really interested
You won't find any native email clients that do that, but you could come across some "web accelerators" that, when using a web-based email, could try to pre-fetch links. I've never seen anything to prevent it.
Links (GETs) aren't supposed to "do" anything, only a POST is. For example, your "unsubscribe me" link in your email should not directly unsubscribe th subscriber. It should "GET" a page the subscriber can then post from.
W3 does a good job of how you should expect a GET to work (caching, etc.)
http://www.w3schools.com/tags/ref_httpmethods.asp
How can I sign my extension so users make sure my extension is safe and it won't steal their information? My extensions needs to access page contents, some users have no good sense of permitting an extension to do so.
Can I sign my extension using a verified sign provider, for example VeriSign?
When you publish an extension to the Chrome Web Store, the only "proof" that users can have of your extension is given by the rating system and the comments of other users. An hypothetical user that wants to install your extension, looks at the ratings and the comments, so make sure that your extensions has a good feedback from its users.
By the way, Google doesn't always look at the internal code of your extension manually, most of the times it only performs some heuristic checks on the code. So the problem is that developers could easily include some malicious code that may not be recognized and that could harm user's privacy in their extension without any problem.
Therefore, due to the Chrome Web Store policy, "validating" your extension is not possible at all. Plus, using SSL servicies (like the one you mentioned) will not make any sense since that your extension's scripts are stored locally.
What you can do is:
Encourage users in rating your extension and leave good feedbacks if they like it.
Redirect users to help links in case of trouble (links like "having trouble?" in your popup and so on).
Write a good worded description, and obviously add some images (or videos, better) to clearly show why an user may find your extension useful.
Always be nice (implied, ahah).
Your extension cannot be signed by an external provider, but it is signed by Chrome Web Store itself.
Every extension has an associated private key used for signing. It ensures consistent extension ID and updates. You can generate one yourself by packaging the extension as CRX (that produces a .pem file) and provide it when publishing on the CWS, or CWS generates it internally when you publish it (and then there's no way to extract it).
From on then, only code signed by this key (by the Web Store engine) will be recognized by Chrome as an update. Furthermore, at least on Windows only CWS-signed packages can be installed.
This security is as strong as the developer's Google account: if it is compromised, CWS will accept an update to your extension, which will be signed with the same key.
Although, as Marco correctly pointed out in his answer, the act of signing something would be just snake oil with respect to security. This signature verifies the identity of the publisher, but nothing more.
There's one more aspect - verified sites. If your extension interacts with a site you control, you can certify this by associating your extension with the site. It will be visible in the Web Store.
CWS-signed packages have an additional warranty of saying "so far, we did not catch this extension breaking any rules". Google can pull the extension off Web Store, and in severe cases blacklist and remove it from all Chrome installs. So that's an additional assurance for the user.
Google runs automated heuristic checks every time you submit your extension, which can trigger manual review. But that's invisible to the user.
That said, make sure to only ask absolute minimum permissions you need. For instance, look into the activeTab permission. It gives full host permissions for a tab when the extension is invoked by the user, but does not result in any permission warning. This was specifically added to address concerns about blanket extension permissions.
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.
I know that GeoLocating requires elevated trust from the user in order to get the location.
Is that part of the standard?
Is the trust level elevation part of the standard?
Which features requires user permission?
do i need to give permission for each feature seperately? or is it "trust-mode" on/off ? can the website keep the permission? or is it just per session?
I'm just starting to get ino HTML 5 myself, so I am going to try to answer as best I can. From what I understand it is not necessarily an "elevated trust" (sounds alot like Microsoft UAC term). Its more of a "granting of permission" for a site to access the user's location.
W3C - http://dev.w3.org/geo/api/spec-source.html#security
The API defined in this specification is used to retrieve the geographic location of a hosting device. In almost all cases, this information also discloses the location of the user of the device, thereby potentially compromising the user's privacy. A conforming implementation of this specification must provide a mechanism that protects the user's privacy and this mechanism should ensure that no location information is made available through this API without the user's express permission.
The way each browser implements this is up to the browser maker (ie google, microsoft, mozilla). For instance chrome will ask for permission for a domain and save that domain in a list of sites that can access the geo location feature. This works in the same way a pop up blocker has a list websites that are ok to "allow pop ups from".
So, I guess its hard to answer your question becuase it depends on the browswer and how those features are implemented.
Is that part of the standard? Is the trust level elevation part of the standard?
Kind of, yea. The standard says to implement some kind of a mechanism.
Which features requires user permission?
Sorry can't say for certain regarding this becuase I am not familiar enough will all the features of the standard. But I am pretty sure that access hardward like camera will be included in this list.
Do i need to give permission for each feature seperately? or is it "trust-mode" on/off?
I would think so, but this again will depend on the browswer makers "implementation" of the standards.
Can the website keep the permission? or is it just per session?
This would also depend on the browser, I can tell you that Chrome keeps a list once permission is granted (at least for geo location). You can then remove the permission later. I am not sure if they it is the same for other features with crhome.
Hope it helps.