Giter Site home page Giter Site logo

requestpolicycontinued / requestpolicy Goto Github PK

View Code? Open in Web Editor NEW
253.0 253.0 35.0 6.68 MB

a web browser extension that gives you control over cross-site requests. Available for XUL/XPCOM-based browsers.

Home Page: https://github.com/RequestPolicyContinued/requestpolicy/wiki

License: Other

Makefile 1.46% Shell 0.50% JavaScript 13.12% HTML 4.58% CSS 1.39% PHP 0.25% Python 17.93% TypeScript 60.00% CoffeeScript 0.70% Dockerfile 0.08%

requestpolicy's People

Contributors

aleksandrs-ledovskis avatar archaeopteryx avatar beriain avatar chrisbura avatar codeman38 avatar e-jim avatar genodeftest avatar jrrdev avatar jsamuel avatar ma2moto avatar myrdd avatar nodiscc avatar qk4 avatar roadrunner2 avatar strel avatar wenketel avatar wilkowy avatar yfdyh000 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

requestpolicy's Issues

Allow easier access to debugging logs for bug reporting

Issue by jsamuel
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#5


imported trac ticket
created: 2009-06-21 16:31:08
reporter: justin

The only existing way for a user to copy a debugging log snippet (details of blocked/allowed requests) is through a process intended for developers that involves changing values through about:config. At a minimum it should be possible to enable console logging through preferences > advanced. Even better would be a way for users to access this debugging info without having to start firefox from a console.

[CLOSED] switching between strictness levels confuses menu

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#42


imported trac ticket
created: 2009-10-03 19:02:59
reporter: justin

If one switches between different strictness levels (e.g. "base domain" -> "full domain") the menu for currently opened sites will be wonky. It is possible that items show up that shouldn't and submenus for listed items don't exist. This caused version 0.5.9 submitted to AMO to be rejected:

Hi Justin,
please excuse that I have to refuse this version, it seems that it gets easily confuse on domain rules. I started testing with importing some of the default rules, removed them later, changed to full domain style and allowed youtube.com requests to ytimg.com. I guess your extension can't distinguish if it is a domain or host rule and switching the rule style confuses it. I switched backed to basic domain style and had ytimg.com listed under allowed requests, removed this, but the item is still there, no without the submenu (and other hosts of ytimg.com like i.ytimg.com still show up under the forbidden one).

There are two possible approaches I see for when the user changes strictness levels:

  1. Go through and fix up the _rejectedRequests and _allowedRequests objects based on the new strictness level, resulting in the menu working normally after the change.
  2. Just clear out the _rejectedRequests and _allowedRequests objects, resulting in the menu not having anything in it for already-open sites.

I should try to do the the first one, and if there are unexpected difficulties then just do the second. This is just not a common enough use case to worry about a little odd behavior given the number of more important outstanding features and bugs.

Perform multiple menu actions before reload of page

Issue by jsamuel
Thursday Dec 22, 2011 at 18:44 GMT
Originally opened as RequestPolicy/requestpolicy#2


imported trac ticket
created: 2009-06-09 08:05:50
reporter: justin

Some people would like to be able to perform multiple menu actions before the automatic reload of the current page. One good example of this being useful is with mobile devices that have low and costly bandwidth and thus slow reloads that waste data transfer.

[CLOSED] SeaMonkey: context menu "open link in new tab" fails

Issue by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#24


imported trac ticket
created: 2009-07-25 13:38:58
reporter: justin

On !SeaMonkey 2.0b2pre, using "open link in new tab" fails when trying to open a cross-site link. What you get is a blank tab and the following message which looks like the browser reacting to !ShouldLoad returning false for the url it's trying to display in the new tab:

