Slashdot Mirror

I have a domainname. Why would I be forced to use https://toaster.example.com/ when I browse to my Linux toaster, when just typing 'toaster'?
It is in no way connected to the internet.

Or try the domain hackme.houghi.org and see how that is connected. Excluding local IP addresses should be standard.

Example.com and several others are reserved domains (RFC6761, example.com), operated by IANA for documentation purposes.

I'll admit up front I don't know exactly how DNS records works, but I think if you're copying the protocol into the domain name simply to get a one-to-one mapping it's not logically correct. If go to ftp://example.com I want example.com's ftp server. If I go to http://example.com/ I want example.com's web server. I should not have to go to ftp://ftp.google.com and http://www.example.com/ that would have to be because of technical design limitations. I believe you also get google.com's email servers, like you don't have to look up email.google.com for that so why can't you tell ftp and www apart? Of course if it's the same protocol but say intranet.example.com then it's okay.

I'll admit up front I don't know exactly how DNS records works, but I think if you're copying the protocol into the domain name simply to get a one-to-one mapping it's not logically correct. If go to ftp://example.com I want example.com's ftp server. If I go to http://example.com/ I want example.com's web server. I should not have to go to ftp://ftp.google.com and http://www.example.com/ that would have to be because of technical design limitations. I believe you also get google.com's email servers, like you don't have to look up email.google.com for that so why can't you tell ftp and www apart? Of course if it's the same protocol but say intranet.example.com then it's okay.

I'll admit up front I don't know exactly how DNS records works, but I think if you're copying the protocol into the domain name simply to get a one-to-one mapping it's not logically correct. If go to ftp://example.com I want example.com's ftp server. If I go to http://example.com/ I want example.com's web server. I should not have to go to ftp://ftp.google.com and http://www.example.com/ that would have to be because of technical design limitations. I believe you also get google.com's email servers, like you don't have to look up email.google.com for that so why can't you tell ftp and www apart? Of course if it's the same protocol but say intranet.example.com then it's okay.

This is the only valid use of punycode: look of disapproval.

