MS Edge is a fast, lean, and efficient browser. When I play around with underpowered WinTabs, Edge consistently has smoother browsing (load times, scrolling, etc.) all around, when compared to Chrome and FF. It simply uses less RAM and CPU compared to the competition. Therefore, it's not surprising that it fares better with battery life comparisons. If they made even more improvements lately compared to the last time I played with Edge, I congratulate them for a job well done. Edge is indeed much more efficient than their competition, and as a web/software developer, that makes me appreciate their efforts on that front.
HOWEVER, that does not excuse their crappy security model. Anyone that's watched recent hacking events should know that Edge is the laughing stock of the bunch when it comes to vulnerabilities. Some of it comes with being the younger browser of the bunch. But that shouldn't really be an excuse in this day and age. I can't trust a browser that is so full of holes.
I'd appreciate if MS focused more on closing gaping security holes than a few more % on arbitrary benchmarks that become meaningless because the target audience is too afraid to use the product anymore.
Just like.edu,.gov all require valid certification (to a degree) for ownership, they could simply institute a new TLD where the registry requires ID validation, and prohibits all privacy services for WHOIS information. Enforce a strict contact availability policy, and you have as good of a system as you can pragmatically setup. As an opt-in TLD, no one would be forced to sacrifice their privacy for their current TLDs, and the sites that want to be legitimate sources of information can host their content on their verified domains.
I don't for a minute think this addresses the problem of the masses believing everything they read on traditional.com sites -- and also especially on social networks. But going this route could potentially improve the accessibility of credible information for those that can be bothered to source-check.
So it happened less than a year ago. What you researched 18 months ago was probably legit. The acquisition happened after your issuance. That said, having been a long time user of StartCom/StartSSL, I find this is depressing it's gone this route. But I've moved on to LetsEncrypt recently anyways, since the StartSSL website was a royal PITA to use, and LetsEncrypt works much more fluidly.
I've been holding my breath for a long time for this, and it's pretty disappointing to have to say... This is really not ready for real use -- at least for most non-trivial use.
For example, I can't easily get a MySQL connector to work, since it's meant for.NET 4.x and not Core. The majority of packages I use in my projects don't support Core. Obviously this takes time, and without Core being live, it would have less priority for package maintainers to actually support Core. That's understandable. But it's just hard to do anything useful with it, and as a developer, it's highly frustrating to not be able to do something that should be so fundamental like importing 3rd party packages.
The new CLI toolset is a bit weird, and it's a few steps backwards of what they were proposing of being able to do, like save and reload (quickly) -- but I suppose that for now, I should just be celebrating that they're headed in the right direction... Maybe.
The RFC you linked to points out: in a proxy situation, this establishes a secure connection between you and the proxy (between proxy and target site is undefined). If you want end-to-end TLS, it states you must use CONNECT to create a tunnel.
I can't imagine Amazon would funnel TLS encrypted connections through AWS using this method, since the whole point of Silk is to analyze/cache/preload the content (end-to-end crypto would break this ability). If they couldn't read your HTTPS data, it would be less latency for you and cheaper for Amazon to have the client connect directly. Their Help site makes it sound like proxy/cached mode is the default setting, so IMHO it still is effectively a man-in-the-middle.
Thankfully, it looks like you can disable it (or use a different browser), so I may just be paranoid for no reason.
What about handling secure (https) connections?
We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com/ ).
So essentially, they become the man-in-the-middle so they can better cache your HTTPS content? And their browser is programmed to show this is acceptable/secure... What kind of privacy implications does this introduce? Even if their privacy policy says they won't use the data maliciously, cloud computing isn't a bullet-proof system (i.e., leaks, hacking incidents, etc.). Call me paranoid, but if I read this right, this sounds like a frightening idea.
What about handling secure (https) connections?
We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com/ ).
So essentially, they become the man-in-the-middle so they can better cache your HTTPS content? And their browser is programmed to show this is acceptable/secure... What kind of privacy implications does this introduce? Even if their privacy policy says they won't use the data maliciously, cloud computing isn't a bullet-proof system (i.e., leaks, hacking incidents, etc.).
Call me paranoid, but if I read this right, this sounds like a frightening idea.
There's all this talk of URL shortening services - whether third-party, or in-house implementation.
The question here is this: Why are the URLs so long to begin with?
Why does it have to be: http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
A full title in the URL is, IMHO, a very inefficient idea. The excuses I've heard are:
Search Engine Optimizations (better performance when keywords are in the URL)
Okay, I can't argue that some search engines do stuff like that. But shouldn't the TITLE or META tags have more bearing on this than how ridiculously long the URL is?
"The URL has meaning, so you know what you're clicking", Context, etc.
I suppose that when I see a URL like http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
as opposed to something like http://example.org/blog/526
I would have a slightly better idea of the article's content before clicking on it. But then again, I can't really say that I've decided against clicking on a link just because of the link URL. I would, instead, decide whether I'd want to visit the link by its link text/description.
So <a href="http://example.org/blog/526">blog on link shortening</a> would still have the same effect on me as a long URL IMO. If it were bookmarked, the same rules would apply.
Hell, if I were handed an obfuscated shortened URL without context, I'd know even less of what I was getting myself into.
I think the proper solution is to just stop making ridiculously long URLs to begin with, so we don't have to rely on obfuscation/hashing/shortening to accommodate services that have character limit restrictions. And we'd save bandwidth too, apparently. Win-win?
Maybe I'm off my rocker, but I believe my Bittorrent client uses UDP for DHT. Perhaps the school's pipe was being saturated by torrent downloads to begin with, and Halo was merely the straw that broke the camel's back? The fact that shaping UDP fixed the bandwidth issue tells me that an online game couldn't be the cause of it unless everyone decided to skip class for a campus-wide Halo-fest.
[joshuaa@nemo joshuaa]$ uname -a Linux nemo 2.6.9 #1 SMP Tue Nov 30 15:21:17 PST 2004 i686 Intel(R) Xeon(TM) CPU 2.66GHz GenuineIntel GNU/Linux [joshuaa@nemo joshuaa]$ gcc -v Reading specs from/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs Co nfigured with: [abbreviated] Thread model: posix gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) [joshuaa@nemo joshuaa]$ make test gcc test.c -o test test.c: In function `check_vma_flags': test.c:545: warning: deprecated use of label at end of compound statement [joshuaa@nemo joshuaa]$./test
child 1 VMAs 0 [+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000 [+] vmalloc area 0xb5c00000 - 0xffffd000 [-] FAILED: open lib (/dev/shm/_elf_lib not writable?) (Permission denied) Killed
Of course the exploit sample code specifically says only tested on 2.4...
[joshuaa@nemo joshuaa]$ uname -a
Linux nemo 2.6.9 #1 SMP Tue Nov 30 15:21:17 PST 2004 i686 Intel(R) Xeon(TM) CPU 2.66GHz GenuineIntel GNU/Linux
[joshuaa@nemo joshuaa]$ gcc -v
Reading specs from/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Configured with: [abbreviated]
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
[joshuaa@nemo joshuaa]$ make test
gcc test.c -o test
test.c: In function `check_vma_flags':
test.c:545: warning: deprecated use of label at end of compound statement
[joshuaa@nemo joshuaa]$./test
child 1 VMAs 0
[+] moved stack bfffd000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xb5c00000 - 0xffffd000
[-] FAILED: open lib (/dev/shm/_elf_lib not writable?) (Permission denied)
Killed
A "strong" alpha/case-sensitive password at 8 chars long would be:
8 ^ 62 = 9.81e+55 possible passwords
The suggested method might give out *longer* passwords, but it would take a string well over 100 characters long to even come close:
100 ^ 26 = 1e+52 possible passwords
Not to mention that looking at dictionaries, the beginning letter of a word is not very evenly distributed. This would enable simple statistics to run randomized checks faster based on dictionaries, effectively reducing possible combinations even more.
Of course you can remove transparency, reduce the color depth from the original 16 colors, etc. to make it smaller - heck, I can make it 1.395K at 2 colors!
But that's besides the point - we're trying to preserve quality and the original color depth.
> Is anyone still producing calculator watches? Where can I get a new one?
Last I looked for watches, my local Walmart had 2 different models, and I'm sure any local modern watch store would carry one... If not, online stores are your friends. YMMV *shrug*
The demo version for Windows didn't even have NPC voice overs or more than one voice set. The retail version has all of the above where the demos did not.
Your vid card on the 17" probably doesn't support the shiny water AFAIK since it's just a GeForce4 Go440 (derivative of MX440, a souped up GF2MX almost) and has no pixel shaders, etc.
Slashdot Mirror
MS Edge is a fast, lean, and efficient browser. When I play around with underpowered WinTabs, Edge consistently has smoother browsing (load times, scrolling, etc.) all around, when compared to Chrome and FF. It simply uses less RAM and CPU compared to the competition. Therefore, it's not surprising that it fares better with battery life comparisons. If they made even more improvements lately compared to the last time I played with Edge, I congratulate them for a job well done. Edge is indeed much more efficient than their competition, and as a web/software developer, that makes me appreciate their efforts on that front.
HOWEVER, that does not excuse their crappy security model. Anyone that's watched recent hacking events should know that Edge is the laughing stock of the bunch when it comes to vulnerabilities. Some of it comes with being the younger browser of the bunch. But that shouldn't really be an excuse in this day and age. I can't trust a browser that is so full of holes.
I'd appreciate if MS focused more on closing gaping security holes than a few more % on arbitrary benchmarks that become meaningless because the target audience is too afraid to use the product anymore.
Just like .edu, .gov all require valid certification (to a degree) for ownership, they could simply institute a new TLD where the registry requires ID validation, and prohibits all privacy services for WHOIS information. Enforce a strict contact availability policy, and you have as good of a system as you can pragmatically setup. As an opt-in TLD, no one would be forced to sacrifice their privacy for their current TLDs, and the sites that want to be legitimate sources of information can host their content on their verified domains.
I don't for a minute think this addresses the problem of the masses believing everything they read on traditional .com sites -- and also especially on social networks. But going this route could potentially improve the accessibility of credible information for those that can be bothered to source-check.
TFA mentions that:
8 Issue R: Purchase of StartCom (Nov 2015)
So it happened less than a year ago. What you researched 18 months ago was probably legit. The acquisition happened after your issuance. That said, having been a long time user of StartCom/StartSSL, I find this is depressing it's gone this route. But I've moved on to LetsEncrypt recently anyways, since the StartSSL website was a royal PITA to use, and LetsEncrypt works much more fluidly.
Sad, but time to move on, I guess.
I've been holding my breath for a long time for this, and it's pretty disappointing to have to say... This is really not ready for real use -- at least for most non-trivial use. For example, I can't easily get a MySQL connector to work, since it's meant for .NET 4.x and not Core. The majority of packages I use in my projects don't support Core. Obviously this takes time, and without Core being live, it would have less priority for package maintainers to actually support Core. That's understandable. But it's just hard to do anything useful with it, and as a developer, it's highly frustrating to not be able to do something that should be so fundamental like importing 3rd party packages.
The new CLI toolset is a bit weird, and it's a few steps backwards of what they were proposing of being able to do, like save and reload (quickly) -- but I suppose that for now, I should just be celebrating that they're headed in the right direction... Maybe.
The RFC you linked to points out: in a proxy situation, this establishes a secure connection between you and the proxy (between proxy and target site is undefined). If you want end-to-end TLS, it states you must use CONNECT to create a tunnel.
I can't imagine Amazon would funnel TLS encrypted connections through AWS using this method, since the whole point of Silk is to analyze/cache/preload the content (end-to-end crypto would break this ability). If they couldn't read your HTTPS data, it would be less latency for you and cheaper for Amazon to have the client connect directly. Their Help site makes it sound like proxy/cached mode is the default setting, so IMHO it still is effectively a man-in-the-middle.
Thankfully, it looks like you can disable it (or use a different browser), so I may just be paranoid for no reason.
What about handling secure (https) connections?
We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com/ ).
So essentially, they become the man-in-the-middle so they can better cache your HTTPS content? And their browser is programmed to show this is acceptable/secure... What kind of privacy implications does this introduce? Even if their privacy policy says they won't use the data maliciously, cloud computing isn't a bullet-proof system (i.e., leaks, hacking incidents, etc.). Call me paranoid, but if I read this right, this sounds like a frightening idea.
What about handling secure (https) connections?
We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com/ ).
So essentially, they become the man-in-the-middle so they can better cache your HTTPS content? And their browser is programmed to show this is acceptable/secure... What kind of privacy implications does this introduce? Even if their privacy policy says they won't use the data maliciously, cloud computing isn't a bullet-proof system (i.e., leaks, hacking incidents, etc.). Call me paranoid, but if I read this right, this sounds like a frightening idea.
There's all this talk of URL shortening services - whether third-party, or in-house implementation.
The question here is this: Why are the URLs so long to begin with?
Why does it have to be:
http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
A full title in the URL is, IMHO, a very inefficient idea. The excuses I've heard are:
Search Engine Optimizations (better performance when keywords are in the URL)
Okay, I can't argue that some search engines do stuff like that. But shouldn't the TITLE or META tags have more bearing on this than how ridiculously long the URL is?
"The URL has meaning, so you know what you're clicking", Context, etc.
I suppose that when I see a URL like
http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
as opposed to something like
http://example.org/blog/526
I would have a slightly better idea of the article's content before clicking on it. But then again, I can't really say that I've decided against clicking on a link just because of the link URL. I would, instead, decide whether I'd want to visit the link by its link text/description.
So <a href="http://example.org/blog/526">blog on link shortening</a> would still have the same effect on me as a long URL IMO. If it were bookmarked, the same rules would apply.
Hell, if I were handed an obfuscated shortened URL without context, I'd know even less of what I was getting myself into.
I think the proper solution is to just stop making ridiculously long URLs to begin with, so we don't have to rely on obfuscation/hashing/shortening to accommodate services that have character limit restrictions. And we'd save bandwidth too, apparently. Win-win?
Maybe I'm off my rocker, but I believe my Bittorrent client uses UDP for DHT. Perhaps the school's pipe was being saturated by torrent downloads to begin with, and Halo was merely the straw that broke the camel's back? The fact that shaping UDP fixed the bandwidth issue tells me that an online game couldn't be the cause of it unless everyone decided to skip class for a campus-wide Halo-fest.
Of course the exploit sample code specifically says only tested on 2.4... [joshuaa@nemo joshuaa]$ uname -a Linux nemo 2.6.9 #1 SMP Tue Nov 30 15:21:17 PST 2004 i686 Intel(R) Xeon(TM) CPU 2.66GHz GenuineIntel GNU/Linux [joshuaa@nemo joshuaa]$ gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Configured with: [abbreviated]
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
[joshuaa@nemo joshuaa]$ make test
gcc test.c -o test
test.c: In function `check_vma_flags':
test.c:545: warning: deprecated use of label at end of compound statement
[joshuaa@nemo joshuaa]$ ./test
child 1 VMAs 0
[+] moved stack bfffd000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xb5c00000 - 0xffffd000
[-] FAILED: open lib (/dev/shm/_elf_lib not writable?) (Permission denied)
Killed
A "strong" alpha/case-sensitive password at 8 chars long would be:
8 ^ 62 = 9.81e+55 possible passwords
The suggested method might give out *longer* passwords, but it would take a string well over 100 characters long to even come close:
100 ^ 26 = 1e+52 possible passwords
Not to mention that looking at dictionaries, the beginning letter of a word is not very evenly distributed. This would enable simple statistics to run randomized checks faster based on dictionaries, effectively reducing possible combinations even more.
Of course you can remove transparency, reduce the color depth from the original 16 colors, etc. to make it smaller - heck, I can make it 1.395K at 2 colors!
But that's besides the point - we're trying to preserve quality and the original color depth.
Here's also another one:
topicpatents.gif - 1.09 KB (1,123 bytes)
topicpatents.png - 1.71 KB (1,761 bytes)
This is at the original 12 color palette with transparency.
(BTW, this is Photoshop 7.0 on the PC)
title.gif = 3.39 KB (3,473 bytes) (Original Slashdot logo on top right)
.gif format works well, and AFAIK, my cell browser doesn't open PNG at all. Not that slashdot.wap uses images, however...
title.png = 3.34 KB (3,428 bytes) (PNG8 16 color palette)
A conversion would make a mere 45 byte difference.
Oh my... how could I be such an insensitive clod - I forgot some of us are still using 2400 baud modems!
Honestly, the
> Is anyone still producing calculator watches? Where can I get a new one? Last I looked for watches, my local Walmart had 2 different models, and I'm sure any local modern watch store would carry one... If not, online stores are your friends. YMMV *shrug*
The demo version for Windows didn't even have NPC voice overs or more than one voice set. The retail version has all of the above where the demos did not. Your vid card on the 17" probably doesn't support the shiny water AFAIK since it's just a GeForce4 Go440 (derivative of MX440, a souped up GF2MX almost) and has no pixel shaders, etc.
"ps. how many of todays slashdot readers know what ^H means?"
^H (Ctrl-H) = 0x08 in ASCII (Backspace)
Just like how Enter/Carriage Return is ^M (Ctrl-M) or 0x0d, etc. Ahh... the good ol' days of terminals. I miss my VAX account *sniff*