{{{
Error: uncaught exception: [Exception... "Component returned
failure code: 0x805e000a [nsIWebNavigation.loadURI]" nsresult:
"0x805e000a ()" location: "JS frame :: chrome://global/content/bindings/browser.xml
:: loadURIWithFlags :: line 186" data: no]
}}}

The fundamental problem is that our registerLinkClicked() function is not getting called. There is some chance this is the result of the crappy workaround for !TabMixPlus in our _wrapAddTab() function in overlay.js.

Add a request blacklist with priority over the whitelist

Issue by jsamuel
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#6


imported trac ticket
created: 2009-06-21 16:51:42
reporter: justin

Add a blacklist of request destinations that aren't allowed even if the whitelist policy says they should be. This would apply even when "temporarily allow all requests" is enabled (maybe that would be the default behavior but it could be changed through a config option to not apply in that case).

The blacklist would be able to include IP address ranges and requests to those IP addresses would be blocked even if the host in the requested URI was a domain name rather than an IP address.

The blacklist would definitely be for blacklisting destinations, possibly also for blacklisting origins-to-destinations (though one might argue that if users need to allow destinations from only some origins, they shouldn't whitelist the destination but instead only those origins-to-destinations they intended to allow). What about origins? I seem to really need to stretch to come up with a situation where that would be useful.

The blacklist would probably be accessible by default only from the preferences window but later on there could be an option to add "blacklist this [whatever]" items in the menu.

(Thanks to RSnake for the suggestion of a blacklist.)

[CLOSED] infrequently paths showing as allowed destination hosts in menu

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#39


imported trac ticket
created: 2009-09-17 16:49:27
reporter: justin

Sometimes a path will show up as an allowed destination hostname in the menu. I finally found a repeatable (for the moment) example of this happening and it appears to be with a 303 Object Moved redirect to a location that is just a path (no protocol + host).

Example with some specifics removed (so you don't know what coupon my wife wanted me to print):

http://coupons2.smartsource.com/smartsource/index.jsp?Link=XXXXXXX

elicited the following Location header in the response:

Location: /YYYYYYY/dcs.gif?dcsredirect=126&dcstlh=0&...

which appears to match what I see in the !RequestPolicy menu.

However, it seems like there must be more to it as one would think this would be fairly common and so the bug would have been visible more frequently. I'll need to come up with a repeatable test case to be sure that this is the issue.

[CLOSED] requestpolicy 0.5.8 breaks opening new tab in latest minefield trunk builds

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#38


imported trac ticket
created: 2009-09-16 12:54:51
reporter: aja

0.5.8 breaks opening of new tabs (via context menu, or otherwise) with latest trunk nightly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090915 Minefield/3.7a1pre ID:20090915053258

I get the following in Console2:
Error: '[JavaScript Error: "uri is null" {file: "file:///C:/Documents%20and%20Settings/Aja/Application%20Data/Mozilla/Firefox/Profiles/y5aydfee.central/extensions/[email protected]/modules/DomainUtil.jsm" line: 186}]' when calling method: [nsIRequestPolicy::registerLinkClicked] = NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS Source file: chrome://requestpolicy/content/overlay.js Line: 844

which refers to this line:
this._rpService.registerLinkClicked(referrerUri.spec, tabUri);

This was reported in firefox builds forum here:
viewtopic.php?p=7522705#p7522705

NewsFox: redirected feeds blocked and not saved

Issue by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#18


imported trac ticket
created: 2009-06-21 17:59:42
reporter: justin

Cross-site redirected feeds are not only blocked but may not even be retained by !NewsFox if it cannot retrieve them. Additionally, some content (e.g. images) of feeds is blocked because the requests have the origin of "about:blank".

[CLOSED] private browsing mode not supported

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#34


imported trac ticket
created: 2009-09-15 08:33:19
reporter: justin

Private browsing mode doesn't currently get special treatment.

There are two major aspects to consider: 1) the whitelist, and 2) the allowed/blocked request information maintained internally so that RequestPolicy knows what to show in the menu.

I think the easiest thing to do that could be considered expected behavior would be to have anything added to the whitelist during private browsing be temporary and have leaving private browsing mode remove all temporarily whitelisted items.

The internally maintained request data is harder to deal with. One option would be to make a copy of internal data when entering private browsing mode and restore that copy when leaving.

redirects from links opened in new tabs can show in menu of original page

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#36


imported trac ticket
created: 2009-09-15 08:57:55
reporter: justin

Aerik Knapp-Loomis writes:

Currently there's a bug where when you open a new tab and contains a redirect, the tab that you clicked over from will have somehow interacted with RP as if you allowed a request from the second tab.

For example, every time I'm on google reader and I ctrl+click on a link to a new tab that's located at feedproxy.google.com, which is always a redirect, the google reader tab will show that I've allowed a request from feedproxy.google.com.

This issue has been known and reported a few times before and it's time to make a ticket for it. However, I'm not sure how to fix it. There are fundamental issues with lacking information that Firefox makes available to us when we block or allow requests. It may be the case that solving this involves using a lot more DOM inspection for generating the menu, which is something we'd like to avoid for simplicity and speed reasons.

I need to spend some time on this, though, to see if there's an easier fix I'm not thinking of that won't involve complicating !RequestPolicy a lot just to deal with this issue.

Add an "ignore blocked requests to" option

Issue by jsamuel
Thursday Dec 22, 2011 at 18:44 GMT
Originally opened as RequestPolicy/requestpolicy#1


imported trac ticket
created: 2009-06-09 07:48:26
reporter: Christoph Langguth

Add an "ignore blocked requests to" option to ignore certain blocked destination domains and therefore avoid showing a blocked content notification when only these destinations are blocked.

[CLOSED] Link click is blocked if the link target contains IDN

Issue by jsamuel
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#48


imported trac ticket
created: 2009-10-23 20:57:19
reporter: emk

For example, click http://็ทๅ‹™็œ.jp/.
RequestPolicy will block the request to xn--lhr645fjve.jp.
I've found the following methods in nsIRequestPolicy broke the non-ascii chars.
11 void registerHistoryRequest(in ACString destinationUri);
12 void registerFormSubmitted(in ACString originUri, in ACString destinationUri);
13 void registerLinkClicked(in ACString originUri, in ACString destinationUri);
The parameter type should be AString rather than ACString. ACString will cripple the non-ascii chars from JavaScript caller.
In general, XPCOM components written in JavaScript should use AString because JavaScript strings are encoded as UTF-16.

toolbar button shouldn't have separate drop-down arrow

Issue by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#28


imported trac ticket
created: 2009-08-06 13:49:09
reporter: justin

The toolbar button uses a button type that has both the icon button and a separate, smaller button (an arrow) that indicates a drop-down menu. However, clicking on the main button or the drop-down arrow part of the button gives the same menu. We should save space and just use the normal button as long as the two parts of the button do the same thing.

Thanks to Fakir for the suggestion.

[CLOSED] current session history info visible from menu at chrome:// url

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#35


imported trac ticket
created: 2009-09-15 08:48:04
reporter: justin

!RequestPolicy has to keep data around about blocked and allowed requests in order to display the menu. However, it shouldn't be easy for someone sitting down at an existing browser session to view internal data structures. That is, we can't hide the data from browser data inspection tools, extension development utilities, process debugging tools, memory dumping, etc., but we should at least keep less savvy users from sitting down at an open firefox session and viewing information about browsing history that may not be otherwise available due to history saving being disabled, etc.

Aerik Knapp-Loomis has discovered that using the url chrome://browser/content/browser.xul and then clicking on the !RequestPolicy menu shows a list of visited domain names during the current session.

I don't consider this to be a major issue as plenty of other information from firefox is available to someone sitting at someone else's logged in system. This particular case should be fixed, though.

[CLOSED] inform user in menu that chrome:// origins will not be blocked

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#43


imported trac ticket
created: 2009-10-05 08:41:24
reporter: justin

This is an extended and better fix for #35. We should display a message in the menu when the user is at a chrome:// url that tells them they cannot block these requests. It should also take care of not displaying any other meaningless data in the menu in the case of an origin whose requests the user aren't allowed to control.

This is also needed because the change in r275 may actually have a side effect of not clearing items from the menu fully when a page is reloaded, for example.

[CLOSED] request log being initially empty is confusing

Issue by jsamuel
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#46


imported trac ticket
created: 2009-10-21 21:21:30
reporter: justin

Multiple users have thought that there was something wrong with the Request Log because it is empty when they open it even though they clearly have had cross-site requests being blocked.

My reason for having it not be populated until it is opened is that otherwise it could be harmful to someone's privacy if someone else sat down at their browser session and could see the user's history by looking at the request log.

Here are some options for how to improve this:

  1. At a minimum, display a message in the empty request log saying that no requests have been made since the log has been open.
  2. Add a preference to allow the user to have the log always keep a certain number of past items, even when closed.
  3. Make some small number of past items being kept be the default.

There also needs to be a "clear" button added if just closing the request log doesn't clear it anymore.

[CLOSED] toolbar button does not work when status bar is disabled

Issue by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#25


imported trac ticket
created: 2009-07-26 20:24:43
reporter: justin

If the status bar is not enabled (that is, if one goes to the Firefox "View" menu and disables the status bar), the !RequestPolicy toolbar button does not work. The error that results from clicking on the toolbar button is:

{{{
Error: this._menu.openPopup is not a function
Source file: chrome://requestpolicy/content/overlay.js
Line: 1295
}}}

don't change color of "RequestPolicy" label in context menu

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#31


imported trac ticket
created: 2009-08-12 09:17:05
reporter: justin

In the context menu, the label that says "RequestPolicy" changes color to match the flag icon next to it. Adam mentioned that this can be distracting and so not good for overall usability. I tend to agree. The color of the text in the label should stay black.

[CLOSED] allow removing status bar/addon bar icon

Issue by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#27


imported trac ticket
created: 2009-08-06 11:28:11
reporter: justin

Some users would like to use only the toolbar button and not have the status bar icon visible at all. This will require being careful with the possibility that users may not have either the status bar icon or the toolbar visible. In that case, they would still have the context menu, though.

We could try to warn the user if they disable the status bar icon when they don't have the toolbar button in use, but that's not perfect because they could remove the toolbar button later. Probably best is to just warn the user when they disable the status bar icon.

Somewhat related to this is #25.

make initial setup window whitelisting less confusing

Issue by jsamuel
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#15


imported trac ticket
created: 2009-06-21 17:46:31
reporter: justin

The initial setup window can be confusing by prompting users to choose regions that have corresponding pre-defined origin-to-destination whitelist items. It needs to be clearer to understand the impact that selecting regions has (sometimes it doesn't appear to change the box showing the items to be whitelisted), as well as which ones a user should select. An entirely new approach is not a bad idea.

allow wildcards/regex/CIDR notation for whitelist

Issue by jsamuel
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#8


imported trac ticket
created: 2009-06-21 17:11:28
reporter: justin

There is a need to make available wildcard whitelisting, especially for users who have enabled stricter classification policies (e.g. full domain).

This will probably include both the ability to use just a * for a wildcard or use regex if preferred. Care must be taken to avoid users attempting to whitelist items such as 12.34.56.* and losing security as a result of whitelisting more than ip addresses. Allowing/requiring CIDR notation for this would help (at least, it would help the more advanced users -- the average user should at least be prevented from shooting themselves in the foot, though).

[CLOSED] More Prefetch Options

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#33


imported trac ticket
created: 2009-08-28 11:20:00
reporter: TPS

I would like the option to enable/disable each of the prefetch behaviors of RP. Default it however it is now, but I would like the option to keep each of the prefetch options enabled, or conversely, to keep forcing them (each) disabled upon startup & shutdown. If prefecthing can be dynamically activated/disactivated during browsing, maybe also per-load or timer-based options to force them to the above options.

provide a way to allow individual blocked requests

Issue by jsamuel
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#7


imported trac ticket
created: 2009-06-21 16:58:49
reporter: justin

There should be a way to allow individual blocked requests rather than having to allow an entire domain.

Possibly this could go in an "Advanced" submenu off of the main menu (maybe put it where "Request Log" is and stick "Request Log" under "Advanced", as well). Another option would be to add a new submenu to each blocked/allowed destination and under there list the specific blocked/allowed requests. This starts to get complicated on the implementation side due to the way RequestPolicy tracks blocked and allowed requests for generating the menu: that is, not analyzing the DOM (well, only a little) and instead keeping track of requests that the browser tries to make and associating them with the url of the current page. The risk of misleading info increases a lot if RequestPolicy is stating what the individual items on the page are without looking at the DOM. So, RequestPolicy would need to look through the DOM very thoroughly.

(Thanks to RSnake for the suggestion.)

allow wildcard subdomain whitelisting from menu when using stricter classification policies

Issue by jsamuel
Thursday Dec 22, 2011 at 18:45 GMT
Originally opened as RequestPolicy/requestpolicy#9


imported trac ticket
created: 2009-06-21 17:16:17
reporter: justin

When using stricter classification policies, there are times when users want to whitelist all subdomains of the current domain. After #8 has been completed, displaying menu items for wildcard subdomain whitelisting should either be enabled by default or should be an optional preference when using stricter classification policies.

[CLOSED] Creation of a blacklist

Issue by jsamuel
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#45


imported trac ticket
created: 2009-10-18 05:24:15
reporter: muncho

There are many sites that refer to a bunch of other sites that host avatar images, videos, files, etc. I have also seen a lot of sites that uses CSS files from different domains.
It would be more convenient for the user to just blacklist some sites (like "GoogleSyndication.com") and then use the "Allow reguests from www.site.com" and "Temporarily allow requests from www.site.com" features instead of allowing every other site EXCEPT the sites he/she does not want to.

[CLOSED] URIs with single-word hostnames show entire URIs in menu when using strictness of "base domain"

Issue by jsamuel
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#44


imported trac ticket
created: 2009-10-05 09:07:15
reporter: fung0 and Herrminator

If one is using "base domain" strictness, going to a location with a single-word hostname (e.g. "localhost") results in not recognizing a hostname at all.

For example:
http://localhost/phpmyadmin/

results in the following blocked destinations in the menu:

http://localhost/phpmyadmin/favicon.ico
http://localhost/phpmyadmin/pring.css
...

This bug is the result of the refactoring done to modules/DomainUtil.jsm in r274 where I removed the "fall through" of trying to grab a different identifier from the URI if the default level's logic fails.

Original report (same issue noticed by different users):
http://forums.mozillazine.org/viewtopic.php?p=7648765#p7648765

[CLOSED] Shorter whitelist entry should also apply for longer entries

Issue by jsamuel
Thursday Dec 22, 2011 at 18:48 GMT
Originally opened as RequestPolicy/requestpolicy#50


imported trac ticket
created: 2009-10-26 08:22:54
reporter: cd-man

I would like to be able to allow either full sites (ie. google.com) or just a subdomain of it (www.google.com). Currently if I set "Strictness" to "Full domain" in the preferences, it doesn't whitelist www.google.com, even though I have google.com in my whitelist.

IMHO a modus-operandi more similar to NoScript would be more useful. In concrete terms:

  • have the option to show both subdomains and domains in the menu, or only domains
  • when you whitelist a domain, it should be considered as whitelisting all the subdomains

This is useful, because on some sites I trust the whole site (ie. *.google.com), while on other sites I would like to trust only the particular subdomain (blogs hosted on services like blogger or wordpress come to mind - ie. I would like to trust qwert.blogspot.com but not aoeui.blogspot.com :-)).

destination domains can sometimes show as both allowed and blocked in the menu

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#37


imported trac ticket
created: 2009-09-16 07:04:13
reporter: justin

There is a bug that is allowing, on rare occasions, the same destination domain to show in both the "allowed" and "blocked" sections of the menu.

I've noticed this a few times and it has also been reported by two users here:

http://forums.mozillazine.org/viewtopic.php?p=7204365&sid=0281311390631917f73582128be39846#p7204365

I still have not found a repeatable case of it.

Going forward, I think what I'll need to do is add in some code to check for this particular situation and log the relevant info when it happens.

[CLOSED] remove recaptcha.net from suggested initial whitelist, owned by google now

Issue by jsamuel
Thursday Dec 22, 2011 at 18:47 GMT
Originally opened as RequestPolicy/requestpolicy#40


imported trac ticket
created: 2009-09-18 06:59:07
reporter: justin

The initial whitelist that users are given the option to import when they use !RequestPolicy for the first time includes only one destination that is allowed from any origin: recaptcha.net. However, Google just bought reCAPTCHA:

http://www.techcrunch.com/2009/09/16/google-acquires-recaptcha-to-power-scanning-for-google-books-and-google-news/

So, we need to remove it from the suggested initial whitelist. (In case the reader of this wants an explanation of why this changes things: allowing any site to make requests to a Google property without the user's knowledge is exactly the opposite of what !RequestPolicy should do.)

It's a shame, too, as there are a handful of sites whose registration process is complicated by having reCAPTCHA blocked until after the user already has done some work.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.