My early 1990s memories are that my ISP provided free hosting, though on their domain (e.g. http://example.com/~username) and also email and even Usenet! Geocities is one of those things that never made sense to me, not even as a cheapskate. My 1994 ISP even let me do CGI on my web pages, though I didn't take advantage of it except as a toy.

It's the modern ISP which doesn't offer that, except maybe email. No free hosting. Definitely no free Usenet!

MySpace wasn't about cheaper hosting; it was a deliberate effort on the part of the users, to centralize and have all of "us" (whoever that is) connected not just by hyperlinks, but by semantics within the website itself.

We probably should have tried harder to get by with hyperlinks.

One I really visit often is http://dataserver/ with the IP address 192.168.1.27. So please tell me how I should turn that into https without Google Chrome yelling at me that it is insecure.

Sure, I could try to use a name like https://dataserver.example.com... and use the external address instead of the internal one, but that makes it LESS secure.

Not possible with https://certbot.eff.org/ and I am not going to pay for it, if it is possible at all. Yes, I know I cab create my own signature, but Choogle Chrome does not trust it.

Except the whole point of HTTPS is that the government only knows you visited https://example.com/ and not which page on example.com you visited.

Technically the monitor can't see the whole URL. Monitoring only lets you see that they resolved the name example.com, and that they then visited port 443 on that site. The network traffic is encrypted and you can't be sure if they visited index.html or not.

I realize this is probably what you meant, and is just splitting hairs, but it pays to be accurate.

Except the whole point of HTTPS is that the government only knows you visited https://example.com/ and not which page on example.com you visited.

Sounds more like an example of http://example.com?query=chess... not returning a 404 error, and some clown firing off a takedown notice and collecting a bounty from the music publisher.

I don't see how Bluetooth helps with fingerprinting users if the user has to first click "Allow for https://example.com/".

If you are addressing this from a position of objecting to fingerprinting in general: The easiest way to fingerprint users is to require a Google, Facebook, Twitter, Microsoft, or email account login to read past the abstract. As browsers add anti-fingerprinting measures, watch more sites become "free reg. req."

Here you go, the short version is that Facebook noticed the problem and spend time with the browser vendors:

Over the past two years Facebook has been working with browser vendors to improve browser caching. As a result of this work, both Chrome and Firefox recently launched features that make their caches significantly more efficient both for us and for the entire web. These changes have helped reduce static resource requests to our servers by 60% and as a result have dramatically improved page load times. (A static resource is a file our server reads from disk and then just serves it without running any extra code.) In this post, we'll detail the work we did with Chrome and Firefox to get this result — but let's start with a a bit of context and definitions that help explain the problem that needed to get solved. Up first, revalidation.
Every revalidation means another request

As you navigate the web you often reuse the same resources — things like logos or JavaScript code that are reused across pages. It's wasteful if browsers download these resources over and over again.

To stop unnecessary downloads, HTTP servers can specify an expiration time and a validator for each request that can indicate to a browser that it doesn't need to download until later. An expiration time tells the browser how long it can re-use the latest response and is sent using the Cache-Control header. A validator is a way to allow the browser to continue to re-use the response even after the expiration time. It allows the browser to check with the server if a resource is still valid and re-use the response. Validators are sent via Last-Modified or Etag headers.

Here's an example resource that expires in an hour and has a last-modified validator.

$ curl https://example.com/foo.png
> GET /foo.png

In this example, for the next hour, a browser which received this response can re-use it without contacting example.com. After that the browser must revalidate the resource by sending a conditional request to check if the image is still up to date:

$ curl https://example.com/foo.png -H 'if-modified-since: Mon, 17 Oct 2016 00:00:00 GMT'
> GET /foo.png
> if-modified-since: Mon, 17 Oct 2016 00:00:00 GMT

If the image was not modified

A not modified (304) response is sent if the resource has not been modified. This has benefits over downloading the whole resource again, as much less data needs to be transferred, but it doesn't eliminate the latency of the browser talking to the server. Every time a not-modified response is sent, the browser already had the correct resource. We want to avoid these wasted revalidation by allowing the client to cache for longer.
Signaling no download needed over the long term

Revalidation raises a difficult question: How long should your expiration times be? If you send expiration times of one hour, browsers will have to talk to your server to check if your resources have been modified every hour. Many resources like logos or even JavaScript code change rarely; every hour is overdoing it in those cases. On the other hand, if your expiration times are long, browsers will serve the resource from cache potentially showing users out of date resources.

To solve this problem, Facebook uses the concept of content addressed URLs. Rather than our URLs describing a logical resources (“logo.png,” “library.js”) our URLs are a hash of our content. Every time we release our site, we take each static resource and hash it. We maintain a database that stores those hashes and maps them to their contents. When serving a resource rather than serving it by name, we create a URL that has the hash. For example, if the hash of logo.png i

Here you go, the short version is that Facebook noticed the problem and spend time with the browser vendors:

Over the past two years Facebook has been working with browser vendors to improve browser caching. As a result of this work, both Chrome and Firefox recently launched features that make their caches significantly more efficient both for us and for the entire web. These changes have helped reduce static resource requests to our servers by 60% and as a result have dramatically improved page load times. (A static resource is a file our server reads from disk and then just serves it without running any extra code.) In this post, we'll detail the work we did with Chrome and Firefox to get this result — but let's start with a a bit of context and definitions that help explain the problem that needed to get solved. Up first, revalidation.
Every revalidation means another request

As you navigate the web you often reuse the same resources — things like logos or JavaScript code that are reused across pages. It's wasteful if browsers download these resources over and over again.

To stop unnecessary downloads, HTTP servers can specify an expiration time and a validator for each request that can indicate to a browser that it doesn't need to download until later. An expiration time tells the browser how long it can re-use the latest response and is sent using the Cache-Control header. A validator is a way to allow the browser to continue to re-use the response even after the expiration time. It allows the browser to check with the server if a resource is still valid and re-use the response. Validators are sent via Last-Modified or Etag headers.

Here's an example resource that expires in an hour and has a last-modified validator.

$ curl https://example.com/foo.png
> GET /foo.png

In this example, for the next hour, a browser which received this response can re-use it without contacting example.com. After that the browser must revalidate the resource by sending a conditional request to check if the image is still up to date:

$ curl https://example.com/foo.png -H 'if-modified-since: Mon, 17 Oct 2016 00:00:00 GMT'
> GET /foo.png
> if-modified-since: Mon, 17 Oct 2016 00:00:00 GMT

If the image was not modified

A not modified (304) response is sent if the resource has not been modified. This has benefits over downloading the whole resource again, as much less data needs to be transferred, but it doesn't eliminate the latency of the browser talking to the server. Every time a not-modified response is sent, the browser already had the correct resource. We want to avoid these wasted revalidation by allowing the client to cache for longer.
Signaling no download needed over the long term

Revalidation raises a difficult question: How long should your expiration times be? If you send expiration times of one hour, browsers will have to talk to your server to check if your resources have been modified every hour. Many resources like logos or even JavaScript code change rarely; every hour is overdoing it in those cases. On the other hand, if your expiration times are long, browsers will serve the resource from cache potentially showing users out of date resources.

To solve this problem, Facebook uses the concept of content addressed URLs. Rather than our URLs describing a logical resources (“logo.png,” “library.js”) our URLs are a hash of our content. Every time we release our site, we take each static resource and hash it. We maintain a database that stores those hashes and maps them to their contents. When serving a resource rather than serving it by name, we create a URL that has the hash. For example, if the hash of logo.png i

Of course, if someone could get in far enough to hijack the password database, then you've got bigger security issues than just those pertaining to a single account anyway.

Not necessarily. A lot of places have quite lax security on their hashed and salted password file, because it's regarded as secure (it will take a long time to brute force). In other places, it just takes an information disclosure vulnerability (accidentally making something world readable when it shouldn't be, like those fun web server things where you could go to http://example.com/../../etc/p... and grab the file), not a full system compromise, to get the passwords and then if you can crack one then you can log in properly and do something more dangerous.

If all of the passwords are reasonably strong, then you'll need to do a large search to find a hash collision, but it's something that can be trivially parallelised (and works nicely on GPUs, so a targeted attack from someone with a cluster of GPUs to throw at it might be lucky). A few years ago, someone with 25 GPUs was computing 348 billion password hashes per second. If your passwords are upper case, lower case, number, and one of 20 punctuation symbols, then that gives you 82 symbols per character. For an 8-character password, that's about 100 seconds to search every possible combination. The time increases by a factor of 82 each extra character, so that's about 2 hours for 9-character passwords. For 10-character passwords, that's a bit over a year, but remember that I'm using 4-year-old numbers for performance (GPUs are faster now), and it's an embarrassingly parallel problem, so using 250 GPUs (not that expensive in comparison to the value of your corporate assets) would bring it down to about a month.

Hopefully your password database is using a slow hash (e.g. sha512crypt), which takes a lot longer, but an adversary able to throw more (or custom) hardware at the problem can still likely manage it for most 10-character passwords.

That was ftp://ftp.example.com/file.zip [example.com] before slashdot helpfully linkified it and dropped the user@ portion.

File a support ticket.

That was ftp://user@ftp.example.com/file.zip before slashdot helpfully linkified it and dropped the user@ portion.

Most web browsers or OSs will handle an ftp transfer just fine, without the need to install anything new. You can even send a URL by email that will prompt them for a password if you don't want to put a file in a publicly accessible place: ftp://ftp.example.com/file.zip

# lynx http://example.com/

And because we need to ~double the amount of data used by all the hamster forums, cat videos and aircraft curation guides, especially when a lot of the world's users are on slow or data-limited connections?

Look. I get that it's good to ensure that there's no injected content, and that you know you're connected to the site you want - but that's only true for 1% of the population. The rest of the world wouldn't know the difference between https://www.example.com/member... and https://www.example.com.member.... Both "secure" because they're HTTPS, right?

Factor in all the browsers deciding that privately-signed sites are worse than plain http, that no-one needs to actually SEE the protocol, or the URL, that all the certs are issued by a cabal of companies who just see the benefit of charging for a NUMBER, but barely doing validation ... but sure. "Adding security". Right.

When you type "slashdot.org" into your browser it goes to the HTTP site first and gets redirected to the HTTPS version.

This will work only until Slashdot starts sending Strict-Transport-Security headers or gets included in the ruleset for EFF's HTTPS Everywhere browser extension. Then you'll have to resort to what I do: http://example.com/

Wait, what? You're saying that if I went to http://example.com/x/y/z Directly I'd get the exact same HTML rendered out as if I'd gone to http://example.com/ and clicked a link to /x/y/z ?

So basically, after forcing all this ajax on everyone for years you're finally getting back to Web 1.0 with proper links that actually link to stuff instead of linking to a pile of javascript

Wait, what? You're saying that if I went to http://example.com/x/y/z Directly I'd get the exact same HTML rendered out as if I'd gone to http://example.com/ and clicked a link to /x/y/z ?

So basically, after forcing all this ajax on everyone for years you're finally getting back to Web 1.0 with proper links that actually link to stuff instead of linking to a pile of javascript

Privacy Badger has its own "Acceptable Ads" policy, which is as simple as promising to respect the "Do not track" header and supporting HTTPS.

I am an online advertising / tracking company. How do I stop Privacy Badger from blocking me?

One way is to stop tracking third party users who have turned on the Do Not Track header (i.e., stop collecting cookies, supercookies or fingerprints from them). That will work for new Privacy Badger installs.

If copies of Privacy Badger have already blocked your domain, you can unblock yourself by promising to respect the Do Not Track header in a way that conforms with the user's privacy policy. You can do that by posting a specific compliant DNT policy to the URL https://example.com/.well-know..., where "example.com" is all of your DNT-compliant domains. Note that the domain must support HTTPS, to protect against tampering by network attackers. The path contains ".well-known" per RFC 5785.

Privacy Badger currently checks for this specific verbatim policy document, though in the future Privacy Badger may allow content from sites that post different versions of a compliant DNT Policy, and that there may be ways for users to specify their own acceptable DNT policies if they wish to.

Source

Personally, I find the approach to be less naive than ABP's, but only slightly.

I use uBlock Origin and find it to be lighter weight than the old Adblock Plus/edge extensions. Combined with uMatrix, it's a much more responsive and usable combination than the old ABP + NoScript pairing.

How does this 'Ransomware' get downloaded and run on the machine?

Easy. From most likely to least, here's a few ways

1) User visits web page, web page says it needs to install a plugin to work, click here for the link. (Variants include downloading a movie that shows "Codec not installed. Visit http://evil-site.example.com/c... to download required software", email that says "Your invoice is enclosed - refund and cancellation instructions contained within" (interestingly - all those emails for fake invoices always make it so helpful to cancel the order), and many others).

