"Lawful intercept" is a term used in telecoms to refer to a feature of a communications system that allows the police or the government or the TLAs to monitor the communications of a specific endpoint (a person or an address or a device). The implication is that there's some judicial oversight to stop the authorities from abusing it, and some security to stop anyone who isn't the authorities from gaining access to it. The term also implies that the feature is there by design - it can't (or shouldn't) "accidentally" disappear when the vendor releases an update. Just calling it "intercept" or "interception" doesn't convey what it's for and how it works.
I agree that bragging that your product has this feature (even if it's always been there) is a pretty dumb idea, regardless of what you call it. Unless your target market is no longer the users of your product, but people who want to spy on the users and who are in a position to force them to use the product...
I'd be interested in learning more about the compatibility problems you're having with real apps and
We know that there are ocassionally compat issues because we have large customers we work with to try and mitigate them.
There are already mechanisms built into
If you're trying to install an app and it says "i need
If you have problems of the latter sort -
Give us some credit for taking baby steps...
A few years ago, this would have been called "Microsoft Active Developer Conference 2016 with Bing.com and VisualStudio.com"
Surely you agree that "Connect();" is an improvement ?
Instead of LibreSSL.
Mozilla is big enough that they can have an opinion on how the web should work, and the web will move.
They should dump OpenSSL and invest in a winner.
I'm not in any way involved with this specific program, but I do work on VisualStudio.
It's pretty common for all kinds of software projects to take bug reports - even very detailed and thorough ones - from people who ultimately don't end up fixing the bug.
The interesting thing about finding a security bug - especially with the constraints described here - a working exploit and a white paper - it's pretty unambiguous that you've found one. You either have or you haven't.
Now, how to actually fix that bug might be a lot more nuanced.
This statement isn't made to in any way imply that a researcher who could find such a bug _couldn't_ also fix it.
Rather, some bug fixes may be preferable to others, from Microsoft's point of view. And so, my impression is - we're not looking for patches that we'd end up re-writing. We're looking for the really nasty bugs, and then we'll go off and come up with fixes that satisfy the big pile of requirements that we have [for example, performance impact]
A valid observation would be, "if these were really open source projects, anyone in the community would be able to run the same regression and performance tests that Microsoft would run, and thus be able to make perfectly valid fixes themselves"
Well, to a point. Long long ago, I found an IDE driver bug in OpenBSD and submitted a fix for it. The fix was substantially re-written by the maintainer, and, ultimately the whole subsystem was replaced in the next version anyhow.
My fix met the functional requirements, so near as I can tell. But there are things like coding style, or maybe even the personal preferences by the project maintainer(s), that can still impact how a particular patch gets rejected or modified prior to being committed.
Furthermore, I think we would hate for there to be a vuln out there that somebody knows about, but is sitting on until they can come up with a fix that they like.
So, yes, I think we really just want the vulnerability reports, well substantiated and with demonstrated exploits. Finding those things is still very much a niche skill.
Fixing them, once they are understood, and balancing those fixes with the other requirements in the system, is more bread-and-butter Microsoft engineer stuff.
fwiw, I've been at Microsoft 15 years, much of it in VisualStudio. Before that, I worked only with UNIX systems, and I've stayed up to date as a hobby.
The way we are trying to engage with Apple, Linux, and F/OSS in general is completely unlike anything we did up until just the last year or so. People I've worked with for years are suddenly diving headlong into Linux development. Arguments that I tried to make a decade ago are now being made by other people.
It's a really interesting time at the company.
I'm always on the hunt for ideal archival formats for digital media.
The ideal archival format has a few properties, ranging from most theoretical to most practical:
- a completely unencumbered specification and a completely unencumbered implementation
- a highly portable, f/oss reference implementation
- excellent quality vs. usability (e.g. lossless quality, but small to store and fast to decode)
- support in popular general purpose computing environments
- supported in popular dedicated hardware devices
FLAC gets the first few of those, but not the last one -- plenty of dedicated hardware audio players don't deal with FLAC.
Because of this, I use MP3 for audio - which theoretically gives up the first few points, but as a practical matter, those points are irrelevant, and MP3 completely dominates the industry on the last few points.
If Vorbis or FLAC or any of the things that get the first few points correct had ubiqoutous device support, I might be willing to re-rip everything into those formats for a great blend of long-term archival and easy-to-consume on any device convenience. But nothing is like that for audio.
Similarly, if I thought there was going to be a fantastic lossless image format that did everything well and was going to be massively supported and was completely unencumbered, i'd want to move everything over to it. I'd want my future digital cameras to start shooting it. I'd want my whole tool stream and whole life to just be about that format.
How we plan to expose cloud-based filesystems in Samba:
I know you're just a random slashdot poster, and I really shouldn't expect any better, but would it hurt you to look at the list of Document Foundation (the Org behind LibreOffice) and look at the list of supporters:
"Chris DiBona, Open Source Programs Manager at Google, Inc., has commented: "The creation of The Document Foundation is a great step forward in encouraging further development of open source office suites. Having a level playing field for all contributors is fundamental in creating a broad and active community around an open source software project. Google is proud to be a supporter of The Document Foundation and participate in the project".
Hint - supporters mean we fund them. I represent Google on the Board of Directors, and yes, nagging them about getting a full Android port is something I do *every* meeting.
I now return you to your regularly scheduled slashdot poster 2-minute-hate on "Big Corporations".
That would probably require a lawsuit, or at least the threat of one, which would probably involve spending more on lawyers than you're ever likely to see in damages...
I'd be surprised if it was against anti-spam laws. CAN-SPAM applies specifically to messages advertising a commercial service or product, though I suppose this tactic could fall foul of other countries' laws. I'm curious as to how you'd get around them if it did. Claim you have an existing business relationship with Vimeo because you watched a video that someone posted there?
Adding features does not necessarily increase functionality -- it just makes the manuals thicker.