Jump to content

Welcome to nsane.forums

Welcome to nsane.forums, like most online communities you need to register to view parts of our community or to make contributions, but don't worry: this is a free and simple process that requires minimal information. Be a part of nsane.forums by signing in or creating an account.

  • Access special members only forums
  • Start new topics and reply to others
  • Subscribe to topics and forums to get automatic updates

 

Please note: Unfortunetely due to some server side issues, registration via Hotmail / Outlook email addresses do not work, members are requested to use some other email addresses like Gmail to register here.


Search the Community

Showing results for tags 'internet'.

The search index is currently processing. Current results may not be complete.


More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Found 3 results

  1. How fast is your internet speed?

    I wonder what is the plan on other country dsl they have... i got upgraded to 8mb
  2. Last Friday, someone in Google fat-thumbed a border gateway protocol (BGP) advertisement and sent Japanese Internet traffic into a black hole. The trouble began when The Chocolate Factory “leaked” a big route table to Verizon, the result of which was traffic from Japanese giants like NTT and KDDI was sent to Google on the expectation it would be treated as transit. Since Google doesn't provide transit services, as BGP Mon explains, that traffic either filled a link beyond its capacity, or hit an access control list, and disappeared. The outage in Japan only lasted a couple of hours, but was so severe that Japan Times reports the country's Internal Affairs and Communications ministries want carriers to report on what went wrong. BGP Mon dissects what went wrong here, reporting that more than 135,000 prefixes on the Google-Verizon path were announced when they shouldn't have been. Since it leaked what the monitors call “a full table” to Verizon, the fat-thumb error also provided a “peek into what Google's peering relationships look like and how their peers traffic engineer towards Google”. For example, BGP Mon explains how the mistake hit ISP Jastel (Jasmine Telecom) in Thailand: “If we take a closer look at the AS paths involved starting at the right side, we see the prefix was announced by 45629 (Jastel) as expected. Since Jastel peers with Google (15169) that’s the next AS we see. The next AS in the path is 701 (Verizon) and this is where it is getting interesting as Verizon has now started to provide transit for Jastel via Google. “Verizon (701) then announced that to several of it’s customers, some of them very large such as KPN (286) and Orange (5511). So by just looking at four example paths we can see it hit large networks in Europe, Latin America, the US, and India (9498 Airtel).” BGP is the Internet's protocol for distributing routing information between networks. A BGP advertisement shouts out to the rest of the internet to announce things like “if you give me traffic for Verizon, it will reach its destination”. Designed for a more trusting (and much smaller) Internet, BGP's most serious shortcoming is that it's up to network admins to check and filter information in route advertisements. As BGP Mon notes, BGP leaks are “a great risk to the Internet's stability”, and both sides of an advertisement should be filtering them before accepting them. Previous BGP incidents have sent YouTube traffic to Pakistan, blackholed Chinese traffic, made Belarus the default route for more traffic than it could handle, and redirected Level 3's traffic to Malaysia. There are various proposals to tweak BGP to stop this sort of thing happening, but as is so often the case, implementation is lagging far behind requirement. Article BGPMON - explanation of cause of outages in Japan and beyond
  3. All modern web browsers leak extension information to sites if the sites run scripts to pull the information. We talked about the findings of a research term that published its findings recently in a paper. Unless scripts are blocked, sites may run scripts that check the response time of the browser as it is different when checks are made for fake extensions and fake resources, and existing extensions and fake resources. Firefox's situation is special, as it supports the legacy add-on system and the new WebExtensions system. The researcher tested the browser's legacy add-on system only, but suggested that Firefox's new system would also be vulnerable. An anonymous reader pointed out that Firefox's WebExtensions system uses random IDs, and that this meant that the method to enumerate extensions would not work in that case (unlike in Chrome and other Chromium based browsers). While that is correct, Mozilla's implementation introduces a new issue that allows sites to identify users if WebExtensions expose content to sites as the random IDs are permanent. "... in particular, they [Mozilla] changed the initial scheme (moz-extension://[extID]/[path]) to moz-extension://[random-UUID]/[path]. Unfortunately, while this change makes indeed more difficult to enumerate user extensions, it introduces a far more dangerous problem. In fact, the random-UUID token can now be used to precisely fingerprint users if it is leaked by an extensions. A website can retrieve this UUID and use it to uniquely identify the user, as once it is generated the random ID never changes. We reported this design-related bug to Firefox developers as well." If a site manages to get hold of the ID, it may track the Firefox installation as that ID never changes. This is not just theoretical either; Earthling, one of the maintainers of the Ghacks Firefox user.js file, has created a proof of concept that highlights a leak in Firefox's native Screenshot tool. While this particular example requires that users click on the screenshot button in the Firefox interface to make the unique ID available to the site, other extensions may expose content without user interaction. Apple's Safari uses a random UUID system as well, and the researchers discovered that they could enumerate about 40% of all extensions as its implementation is flawed. If the WebExtension exposes content to sites because they have implementation flaws, sites may fingerprint users based on the unique ID that gets exposed in the process. Closing Words Mozilla needs to rework the implementation to protect users of the browser from this. Even if you don't use WebExtensions at all, you may be vulnerable to this as Firefox ships with several system add-ons that may expose the ID to sites. (Thanks Pants and Earthling) Article source
×