2) User downloads pirated software or crack/keygen wrapped with this software so before the crack/keygen runs, it infects the PC. This is a very popular way, so popular that malware authors are dispensing with the whole "wrapping" aspect (where a legitimate application has a malware executable set to run first then the application, bundled into a single file) and just releasing the malware stubs under all sorts of filenames in the hopes the user will download it and blindly click it.

3) Infected media exploiting autoplay (USB, optical disc, etc)

Why is there an API for sending a text message from a web page? Why does this need to exist at all?

You'd think someone at Apple, when they came up for this idea for this, would be shot down by someone else saying "Sorry dude, this is a feature that can be abused."

It wasn't shot down when mailto: was included in the HTML spec. As long as the API doesn't allow you to actually send it without further consent, how is it any different than every other app's "Send to Facebook|Twitter|Email|Whatever" functionality?

The difference is money.

For many people, there is a cost per message (over some monthly limit) to send/receive texts, and 'subscription' texts (as the ad in the article was apparently trying to set up through this sketchy exploit) charge the user above and beyond the carrier costs. Posting to FB or Twitter doesn't carry any significant cost rider (just loss of dignity, but that's going cheap nowadays), unless the payload is big enough to impact data costs. Even emails are not individually metered like text messages, although I suppose there the data costs could potentially be higher depending on attachments.

