If you write userland software, you most likely don't have to care about FS, GUI (there are framework that handle that for a vast majority of cases), init process or whatever. You write *userland* *software*.
The main issue is how to distribute your software. Then your concern become "should I support X, Y or Z distro". Just pick something like two of the "big" ones, and if people run something else, they can manage the details on porting a package from X to Y.
There's even relatively standard way to hook into stuff like "load on startup" through freedesktop. And as long as you officially support a restricted set of distributions, that's not a problem.
Software doing something quite complicated like crafting a message, sending an attachment etc. is not software being faulty and the execution being corrupt, it's software doing what it was told. The problem likely lies before the software turns from idea into code, so the language is irrelevant. Until we have AI-powered compiler that can analyze human behavior, no language, no matter how modern, should prevent a developper from writting code that do stuff, no matter how silly it is.
Ah, didn't even think of using RSS for that. In the end, I'll just spend less time navigating through youtube, just showing up on the right video page and leaving right after it.
I'm sure that's exactly what Youtube's exec wanted; people spending less time on their platform while still getting the content.
That's not really the point here (although it might be valid in other discussions).
The LIDAR/Radar/Whatever does not care much about lighting condition, so understanding the cause of the failure is important. If the cause isn't linked to lighting, then this situation (pedestrian crossing where it shouldn't) could trigger the same lack of reaction in broad daylight if the conditions are right. This is a serious issue.
It would be better for everyone (except maybe for short-term gains from carmakers) to crowdsource the development of these driverless software and hardware. More experience and knowledge poured into the system, more transparency when these issues arise.
Nothing's needed really. A few week ago, I updated a Windows 7 system to Windows 10. The initial "free" offer was never accepted (at the time, everything available to disable the upgrade from even installing were used). Just got to the page to download the installer, it ran some checks and proceeded with installing and activating Windows 10.
I'm not sure there's even a reason for microsoft to disable this path. Upgrading older systems to Windows 10 means more computer with it installed, and most people that still have old systems are unlikely to actually buy it standalone. Instead their next time buying Windows 10 will be with a new computer, as they are also unlikely to try to move it from one system to another.
I forcefully disabled every permissions on the FB Messenger app, and it works fine. I'd say it's pretty safe (as long as FB doesn't actively try to work around the permissions system).
I don't rank that. I don't have to. I wrote (but you omited that part in your quote) that there's no absolute way to say that one piece of software is better than another security wise, and that the only thing openness bring to the table is the ability for anyone to look into it.
I didn't say (here or anywhere else) "there must be secret bugs they don't tell us about" so I don't see why you're asking me this, aside from trying to stir a fruitless "discussion".
No idea, but that's the point. Citing CVE (or any equivalent) listings as a "security gauge" is silly one way or another. And even if such list was relevant as to how secure a piece of software is, it would still be irrelevant in the real world, because you'd have to take into account how feasible each vuln. is, how effective it is, and how many systems are at risks.
The main difference between closed-source and open-source here is that one allows for more eyeballs than the other; it doesn't mean that more people will actually look, find, fix vulnerabilities, nor that such vulnerabilities will be easier/harder to exploit in the real world, and how useful they'll end up to be. There's just too much variable to say "X is better/worse than Y" in such absolute way.
Opening a page with "_blank" target doesn't open a blank page; it open a page in a new tab/window. It's super common, and is often used to open link to external sites without losing the current page (it's somewhat seen as a UX nightmare for some people).
So it's not just allowing a blank page to run foreign JavaScript, it's allowing any real page, following "correct looking" URL to run foreign JavaScript.
For reference, an "about:blank" is what you'd want if you want to open a blank page. But the article clearly state "_blank", which is different.
That's the number of publicly known/published vulnerabilities. We know (and it has been proven true) that a lot of vulnerabilities are secretly kept when discovered.
Looking at it another way, I could say "look at how many flaws were fixed in the linux kernel, Mac Os X, Chrome and Firefox, and look at how many were fixed in MS products". Listing CVE says nothing about the actual number of vulnerabilities, only about their disclosure.
I can't tell about Chrome on MacOS (because I don't have one), but maybe Chrome usage of system resources needs a bit more analyzis to be on point. I use it on both Windows and Linux-based system (Ubuntu/KDE right now) and it's working fine, even with multiple tabs in multiple windows, a situation that's very common for me (I keep things open in their own window during work).
To me this sounds like the old complains we got when people look at their free RAM, and see it's close to 0, just because of some cache. I don't know exactly what Chrome is doing because, well, I don't look at it unless the system becomes unstable, which it doesn't. But since I can happily launch some heavy stuff (mostly video transcoding and games) while keeping my tabs open, I'd say Chrome is not the magic culprit most people accuses it to be.
It is. I don't know what they did (I'll check the changelog when I install it), but I've been using Audacity on W10 with no issues or workaround of any kind.
Right now, I can play my games, while recording the whole audio/video output, AND record a secondary audio through a third program. All of this without performance issue. I'm fairly certain if MS implement any sort of "better" scheduling for gaming this will not work as well anymore.
Call me a pessimist if you want, but at this point it's more akin to experience.
So basically MS's Linux subsystem can't even do the job Cygwin does quite nicely?
Cygwin can't run native Ubuntu elf executables which is wehat the Linux subsystem does.
I probably missed the gazillion times this point was raised, but why is this a thing? I get it that you can just run "the same file" but why bother. The linux subsystem is not even close to be a real production environment so you can't validate anything on it anyway. There are so many ways to get a good linux environment that are both way closer to the real thing and can run native binaries (obviously).
As a developer, I honestly don't see the use case here when I can either run a VM, dualboot, or for most simple project simply build them as windows executable anyway. In which case do you need to run a linux ELF in a butchered down environment that (hopefully) isn't what you'll run the production code in the end?
Rest assured that they will half-ass the thing, and most likely end up with an implementation that's useless at best. I can already see the missing settings, the incorrect behavior and, most likely, some random crash. Third party app really have nothing to be worried bout.
With that kind of game supposedly based on exploration, you have to invest quite some time to find out that no, there's nothing to do here. 50h might be stretching out a bit, but even 20-30 hours of gameplay should not be enough to find everything if the game was not as empty as it is.
A few months ago, I wanted to try whatsapp on Android. The app asked me for permission to dig into my contacts, which I refused.
You can't do much without that permission: impossible to start a conversation, impossible to input a name for someone that started a conversation with you, impossible to add contacts by hand in whatsapp; it have to be in the phone contact's list.
When I asked their support about this, they kindly redirected me to their FAQs, explained to me that they use phone numbers to identify contact, that it was for my convenience that this was required, etc. I even got a full rundown of Android permissions required by whatsapp. No option to ever start a conversation by typing a phone number ever came on the table.
Best part was this: "We value your privacy and we do not sell your personal information to anyone.". I suppose technically it's not sold "to anyone", but still. Trust is the most important thing you need in this business; if you require from people to give you all their infos, then pull jokes like that, you might as well just stop doing business.
And how would one does this? By design, DRM schemes requires a level of obscurity. It doesn't matter the mean you're using, if you have encrypted content that you want in clear, at one point you'll have to have both the content and the key available client side. If anyone can implement such DRM, then nothing prevents the copy of the deciphered content as it is played.
That's why we got HDCP as an attempt to plug the "if you can play it, you can save it" hole. And we know how it went.
I'd be really impressed if someone came up with a DRM solution that satisfy all these:
Allow playback of content on user system
Prevent all form of recording without protection
Can be implemented by anyone
The closest you'll get is with keys stored in hardware, but we've seen how that one played out already.
So, stop saying that "it is up to other browsers to add support". The instant anyone can play encrypted content, it's gone. And people pushing DRM really don't want that.
Security for who? Not for the people actually making content, not for the customers, not for netflix... Ah, I have it on the tip of my tongue... who's increasing security by screwing over everyone involved again?
Joking aside, most people will not care about "why" only Edge will support 1080p, because most people are not into technical stuff. However, a fair amount of people turns to their somewhat geeky relative/friend when some question arise; and those will know that the only reason for Edge to support this when other won't is content provider willingly screwing other by using DRM. I'm curious to see how this will play out in the long term.
Hmm. How much of the actual hardware in a system *can* you audit then?
Off-the-shelves stuff is out of question: processors design at the hardware level is not something most of us can access, and I believe they also run some internal software over that, which is not accessible either. Same for the memory controller. *bridges are also out of the question. Mainline GPUs that can peek and poke through PCI, and most other extension cards almost always have some firmware parts that are closed sources.
Granted, there exist completely free and open sources alternatives to most of this stuff, but as seen by the recent compiler issue from microsoft, can you trust the people building the devices to make them up to spec? And them, do they use tools that are 100% certain to not change how things operates?
Sure, if all your hardware is open source and can be somehow 100% certified by yourself to follow the original design, and the OS you run on it is also 100% open source (this one is actually feasible obviously) and you built it yourself, using a compiler you 100% audited yourself, then you can trust everything.
But if not, there is no need to look for a hidden backdoor in the processor; it can as easily run a secret blob on the main CPU without telling the OS and still have access to all the hardware.
I wouldn't be so sure.
Disclaimer: this happens in France, I have no idea how the contactless ship is sailing anywhere else. But we have had chips for as long as I can remember, and contactless just got added recently. A bunch of people jumped on it: payment terminal slowly gets it, automated vending machines too.
Of course, it is as secure as anywhere else (read: not) but that didn't stop the adoption. Thankfully by law banks are obligated to either provide a card without contactless payment or provide a way to disable it, but still it's growing.
Now, they could probably change the contactless protocol to use the same protocol as actual contact payment, including PIN and EMV validation, but that would get in the way of usability, and between security and ease of use, it seems that even money isn't safe.
We had a relatively secure thing: physically put the card in the reader, enter PIN. Takes a few seconds, opposed to... the few seconds it takes for contactless to kick in. But it's not shiny anymore I guess.
Slashdot Mirror
If you write userland software, you most likely don't have to care about FS, GUI (there are framework that handle that for a vast majority of cases), init process or whatever. You write *userland* *software*.
The main issue is how to distribute your software. Then your concern become "should I support X, Y or Z distro". Just pick something like two of the "big" ones, and if people run something else, they can manage the details on porting a package from X to Y.
There's even relatively standard way to hook into stuff like "load on startup" through freedesktop. And as long as you officially support a restricted set of distributions, that's not a problem.
Software doing something quite complicated like crafting a message, sending an attachment etc. is not software being faulty and the execution being corrupt, it's software doing what it was told. The problem likely lies before the software turns from idea into code, so the language is irrelevant. Until we have AI-powered compiler that can analyze human behavior, no language, no matter how modern, should prevent a developper from writting code that do stuff, no matter how silly it is.
Ah, didn't even think of using RSS for that. In the end, I'll just spend less time navigating through youtube, just showing up on the right video page and leaving right after it.
I'm sure that's exactly what Youtube's exec wanted; people spending less time on their platform while still getting the content.
That's not really the point here (although it might be valid in other discussions).
The LIDAR/Radar/Whatever does not care much about lighting condition, so understanding the cause of the failure is important. If the cause isn't linked to lighting, then this situation (pedestrian crossing where it shouldn't) could trigger the same lack of reaction in broad daylight if the conditions are right. This is a serious issue.
It would be better for everyone (except maybe for short-term gains from carmakers) to crowdsource the development of these driverless software and hardware. More experience and knowledge poured into the system, more transparency when these issues arise.
Nothing's needed really. A few week ago, I updated a Windows 7 system to Windows 10. The initial "free" offer was never accepted (at the time, everything available to disable the upgrade from even installing were used). Just got to the page to download the installer, it ran some checks and proceeded with installing and activating Windows 10.
I'm not sure there's even a reason for microsoft to disable this path. Upgrading older systems to Windows 10 means more computer with it installed, and most people that still have old systems are unlikely to actually buy it standalone. Instead their next time buying Windows 10 will be with a new computer, as they are also unlikely to try to move it from one system to another.
I forcefully disabled every permissions on the FB Messenger app, and it works fine. I'd say it's pretty safe (as long as FB doesn't actively try to work around the permissions system).
I don't rank that. I don't have to. I wrote (but you omited that part in your quote) that there's no absolute way to say that one piece of software is better than another security wise, and that the only thing openness bring to the table is the ability for anyone to look into it.
I didn't say (here or anywhere else) "there must be secret bugs they don't tell us about" so I don't see why you're asking me this, aside from trying to stir a fruitless "discussion".
No idea, but that's the point. Citing CVE (or any equivalent) listings as a "security gauge" is silly one way or another. And even if such list was relevant as to how secure a piece of software is, it would still be irrelevant in the real world, because you'd have to take into account how feasible each vuln. is, how effective it is, and how many systems are at risks.
The main difference between closed-source and open-source here is that one allows for more eyeballs than the other; it doesn't mean that more people will actually look, find, fix vulnerabilities, nor that such vulnerabilities will be easier/harder to exploit in the real world, and how useful they'll end up to be. There's just too much variable to say "X is better/worse than Y" in such absolute way.
Opening a page with "_blank" target doesn't open a blank page; it open a page in a new tab/window. It's super common, and is often used to open link to external sites without losing the current page (it's somewhat seen as a UX nightmare for some people).
So it's not just allowing a blank page to run foreign JavaScript, it's allowing any real page, following "correct looking" URL to run foreign JavaScript.
For reference, an "about:blank" is what you'd want if you want to open a blank page. But the article clearly state "_blank", which is different.
That's the number of publicly known/published vulnerabilities. We know (and it has been proven true) that a lot of vulnerabilities are secretly kept when discovered.
Looking at it another way, I could say "look at how many flaws were fixed in the linux kernel, Mac Os X, Chrome and Firefox, and look at how many were fixed in MS products". Listing CVE says nothing about the actual number of vulnerabilities, only about their disclosure.
Ok, now I have to read the full paper to see how to interpret high score while not feeling so bad :\
I can't tell about Chrome on MacOS (because I don't have one), but maybe Chrome usage of system resources needs a bit more analyzis to be on point. I use it on both Windows and Linux-based system (Ubuntu/KDE right now) and it's working fine, even with multiple tabs in multiple windows, a situation that's very common for me (I keep things open in their own window during work).
To me this sounds like the old complains we got when people look at their free RAM, and see it's close to 0, just because of some cache. I don't know exactly what Chrome is doing because, well, I don't look at it unless the system becomes unstable, which it doesn't. But since I can happily launch some heavy stuff (mostly video transcoding and games) while keeping my tabs open, I'd say Chrome is not the magic culprit most people accuses it to be.
It is. I don't know what they did (I'll check the changelog when I install it), but I've been using Audacity on W10 with no issues or workaround of any kind.
He was lying. Win 7 doesn't collect telemetry...at least it didn't originally, maybe a Windows update put it in.
You posted as AC, but from that quote it will be easy to find who you are, simply by listing people that lived in a cave for the last year or so.
...or that it will be possible to disable it.
Right now, I can play my games, while recording the whole audio/video output, AND record a secondary audio through a third program. All of this without performance issue. I'm fairly certain if MS implement any sort of "better" scheduling for gaming this will not work as well anymore.
Call me a pessimist if you want, but at this point it's more akin to experience.
Technically, it won't be valid in the US of Trump. It was valid *before*...
That's a good move. Instead of fighting windmills trying to shut down the network, use it. No idea how it will fare, but that's the way to go.
Cygwin can't run native Ubuntu elf executables which is wehat the Linux subsystem does.
I probably missed the gazillion times this point was raised, but why is this a thing? I get it that you can just run "the same file" but why bother. The linux subsystem is not even close to be a real production environment so you can't validate anything on it anyway. There are so many ways to get a good linux environment that are both way closer to the real thing and can run native binaries (obviously).
As a developer, I honestly don't see the use case here when I can either run a VM, dualboot, or for most simple project simply build them as windows executable anyway. In which case do you need to run a linux ELF in a butchered down environment that (hopefully) isn't what you'll run the production code in the end?
Rest assured that they will half-ass the thing, and most likely end up with an implementation that's useless at best. I can already see the missing settings, the incorrect behavior and, most likely, some random crash. Third party app really have nothing to be worried bout.
With that kind of game supposedly based on exploration, you have to invest quite some time to find out that no, there's nothing to do here. 50h might be stretching out a bit, but even 20-30 hours of gameplay should not be enough to find everything if the game was not as empty as it is.
A few months ago, I wanted to try whatsapp on Android. The app asked me for permission to dig into my contacts, which I refused.
You can't do much without that permission: impossible to start a conversation, impossible to input a name for someone that started a conversation with you, impossible to add contacts by hand in whatsapp; it have to be in the phone contact's list.
When I asked their support about this, they kindly redirected me to their FAQs, explained to me that they use phone numbers to identify contact, that it was for my convenience that this was required, etc. I even got a full rundown of Android permissions required by whatsapp. No option to ever start a conversation by typing a phone number ever came on the table.
Best part was this: "We value your privacy and we do not sell your personal information to anyone.". I suppose technically it's not sold "to anyone", but still. Trust is the most important thing you need in this business; if you require from people to give you all their infos, then pull jokes like that, you might as well just stop doing business.
and can be implemented on any platform
And how would one does this? By design, DRM schemes requires a level of obscurity. It doesn't matter the mean you're using, if you have encrypted content that you want in clear, at one point you'll have to have both the content and the key available client side. If anyone can implement such DRM, then nothing prevents the copy of the deciphered content as it is played.
That's why we got HDCP as an attempt to plug the "if you can play it, you can save it" hole. And we know how it went.
I'd be really impressed if someone came up with a DRM solution that satisfy all these:
The closest you'll get is with keys stored in hardware, but we've seen how that one played out already.
So, stop saying that "it is up to other browsers to add support". The instant anyone can play encrypted content, it's gone. And people pushing DRM really don't want that.
for an even higher level of security
Security for who? Not for the people actually making content, not for the customers, not for netflix... Ah, I have it on the tip of my tongue... who's increasing security by screwing over everyone involved again?
Joking aside, most people will not care about "why" only Edge will support 1080p, because most people are not into technical stuff. However, a fair amount of people turns to their somewhat geeky relative/friend when some question arise; and those will know that the only reason for Edge to support this when other won't is content provider willingly screwing other by using DRM. I'm curious to see how this will play out in the long term.
Hmm. How much of the actual hardware in a system *can* you audit then?
Off-the-shelves stuff is out of question: processors design at the hardware level is not something most of us can access, and I believe they also run some internal software over that, which is not accessible either. Same for the memory controller. *bridges are also out of the question. Mainline GPUs that can peek and poke through PCI, and most other extension cards almost always have some firmware parts that are closed sources.
Granted, there exist completely free and open sources alternatives to most of this stuff, but as seen by the recent compiler issue from microsoft, can you trust the people building the devices to make them up to spec? And them, do they use tools that are 100% certain to not change how things operates?
Sure, if all your hardware is open source and can be somehow 100% certified by yourself to follow the original design, and the OS you run on it is also 100% open source (this one is actually feasible obviously) and you built it yourself, using a compiler you 100% audited yourself, then you can trust everything.
But if not, there is no need to look for a hidden backdoor in the processor; it can as easily run a secret blob on the main CPU without telling the OS and still have access to all the hardware.
I wouldn't be so sure.
Disclaimer: this happens in France, I have no idea how the contactless ship is sailing anywhere else. But we have had chips for as long as I can remember, and contactless just got added recently. A bunch of people jumped on it: payment terminal slowly gets it, automated vending machines too.
Of course, it is as secure as anywhere else (read: not) but that didn't stop the adoption. Thankfully by law banks are obligated to either provide a card without contactless payment or provide a way to disable it, but still it's growing.
Now, they could probably change the contactless protocol to use the same protocol as actual contact payment, including PIN and EMV validation, but that would get in the way of usability, and between security and ease of use, it seems that even money isn't safe.
We had a relatively secure thing: physically put the card in the reader, enter PIN. Takes a few seconds, opposed to... the few seconds it takes for contactless to kick in. But it's not shiny anymore I guess.