This is even worse than those scammy mailers for credit cards, the ones that 'helpfully' pre-fill the application form out with as much of your personal info as they have access to. At least for those you have to make an effort to fill in the remaining fields and physically mail the application form: here you just have to accidentally hit the 'send' button instead of the 'cancel' button (easy to do, esp. if you're used to Android) in order to give them 'permission' to charge you, not only once but multiple times. Also, you can bet that your phone number is now on as many robot scam-dialer databases as possible...there's just no way the user wins in this scenario.

Why is there an API for sending a text message from a web page? Why does this need to exist at all?

You'd think someone at Apple, when they came up for this idea for this, would be shot down by someone else saying "Sorry dude, this is a feature that can be abused."

It wasn't shot down when mailto: was included in the HTML spec. As long as the API doesn't allow you to actually send it without further consent, how is it any different than every other app's "Send to Facebook|Twitter|Email|Whatever" functionality?

Get yourself a cheap PC and install Squid on it, then configure all your browsers, etc. to use that as a proxy. Think of it as a huge, multi-user, multi-platform, multi-browser shared cache. If you find an interesting article on CNN and share it with your wife/roommate/dog, there's no need for them to re-download the entire thing. You can also switch from, say, Chrome to Firefox if a page doesn't render as expected and not have to refetch all of it. Once one person on your LAN fetches http://example.com/image.gif, you all get the benefit of having it stored on your own network.

This made a slow connection at a previous house almost tolerable. It's not a cure-all but I'd stake cash that you'd see a noticeable improvement in routine browsing.

So you mean, after answering http://example.com/'s cookie question with 'no', it would rewrite all links to, say http://example.com/nocookies/, which behaves identical except not asking for a cookie? Fair enough, then.

If on the other hand you mean encoding a session ID in the url, which this:

cookies are often JUST use for authentication. each url is fully complete and describes entirely what is asked of the REST service

seems to imply (does it? if not, how tell different users apart?) then the answer is no, that's not a good idea and already addressed in (my) GP comment

So you mean, after answering http://example.com/'s cookie question with 'no', it would rewrite all links to, say http://example.com/nocookies/, which behaves identical except not asking for a cookie? Fair enough, then.

If on the other hand you mean encoding a session ID in the url, which this:

cookies are often JUST use for authentication. each url is fully complete and describes entirely what is asked of the REST service

seems to imply (does it? if not, how tell different users apart?) then the answer is no, that's not a good idea and already addressed in (my) GP comment

This raises three questions.

First, how would you "encrypt all websites" as long as Windows XP maintains a loyal following despite its end of support? Because Internet Explorer for Windows XP doesn't support Server Name Indication, it can see only the first certificate on port 443 of a given IP address. This breaks name-based virtual hosting, requiring to lease an increasingly scarce IPv4 address.

Second, your "Marking HTTP As Non-Secure" page mentions example.com. I most often use that hostname to log into public Wi-Fi hotspots because a lot of the websites I use daily use HTTPS, which doesn't allow the MITM that a captive portal requires. Even if I key in http: into the address bar, HSTS or the HTTPS Everywhere extension will transparently redirect my request to HTTPS. If web browsers discourage users from visiting cleartext HTTP sites, how are they supposed to log into hotspots?

Third, and most relevantly for this article, even if you "encrypt all websites", you still have to give the website (or a third-party script operating in the website's context) a copy of your private key in order for it to encrypt and decrypt your mail.

http://example.com:443/ ?

The source for that wasn't a peer reviewed published paper but an interview with a journalist.

That's fine — I don't insist, your examples must come from a scientific magazine either.

So he wasn't saying it would never snow

He did say: "Children just aren't going to know what snow is". That means, it was not going to snow — in his opinion.

The ice free prediction by Maslowski was peer reviewed science but it was at odds with a lot of other predictions at the time.

Didn't prevent Al Gore from parroting it, did it? But fine, you can quote predictions, which were likewise disapproved by the predictor's peers at the time too.

So while Maslowski's projection may not be correct it was far from the only scientific opinion about it at the time.

In other words, contrary to frequent assertions, the science is not settled.

Ok, here's a twofer

I'm giving up... Just how can you call a single link a "twofer"? I gave you — and not for the first time — an example of the format:

1. Prediction of foo happening made in year XXXX. Foo happening N years later.

Is it really so hard?

Hard-coded names are easy - you make some entries in your hosts file.

Applying the well-known APK workaround doesn't work when the application sees that the certificate doesn't match the certificate that the application expects.

Your connection to [Game Title] may be compromised!

Your Internet service provider (ISP) appears to be intercepting and changing traffic. [Game Title] cannot ensure that your connection to other players is secure.

Are you connecting through public Wi-Fi? Your provider may be sending a page asking you to log in to the hotspot using a web browser. To see if this is the problem, try logging in and playing again.

Are you playing on break time at work? Your office may be intercepting traffic to check it for viruses or data leaks. To see if this is the problem, try playing from another location.

Yep. Default behaviour is to block that stuff, if your ISP is any good. Depending on how cheap the cheaper ISP was, you might or might not be able to get your connection set to allow it, and your costs might get a lot higher. (If BGP was an option, you could often just announce the routes; if it was a consumer cable modem, or probably even a business cable modem, you can't fix it, but you can still play load-balancing games with your DNS, or do redirects from your webserver so that http://www.example.com/stuff redirects to http://www-cablemodem.example...., etc.)

Yep. Default behaviour is to block that stuff, if your ISP is any good. Depending on how cheap the cheaper ISP was, you might or might not be able to get your connection set to allow it, and your costs might get a lot higher. (If BGP was an option, you could often just announce the routes; if it was a consumer cable modem, or probably even a business cable modem, you can't fix it, but you can still play load-balancing games with your DNS, or do redirects from your webserver so that http://www.example.com/stuff redirects to http://www-cablemodem.example...., etc.)

Buddy, you can get a certificate for less than FIVE US dollars per year. Is that too much for you?

Actually yes, frankly it is. Because according to Google's overpaid, brain-dead Chrome developers, I need one for the KVM, one for each of the management cards in the servers, one for each of the appliances I have (from DVRs to firewalls etc), one for each little device with a web server (assuming it even supports writing a certificate to storage, and config for HTTPS), one for each workstation or server with an app or config UI. Quick count for my house alone ... 47 certs excluding the devices that quite literally have NO way to store and use a cert. I simplified too by assuming the devices supporting certs can handle SHA256 (thanks Google for THAT little recent shitfight). And the certs don't support SANs nor do CAs allow local names, so I have to use the correct FQDN all the time now (no more http://dvr/ or typing the IP - now it's https://dvr.private.example.co...). And what have I gained? I've had to spend $230+ and several hours of work to avoid irrelevant anti-sec warnings, on devices no-one can get to except me. It's bulldust.

Just download this handy powerpoint slideshow and I think you'll find it explains how this attacks works in perfect detail...

Still, HTTPS would at least prevent your ISP from monitoring your browsing activity.

That's part of it - a valuable enough part in itself, IMO; at least one UK ISP, TalkTalk, has started duplicating HTTP requests made by their customers: so, if you request http://example.com/stuff on one of their lines, 30 seconds later they'll go and request the same URL themselves for monitoring purposes.

But, but... That doesn't make any sense!

Using HTTP, the connection isn't encrypted in either direction. If they can see the original request, they can also see the original response, so why not just cache that?

What's the benefit of doing a second request for the same content?

Unless you're on a capped line and both requests/responses count towards your limit? Is that it?

Still, HTTPS would at least prevent your ISP from monitoring your browsing activity.

That's part of it - a valuable enough part in itself, IMO; at least one UK ISP, TalkTalk, has started duplicating HTTP requests made by their customers: so, if you request http://example.com/stuff on one of their lines, 30 seconds later they'll go and request the same URL themselves for monitoring purposes. Obviously, enabling SSL prevents this kind of gratuitous stupidity - and the previous incarnation of such snooping, Phorm. If enough websites enable SSL, ISPs will no longer have the ability to monitor customer behavior that closely, all they will see are SSL flows to and from IP addresses, and whatever DNS queries you make to their servers, if any. (Use encrypted connections to OpenDNS or similar, and your ISP will only ever see IP addresses and traffic volume - exactly as it should be IMO!)

This is a test.
http://soylentnews.org/
http://soylentnews.org
test
http://soylentnews.org

Test.

I see. Then you shouldn't create hyperlinks at all (and somehow avoid Slashdot automatically creating them). That is, if you want to be security conscious, as you say. For example, this is a "slashdot.org" link which actually points to example.com: http://slashdot.org/

If copies of Privacy Badger have already blocked your domain, you can unblock yourself by promising to respect the Do Not Track header in a way that conforms with the user's privacy policy. You can do that by posting a specific compliant DNT policy to the URL https://example.com/.well-know..., where "example.com" is all of your DNT-compliant domains.

So in other words, To exclude a website from Privacy Badger, all a website needs to do is:
- Copy and paste https://www.eff.org/files/dnt-... to https://mywebsite.com/.well-kn...

Give it a few weeks, let the advert sites copy and paste that file, plugin will be useless.

2. No H.265 support means this model of FireTV will become obsolete later this year.

I think you may be exaggerating somewhat. Virtually nothing has H.265 support right now. Are you seriously suggesting every single electronic device capable of playing video will magically become "obsolete" in a few months? We'll all have to throw out our smartphones and tablets and PCs and media players and TVs? Are the landfills going to be overflowing with 250 million discarded LCD screens?

Allowed HTML

1. • URLs http://example.com/ will auto-link a URL Important Stuff Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you are having a problem with accounts or comment posting, please yell for help. Slow Down Cowboy! Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment. It's been 4 minutes since you last successfully posted a comment Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form. Please try again. If the problem persists, and all other options have been tried, contact the site administrator.

Are you seriously suggesting there has ever been a time in history where someone's actions have played no role in deciding whether they're qualified for a specific job?

Yes, it was absurd and evil to disqualify communists from being actors or screenwriters. Would it also have been absurd and evil to disqualify someone from being head of the CIA because of past, undisclaimed, material support for the CCCP?

Allowed HTML

1. • URLs http://example.com/ will auto-link a URL Important Stuff Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) Slow Down Cowboy! Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment. It's been 3 minutes since you last successfully posted a comment Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form. Please try again. If the problem persists, and all other options have been tried, contact the site administrator. If you are having a problem with accounts or comment posting, please yell for help. So here is your nontroversy of the afternoon: Donald Trump is furious that Barack Obama has mentioned the possibility of a terrorist nuclear attack on Manhattan, because, as he told Fox Newsâ(TM)s Greta Van Susteren today, the President âoejust put a big target on Manhattan.â Damn you, Obama! If only you had kept Manhattan a secret, no terrorist ever would have thought to attack it, and the city would remain safe from terrorist attacks, just like it was during George W. Bushâ(TM)s blemish-free reign. Read more at http://wonkette.com/#m4TQ3Etgd... Slow Down Cowboy! Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment. It's been 4 minutes since you last successfully posted a comment Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form. Please try again. If the problem persists, and all other options have been tried, contact the site administrator.

Different AC here. You got down-modded for several reasons. First, your improper capitalization, poor spelling and poor grammar makes your post look like a troll right off the bat. It also looks like it was posted to multiple stories, which from a quick Google search, turns out to be true. Next, the hosts file lacks the finesse of ad-blocking in the browser. It only blocks an entire domain and can't block a directory or file within a domain. When a domain is blocked, it has to go somewhere. Sending it to 127.0.01 may result in a timeout, which is SLOW! Some pages can't render until the whole page is loaded. Finally, DNS was invented for a reason. Before DNS, the Internet did use one massive hosts file that was copied around from machine to machine. DNS solves a lot of problems, such as load balancing and it changing a server's IP (such as by moving it to a new hosting platform), and quite a few more.

To pick out a few points:
"more than AdBlock": AdBlock can block http://www.example.com/banners/.* without blocking http://www.example.com/login.php Hosts files cannot.
"more than Ghostery": This is a close one. The best I can come up with is that Ghostery is easier to update and maintain.
"Request Policy": Request Policy detects "unwanted behaviour" rather than being a strict whitelist/blacklist. A hosts file cannot even come close to doing this.
"reliability vs. downed or redirected DNS": True, although you lose reliability if a server you are trying to contact changes IPs and your hosts file is out of date.
"secure vs. known malicious domains": True, although maintenance and slow updates will kill you.
"more speed" "blocks ads": Not if you get a timeout that prevents the page from rendering.
"more speed" "hardcodes fav": Hardcoded IPs lose out on DNS based load balancing.

(I'm not replying to the rest of the points because I got bored with it. Don't expect a reply from me, just passing through.)

Different AC here. You got down-modded for several reasons. First, your improper capitalization, poor spelling and poor grammar makes your post look like a troll right off the bat. It also looks like it was posted to multiple stories, which from a quick Google search, turns out to be true. Next, the hosts file lacks the finesse of ad-blocking in the browser. It only blocks an entire domain and can't block a directory or file within a domain. When a domain is blocked, it has to go somewhere. Sending it to 127.0.01 may result in a timeout, which is SLOW! Some pages can't render until the whole page is loaded. Finally, DNS was invented for a reason. Before DNS, the Internet did use one massive hosts file that was copied around from machine to machine. DNS solves a lot of problems, such as load balancing and it changing a server's IP (such as by moving it to a new hosting platform), and quite a few more.

To pick out a few points:
"more than AdBlock": AdBlock can block http://www.example.com/banners/.* without blocking http://www.example.com/login.php Hosts files cannot.
"more than Ghostery": This is a close one. The best I can come up with is that Ghostery is easier to update and maintain.
"Request Policy": Request Policy detects "unwanted behaviour" rather than being a strict whitelist/blacklist. A hosts file cannot even come close to doing this.
"reliability vs. downed or redirected DNS": True, although you lose reliability if a server you are trying to contact changes IPs and your hosts file is out of date.
"secure vs. known malicious domains": True, although maintenance and slow updates will kill you.
"more speed" "blocks ads": Not if you get a timeout that prevents the page from rendering.
"more speed" "hardcodes fav": Hardcoded IPs lose out on DNS based load balancing.

(I'm not replying to the rest of the points because I got bored with it. Don't expect a reply from me, just passing through.)

<a href="example.com">...</a>
<a href="http://example.com">...</a>
See the difference?

Fucking slashdot changed my links from wikipedia to slashdot.

Are you complaining because /. lacks a <DWIM> tag, along with the strong AI that implies?
Or because someone failed to teach you about absolute and relative URLs?

Either way, it seems a little unreasonable to blame /. for it.

(Now the tablet UI, I'm with you all the way blaming /. for that abomination. If you have the ability, changing to a desktop user-agent string will get around it -- but there's NO reason we should have to do that.)

No I'm complaining because slashdot took a perfectly valid absolute URL and somehow munged it into something other than what I'd entered before pressing submit. The only difference between that post and the dozens of others I've made previously is that I was using a tablet to do it. Fucked if I know why they would do something different to html embedded in a post from a tablet versus a desktop but I know what was in the textarea before I sumbitted and it sure as fuck was an absolute url with wikipedia in the hostname section.

<a href="example.com">...</a>
<a href="http://example.com">...</a>
See the difference?

Fucking slashdot changed my links from wikipedia to slashdot.

Are you complaining because /. lacks a <DWIM> tag, along with the strong AI that implies?
Or because someone failed to teach you about absolute and relative URLs?

Either way, it seems a little unreasonable to blame /. for it.

(Now the tablet UI, I'm with you all the way blaming /. for that abomination. If you have the ability, changing to a desktop user-agent string will get around it -- but there's NO reason we should have to do that.)

In fact something like this exists and may even be supported by your browser, but isn't in wide deployment at the moment. The way it works is that example.com goes out and gets an SSL cert for example.com, signed by some reasonable CA. example.com also configures dnssec for their domain. When you go to https://example.com/ your web browser does a DNS query against _443._tcp.example.com for TLSA records. If it finds any, it validates the cert it gets via TLS against the TLSA record; the TLSA record can specify what certs are valid, or it can specify what certificate authority key (trust anchor) is valid, and there are a few other modes. The basic principle is that you now have two paths for validating the TLS cert: the CA _and_ DNSSEC. If both validate, use the cert. If either fails, don't use it. You can read all about it here.

In addition, TLS provides for certificate revocation, so if someone generates a bogus cert and it is _detected_, the cert can be revoked, or if a key is compromised, the cert for that key can be revoked.

These mechanisms seem more likely to be useful than just requiring certs from two different CAs.